Windows restricted sandbox cannot apply_patch existing files: “cannot enforce split writable root sets directly”
What version of the Codex App are you using (From “About Codex” dialog)?
ChatGPT Desktop: 1.2026.190.0 - OpenAI Codex package: 26.715.4045.0
What subscription do you have?
Business
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
On Windows, apply_patch can create a new file under the normal restricted
permission mode, but it cannot update the newly created existing file.
The identical update succeeds immediately under Full Access.
This appears related to #31776, but the failure is different. There is no
Access Denied error and no multiline patch corruption. The operation fails
while preparing the filesystem sandbox before the target file is opened.
- CodexSandboxOffline exists and is enabled
- CodexSandboxOnline exists and is enabled
- Integrated terminal: PowerShell
What steps can reproduce the bug?
- Under normal restricted access, use native apply_patch to create:
_codex_patch_probe.txt
Contents:
probe-1
Creation succeeds.
- Use native apply_patch to update probe-1 to probe-2.
- The update fails.
PowerShell independently confirms:
- Get-Location: C:\coding-work
- Test-Path .\_codex_patch_probe.txt: True
- Get-Content: probe-1
- File attributes: Archive
- File length: 8 bytes
Patch submitted:
* Begin Patch
* Update File: _codex_patch_probe.txt
@@
-probe-1
+probe-2
*** End Patch
Exact error
apply_patch verification failed: Failed to read file to update
C:\coding-work\_codex_patch_probe.txt:
failed to prepare fs sandbox:
failed to prepare windows sandbox wrapper:
windows unelevated restricted-token sandbox cannot enforce split writable
root sets directly; refusing to run unsandboxed
Additional result
After switching the same session to Full Access:
- Updating probe-1 to probe-2 succeeds using native apply_patch.
- Deleting the probe file succeeds using native apply_patch.
No fallback editing method was used.
What is the expected behavior?
The normal restricted Windows sandbox should permit apply_patch to update
existing files inside the selected workspace.
Additional information
Related issue
Possibly related to #31776, but this report fails during filesystem sandbox
preparation rather than due to the generated .bat path or multiline argument
transport.
2 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Resolved on my system.
The root cause was a legacy config.toml:
[windows]
sandbox = "unelevated"
The older unelevated sandbox had worked successfully on this same computer
a few days earlier, including native apply_patch updates to existing files.
However, with the current runtime it failed with:
windows unelevated restricted-token sandbox cannot enforce split writable
root sets directly; refusing to run unsandboxed
Changing the configuration to:
[windows]
sandbox = "elevated"
triggered the one-time Windows sandbox setup.
After setup:
Therefore, this was not a broken apply_patch helper. It was caused by the
legacy unelevated sandbox selection being incompatible with the current
runtime behavior.
A clearer startup warning or automatic migration when a copied config still
selects sandbox = "unelevated" may be useful.
Closing as resolved.