apply_patch fails with a windows sandbox related error
What version of the Codex App are you using (From “About Codex” dialog)?
Version 26.616.81150 • Released Jun 23, 2026
What subscription do you have?
pro
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What issue are you seeing?
On Windows, file edits through apply_patch are broken in my session.
I’ve seen these errors/messages:
failed to prepare windows sandbox wrapperwindows unelevated restricted-token sandbox cannot enforce split writable root sets directlyrefusing to run unsandboxed
I tried changing it from unelevated to elevated, and when I did, a tiny apply_patch test did not fail fast — it hung for about 2 minutes until I manually canceled it.
So the bug seems to be one of these two behaviors:
- sandbox wrapper setup fails with the messages above, or
apply_patchhangs instead of returning a clean error
What steps can reproduce the bug?
On my session, any attempt to patch a file results in sandbox wrapper setup failure
What is the expected behavior?
it should be able to write to files without resorting to other methods
Additional information
This looks related to the Windows sandbox path, not the repo itself.
A similar public issue may be related:
- #10601 Sandbox setup error on Windows
The session/workspace was using a workspace-write style sandbox with mixed writable roots / restricted filesystem policy.
The failure appears to happen before the patch is actually applied, during sandbox/wrapper setup.
24 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I searched and there was a weird sized copy of codex-windows-sandbox-setup.exe. Solved the issue by deleting AppData\Local\OpenAI\Codex\bin and AppData\Local\Packages\OpenAI.Codex\LocalCache\Local\OpenAI\Codex\bin
Ok, still getting the issue with "windows unelevated restricted-token sandbox cannot enforce split writable root sets directly" when it uses apply_patch to delete a file.
I can confirm this issue on my setup as well. And I think we are being forced to pay about 2x because of this. (No numbers , just personally observed pre and post usage percentages before and after this bug)
Environment
Windows 11
VS Code Extension
Codex CLI 0.142.2 (installed via npm)
ChatGPT Plus
GPT-5.5
Approval: OnRequest
Filesystem sandbox: restricted
apply_patch consistently fails with messages such as:
"apply_patch is blocked by the Windows sandbox wrapper in this session, so I'm using the approved PowerShell path..."
My config.toml already contains:
[windows]
sandbox = "unelevated"
and codex doctor reports that the configuration is loaded correctly.
The functional workaround (PowerShell edits) allows work to continue, but I believe it has another significant side effect. as mentioned at the top it increases used credits/tokens on each request by approximately 2X.
Yeah, my usage has also tanked, single commands that seem like they would have used 10% before now seem to use 50% of my usage, with what looks like the same or higher token usage per day on the profile, so it's possible there's something burning through context compared to before, not sure if it's this.
As a temporary solution, it does seem like instructing codex to use the Codex CLI apply-patch path instead of the 'WindowsApps' version might sometimes help, but when I tried that it still burned through context. Weirdly, it seemed like it went from like 60 to 50 percent usage remaining, but then a minute later without sending any commands it jumped down to only 8 percent remaining.
I haven't see that magnitude of change, for me its just about double, i think because when apply_patch is not available it needs to figure out he exact old code and new code to replace it using string replace or a similar thing.
That is just a high level understanding based on my observations on what it does during thinking and executing when i juxtapose that against token usage.
I'm also hitting this issue, but on codex CLI. Seems to be a regression, as I've tested
0.142.3,0.142.0and0.141.0, but only the last one (0.141.0) works.Additional Windows Desktop reproduction from my machine.
Environment:
OpenAI.Codex_26.623.5546.0_x64__2p2nqsd0c76g0C:\Users\Ethan Rodrigues\AppData\Local\OpenAI\Codex\bin\codex.exe->codex-cli 0.142.0@openai/codex@0.142.3,codex-cli 0.142.3IsAdmin = falseObserved behavior:
[windows] sandbox = unelevated,apply_patchcan add a new file, but update/delete fails while preparing the fs sandbox:[windows] sandbox = elevated, the original split-root error is gone, but update/delete now fails because the setup helper requires elevation:Relevant sandbox log excerpt:
Other checks:
codex-windows-sandbox-setup.exeexists atC:\Users\Ethan Rodrigues\AppData\Local\OpenAI\Codex\bin\codex-windows-sandbox-setup.exe.OpenAI OpCo, LLC; statusSignature verified.Expected behavior:
apply_patchshould be able to update/delete normal files inside the workspace, or the app should request/setup elevation cleanly once and then proceed.apply_patch.so should i just use on CLI , with version 0.141.0 to save my tokens ?
this is getting to a point where i am not able to work when using VS Code extension, and in CLI i can not provide images to the agent.
but at this point i think it is wiser to move to CLI v0.141.0 if that will save my tokens.
Has anyone tried that ?
Not sure if that will save your tokens or not, but you can still use images in the cli version, you can even drag and drop them, but it might also depend on your terminal.
I am seeing what looks like the same Windows sandbox issue on a new Windows 11 Home PC.
Extra details:
Writes are still blocked inside the writable root:
This happens outside Documents/OneDrive, so it does not appear to be a protected-folder issue.
In my case the failure affects direct file creation as well as patch/edit operations.
Resolution in my case was switching Windows sandbox mode in C:\Users\<you>\.codex\config.toml:
[windows]
sandbox = "elevated"
I tried sandbox = "elevated" and it caused commands to freeze and not respond until I cancelled the chat and sent a new command.
I'm also having this problem.
Here is what Codex told me to post here:
Codex Desktop Windows apply_patch hangs only with [windows] sandbox = "elevated"
Codex app version: 26.623.9142.0
Codex CLI version: 0.142.4
OS: Windows 11 CoreSingleLanguage, 10.0.26200
Project path: C:\Codex\bfd
Config:
default_permissions = ":workspace"
[windows]
sandbox = "elevated"
Observed:
Diagnostics:
Relevant session id:
019f1ae1-3219-79b0-b65c-40239dc55ed7
How to Fix Codex Windows Sandbox
apply_patch failureProblem
On Windows, Codex Desktop may fail when running sandboxed tools. Common symptoms include:
apply_patchsandboxed file reads failCOM+ ErrorSID Errorrgmay still workThis can happen when Codex itself needs a network proxy, but the Windows sandbox helper also inherits proxy environment variables.
Root Cause
The sandbox helper can inherit these environment variables:
When that happens, Codex may write a local proxy port into:
For example:
Later, when
apply_patchor another sandboxed tool triggerscodex-windows-sandbox-setup.exe, the helper may try to refresh Windows sandbox or firewall state for that proxy port and fail.Clearing
setup_marker.jsonalone may not persist, because old Codex or launcher processes can still have the proxy variables in their process environment and write the port back.Fix
Edit the Codex config file:
Add or merge the following configuration:
This keeps Codex network proxy support enabled while preventing sandboxed tools and shell commands from inheriting proxy environment variables.
Apply the Change
config.toml.to:
If the port is not
4780, still clear the array.The order matters: restart Codex first, then clear
proxy_ports. If old Codex processes are still running, they may write the proxy port back.Verification
First, confirm the sandbox shell no longer sees proxy environment variables:
Expected result: no output, or empty values.
Then confirm:
in:
Finally, verify that patching works.
Patch Tool Test Case
Run this as a single prompt inside Codex:
After the patch,
foo.txtshould contain:If this succeeds, the sandbox helper is no longer failing during
apply_patch.Reference
Solution Source
huge thanks! works for me.
btw, path should be `
%USERPROFILE%\.codex\.sandbox\setup_marker.json` with "[dot] sandbox".Thanks for the suggestion. I tried this, but it did not fix my case.
A few differences from the proxy/
proxy_portsfailure mode:``
text
``C:\Users\Leandro\.codex\.sandbox\setup_marker.json
not
.codex\sandbox\setup_marker.json.setup_marker.jsondoes not containproxy_portsat all. It only contains:``
json
``{
"version": 5,
"offline_username": "CodexSandboxOffline",
"online_username": "CodexSandboxOnline",
"created_at": "...",
"read_roots": [],
"write_roots": []
}
```toml
[features]
network_proxy = true
[shell_environment_policy]
inherit = "all"
exclude = ["HTTP_PROXY", "HTTPS_PROXY", "ALL_PROXY", "http_proxy", "https_proxy", "all_proxy"]
```
Then I fully restarted Codex and tested again with:
``
toml
``[windows]
sandbox = "elevated"
The
apply_patchupdate step still hung.proxy_ports, or setup-helper failure errors around the repro. It repeatedly shows the setup helper completing successfully, for example:``
text
``setup refresh: processed 2 write roots (read roots delegated); errors=[]
``
text
``[windows]
sandbox = "elevated"
With
sandbox = "elevated",apply_patchupdate hangs.With
sandbox = "unelevated", create/update/delete throughapply_patchworks.So this may be a different Windows sandbox/apply_patch failure mode than the proxy-port issue. In my case the setup helper appears to complete cleanly, but
apply_patchstill hangs under the elevated Windows sandbox and never emits a clean completion/error.Thanks for sharing the workaround. I tested it on my machine, but it didn't resolve the issue.
My environment is Codex CLI/VS Code Extension v0.142.5 on Windows, with sandbox = "unelevated". I added the network_proxy and shell_environment_policy.exclude configuration, confirmed there are no HTTP_PROXY/HTTPS_PROXY environment variables, and verified the config is being loaded (codex doctor shows network_proxy overridden).
In my case, there is no setup_marker.json under .codex\.sandbox, and the sandbox logs don't show any COM+, SID, proxy, firewall, or setup-helper errors. All sandboxed PowerShell commands succeed. The failure is isolated to apply_patch, which reports a Windows sandbox wrapper/preparation error during the second patch operation.
This seems like a different Windows apply_patch failure mode than the proxy-related issue.
Follow-up from my Windows Desktop repro after testing the newer workaround comments.
I applied the proxy workaround suggested above and used the corrected marker path with dot-sandbox:
Current relevant config now includes:
I also checked/cleared the marker file. In my case it was already empty:
I also checked the shell environment for these proxy variables:
No proxy env vars were visible in the shell I tested from.
After restarting/retesting, the result is still:
apply_patchAdd File succeeds.apply_patchUpdate File fails.So for my setup, the proxy/
proxy_portsworkaround does not resolve the remaining failure mode. My current finding is that this looks closer to #30712: Windows Desktop is launching the session with a split writable-root shape that the unelevated restricted-token sandbox cannot enforce for theapply_patchread/update/delete path.I also previously tried
[windows] sandbox = elevated, but on my machine that moved the failure to the elevated helper path:So neither current local workaround fully fixes my case:
proxy_portsalready empty.sandbox = elevated: hits elevation/helper launch failure.sandbox = unelevated: normal shell commands work, butapply_patchupdate/delete fails with split writable roots.The initial error mentioned (
windows unelevated restricted-token sandbox cannot enforce split writable root sets directly) indicates that the unelevated sandbox cannot handle two writable folders. By default, the writable folders are the local one and the /tmp folder.So I deactivated in config.toml the tmp dir from being wirtable and it worked.
Not sure about overall impact on usability though, I havn't tested this workaround extensively yet.
Sad to see these sandbox issues are not getting the attention they deserve from the codex team. These have been around for maybe 2-3 months and no fixes yet.
I tried using in CLI to see if this apply_patch works in there after updating to latest version this morning and wanted to drag and drop images , but it does not read from screenshots on windows and there is no way to let it read from what i understand right now, codex said i will paste in c;/tmp folder but pasted there and not able to see it there as well.
With so many models and tools and resources, they are not getting it right for paying customers.
The useful way to separate the Windows sandbox reports is by the boundary that failed, not by the command that happened to reveal it.
I would split the diagnostic contract into three states:
For apply_patch specifically, a split-root failure should be terminal before patch execution and should return a no_patch_applied outcome with the rejected writable roots in a safe diagnostic record. Switching to elevated mode may be a workaround, but it is not the same class; if the elevated helper hangs, that is a launch or IPC failure, not a patch failure.
The regression test I would want is:
That would make these reports easier to dedupe: users can tell whether they hit split-root enforcement, helper launch, proxy or marker mismatch, or actual apply_patch behavior.
Additional controlled reproduction from Codex Desktop on Windows (2026-07-20).
Environment:
26.715.4045.0Microsoft Windows NT 10.0.26200.0 x64Observed in the managed
workspace-write/ restricted-filesystem mode:apply_patchAdd File did not return for about 60 seconds.{}and the file had actually been created with the expected content.apply_patchDelete File was still unresponsive after roughly 20 seconds and the task was manually interrupted.I then changed only the task permission profile to
danger-full-access/ unrestricted and repeated the same smoke test in the same workspace:This A/B comparison strongly suggests the delay/hang is in the Windows sandbox/wrapper path, rather than in patch parsing, the target file, or the workspace filesystem. The restricted-mode behavior is especially problematic because it can eventually report success after a long silent stall, while another patch operation may remain stuck until the task is interrupted.