Windows sandbox: apply_patch can add files but cannot update/delete existing files due to apply deny-read ACLs

Open 💬 3 comments Opened Jul 6, 2026 by Traveller23

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

What version of Codex CLI is running?

codex-cli 0.142.5

What subscription do you have?

business

Which model were you using?

gpt-5.5

What platform is your computer?

Microsoft Windows NT 10.0.26200.0

What terminal emulator and version are you using (if applicable)?

Windows PowerShell 5.1.26100.8655

Codex doctor report

What issue are you seeing?

On Windows, apply_patch can create new files, but fails whenever it needs to read an existing file for Update File or Delete File. The failure happens even in a clean repro directory outside the main
project, so it does not appear related to project config, AGENTS.md, Git state, dependencies, symlinks, or file ACLs.

Error:

apply_patch verification failed: Failed to read file to update ...:
fs sandbox helper failed with status exit code: 1:
windows sandbox failed: helper_unknown_error: apply deny-read ACLs

What steps can reproduce the bug?

cd C:\data\javascript
mkdir codex-sandbox-repro
cd codex-sandbox-repro
git init
mkdir .scratch
"hello" | Set-Content .scratch\test.txt
Get-Content .scratch\test.txt

Then ask Codex to run:

* Begin Patch
* Update File: .scratch/test.txt
@@
-hello
+hello world
*** End Patch

Observed:

apply_patch Add File succeeds.
Get-Content can read the file.
icacls shows normal inherited permissions including CodexSandboxUsers modify rights.
apply_patch Update File fails with apply deny-read ACLs.
apply_patch Delete File fails with the same error.
Running shell commands with escalation works, so a workaround is to use PowerShell writes, but apply_patch has no escalation parameter.

What is the expected behavior?

apply_patch should be able to read and update/delete files inside the workspace when normal shell reads succeed and ACLs permit access.

Additional information

Starting Codex from the project root and using relative paths did not help.
Reading the target with Get-Content immediately before apply_patch did not help.
Switching to “Approve for me” did not help.
The same failure reproduced in a clean C:\data\javascript\codex-sandbox-repro git repo.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

#31220
#31086
#30712
#30964
#29938

Powered by Codex Action

Traveller23 · 1 month ago

I checked the suggested potential duplicates.

I think #30712 and the unelevated part of #31220 are closely related, but they do not look like the exact same failure mode as this issue.

This issue fails with:

windows sandbox failed: helper_unknown_error: apply deny-read ACLs

apply_patch Add File succeeds, but Update File / Delete File fail when the fs-helper tries to read an existing workspace file. Normal PowerShell reads succeed in the same clean repro directory.

By contrast, #30712 fails earlier while preparing the unelevated sandbox wrapper:

windows unelevated restricted-token sandbox cannot enforce split writable root sets directly

That looks like a split writable-root enforcement problem, while this issue looks like the helper launches but then incorrectly denies reading an existing file.

#31220 includes the same split-root failure as #30712, plus a separate elevated-mode CreateProcessAsUserW failed: 1312 problem.

#31086, #30964, and #29938 look related to Windows sandbox/setup-helper failures, but they center on codex-windows-sandbox-setup.exe, ShellExecuteExW failed to launch setup helper: 1223, module-not-found dialogs, or proxy/setup-marker mismatch. Those seem related but not exact duplicates of this apply deny-read ACLs repro.

So my suggestion would be:

Track split writable roots under #30712 / #31220.
Track setup-helper/proxy/module launch failures under #29938 / #30964 / #31086.
Keep this issue open for the distinct apply deny-read ACLs failure where the helper can run but cannot read an existing workspace file.

Traveller23 · 1 month ago

I closed #31248 as likely related to this Windows sandbox read/ACL issue, but I want to preserve one additional data point.

In my reproduction, view_image failed with:

windows sandbox failed: helper_unknown_error: apply deny-read ACLs

This happened while using the elevated Windows sandbox. The local image existed on disk and was readable from PowerShell.

After changing:

[windows]
sandbox = "elevated"

to:

[windows]
sandbox = "unelevated"

view_image started working correctly.

So this may be useful evidence that the view_image failure is tied to the elevated Windows sandbox read/ACL path, not to image decoding or file existence.

I later encountered a different failure mode in unelevated mode:

windows unelevated restricted-token sandbox cannot enforce split writable root sets directly

I think that should be tracked separately from this apply deny-read ACLs issue. The two failure modes appear different:

apply deny-read ACLs: helper runs but denies reading an existing local file.
split writable root sets: unelevated sandbox rejects the writable-root configuration before the tool can run.