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.
34 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.
I found a related Windows behavior in the same managed-workspace setup.
Switching the global Windows sandbox to
unelevatedrestored immediateapply_patchcreate/update/delete operations. Switching it toelevatedremoved the split-root error but made patch operations take tens of seconds or hang.The practical workaround was:
unelevated.%APPDATA%.One additional diagnostic trap: if a Flutter command is stopped, its Dart analyzer/test child can remain alive with near-zero CPU. The next command may appear stuck for minutes. Inspect the command lines and terminate only orphaned processes belonging to the stopped Flutter command (for example,
flutter_tools.snapshot analyzeand itsanalysis_server.dart.snapshotchild) before retrying.This workaround made patching responsive while preserving a path for elevated Flutter tooling, but the underlying managed split-writable-root/elevated-sandbox interaction still appears to need a product fix.
It also blocks view_image/image-generation preflight, not only apply_patch, on app version 26.721.11231.0.
In case it helps anybody, this seems to finally be fixed at version 0.146.0 (tried every single version between 0.141.0 and that one, and finally it seems to work). There are dozens of issues with this error now, so not sure how effective this will be, but anyway, let's hope it does help somebody.
This regression is reproducible after the August 1, 2026 Windows app update.
Environment:
Observed behavior:
apply_patch remains pending, yields after approximately 11 seconds, and never returns success or an actionable error. The operation must be terminated. After termination, the target file’s SHA-256 remains unchanged.
Control checks:
Additional controlled-test result:
A minimal Add File apply_patch operation remained pending for approximately 33 seconds, and the agent reported that it did not finish. However, the UI showed a +1 file edit, and independent readback confirmed that the file was successfully created with the expected 6 bytes ("probe\n").
SHA-256:
25BE323556DAD377ABB57FE7EC8C4B99A6527F488DDA28D0C9B686528659C909
This indicates that the mutation can complete while the apply_patch completion/acknowledgment path hangs. Earlier attempts to update an existing Markdown file left that file unchanged, so outcomes are inconsistent and cannot safely be inferred from the stalled tool result.
Expected behavior:
apply_patch should either apply the edit or return a specific parsing, context, permission, or filesystem error. It should not remain pending indefinitely.
The Microsoft Store shows that ChatGPT was modified on August 1, 2026, and the failure began after that update. This appears to be a regression in the Windows apply_patch tool-host or sandbox-helper path.
Yeah, +1 to this after applying the Aug 1st update
Codex Version 26.727.51351 x64
Windows Home 22H2, build 19045.6466
For what it's worth, I updated to 26.730.61309, and still see the issue.
is there anyway to go back to an older version taht doesnt have this Issue? Getting it here too
Thought I would try the new version..
Controlled result:
App: 26.803.5235.0
Runner: 0.147.0-alpha.6.5
Test began: 2026-08-07 04:55:14.094 UTC
Operation: create only .codex-apply-patch-repro-26803.txt
After 45 seconds: still running, with no completion output
Tool state: Script running with cell ID 7
Action: bounded call terminated
Filesystem verification: scratch file was not created
Git status before and after: identical
Existing project files and the older scratch file were untouched
Hi @openai/codex-core-agent-team — this issue (#30009) has been reproduced by multiple people and is blocking file edits via the apply_patch tool on Windows. Summary:
Symptoms: sandbox-wrapper setup fails with "failed to prepare windows sandbox wrapper", "windows unelevated restricted-token sandbox cannot enforce split writable root sets directly", "refusing to run unsandboxed", or the apply_patch process hangs for ~2 minutes before manual cancel.
Repro: see above
Logs: can get if needed
Impact: users cannot apply patches in sessions on Windows; this appears to be a sandbox-wrapper setup problem or an apply_patch hang on failure.
Request: could someone from the team triage and assign? Suggested first actions:
Confirm whether this is the same root cause as #10601.
Add a fail-fast error path when sandbox wrapper setup fails (return diagnostic error, not a long hang) OR wrap the wrapper spawn in a 30s timeout and emit detailed logs.
If a code fix is preferred, a small reproducible test or local repro would help — please let me know what extra logs you need; I can collect them.
Thanks — I can help collect extra logs or try a candidate fix if helpful.
Reproduced a closely related failure on Windows Codex Desktop in August 2026.
Environment/behavior:
apply_patchtool.Test-Path, file length, SHA-256) continued to work normally against the same directory.apply_patch.This appears to fail before filesystem mutation and is consistent with a Windows sandbox/tool-call bridge problem rather than patch syntax or repository permissions. It also resembles the no-result behavior in #24155 and the long approval/sandbox delays reported in #32790 and #35018.
A useful improvement would be a bounded timeout with a clear sandbox/setup diagnostic instead of leaving the patch call without a result. I can provide Codex task IDs or sanitized sandbox logs privately if maintainers need them.