Windows sandbox sets incorrect ACLs when creating new folders, causing issues with apply_patch

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

• #14409
• #13378
• #14006

Powered by Codex Action

I can reproduce what looks like the same Windows sandbox/apply_patch failure pattern.

Environment:

• Native Windows 10
• PowerShell 7
• Codex v0.115.x
• Approval policy: never
• Filesystem sandbox: workspace-write
• Windows sandbox enabled

Observed behavior:

• apply_patch is intermittent
• it can work in the workspace root, but fail on a nested workspace folder
• terminal error: windows sandbox: setup refresh failed with status exit code: 1

<img width="1156" height="89" alt="Image" src="https://github.com/user-attachments/assets/5d46791e-61e7-4510-bc6a-c87910bf5b0e" />

Relevant sandbox log evidence:

• setup error: setup refresh had errors
• write ACE failed on C:\git\my-repo\Codex\scripts\setup: SetNamedSecurityInfoW failed: 5

I also previously saw a related read-ACL failure under %USERPROFILE%:

• CreateFileW failed for C:\Users\<user>\Intel
• grant read ACE failed on C:\Users\<user>\Intel

That later self-corrected when the sandbox successfully added a read ACE, but the workspace write-ACE failure still occurs intermittently.

One potentially useful clue: the failure mode changed over time on the same machine. Earlier, setup refresh failed in the read-ACL pass while touching a top-level %USERPROFILE% folder. Later, that self-corrected after Codex added a sandbox read ACE, but a different failure still occurred in the setup refresh write-ACE step on a nested workspace folder with SetNamedSecurityInfoW failed: 5.

When inspected afterwards, the affected workspace folder already appeared to have inherited CodexSandboxUsers modify rights and inheritance enabled, so this may point to duplicate/unnecessary ACE application or an inherited-ACL propagation edge case rather than a simple missing local permission.

So from this machine, #14585 looks like a real existing issue rather than a one-off local ACL misconfiguration.

I think I have some of the same issues on 26.325.31654. I saw lots of rejected apply_patch calls in the UI, and reading the sandbox log at %Userprofile%\.codex\.sandbox\sandbox.log hinted at ACE writing failing. I checked my path, and sure enough, there were sandbox user groups (and some unknown SID) already in the ACL.

From what I saw, it should work - maybe the error is that "writing ACE failed because its already there..". I'm unsure. I closed the codex app, reset the permissions on my project folder (removed the sandbox group, the unknown user SID) by replacing the permissions on all child objects. It failed, so I elevated to admin to do this reset.

Once I restarted codex app, I immediately got the user group back in the ACL, but now apply_patch seems to work.

Maybe this works until I restart codex app?

One thing I noticed, because I'm still having issues, was an ACE edit on the ...\Resources folder in the windows app. I checked it out and found this.

<img width="1543" height="443" alt="Image" src="https://github.com/user-attachments/assets/a0bf0da8-10c0-42f7-bebb-19b90c56e3d7" />

Its the first time I've ever seen a "Condition" on an ACE. Clicking it brings this:

<img width="1239" height="734" alt="Image" src="https://github.com/user-attachments/assets/32b84463-b876-4f89-a9ef-05b5f8df360d" />

Windows doesn't like the ACE that's been made.

This issue helped me get a temp fix going for editing files at least, thanks everyone.

This command fixed individual files and enabled Codex to edit them again:
icacls {file} /reset

So I made a PowerShell script to fix all the files with stale ACL, that fixed editing for my project folder. It's a bit of a brute force approach, so you may want to back up with icacls cmd first.

Another workaround for editing fix for entire folder (mentioned earlier by @LordMike):
On the project root folder, go to Properties > Security > Advanced and use: “Replace all child object permission entries with inheritable permission entries from this object”
<img width="586" height="243" alt="Image" src="https://github.com/user-attachments/assets/bd592f5c-b891-4191-9d54-79801fc1cd41" />

But even after ACL repair, a fresh Codex session in sandbox_mode = "workspace-write" still cannot delete or rename properly for me. The delete / rename operations works in sandbox_mode = "danger-full-access" however.

So there appears that might be a separate Windows workspace-write delete/rename bug, distinct from the stale ACL issue as well.

Using Win11/codex 0.120.0/Powershell 7.

I've resorted to running with "unsafe" or "yolo" setups for now. At least when working on things that don't involve the web as much. But then another issue pops up: Codex is regularly unable to run "rg". I suspect that the unrestricted "sandbox" is really just "run as me", and that the "rg.exe" Codex ships is in a folder where regular Users don't have execute rights.

I saw other guides saying "install rg.exe outside codex and put it in path", which probably works because then regular users (me) can run it, its in path so it probably takes precedence over the codex-shipped one, and so on... Conversely, that may break the sandboxed execution of rg.exe, because now Sandbox-users don't have execute rights .. :'D

I can confirm this is broader than apply_patch and appears to be tied to Codex-injected ACL entries on Windows.

What I observed on native Windows:

• The issue reproduces only on folders that were added to Codex as workspaces.
• Neighboring folders that were not added to Codex do not get the same ACL changes.
• Codex adds opaque SID-based ACEs to the workspace ACL (shown as raw S-1-5-21-... entries instead of normal account names).
• If I manually remove those SID ACEs and add the named sandbox users (CodexSandboxOffline / CodexSandboxOnline) with Full Control, Codex later adds the opaque SID back again.

Minimal repro outside apply_patch:

1. In a Codex-added workspace folder, create a file from a sandboxed command. This succeeds.
2. Try renaming that file in the same directory (Move-Item / System.IO.File.Move). This fails with Access to the path is denied.
3. The same rename operation succeeds outside the sandbox.

Important detail:

• NTFS effective access for the named sandbox user shows Create/Write/Delete permissions.
• The failure is still reproducible.
• So this does not look like a simple missing ACL right on the folder; it looks like Codex is injecting or refreshing incorrect ACL/sandbox principals and the resulting sandboxed process still cannot perform rename/replace operations.

This affects build tools too, because MSBuild/WinUI/Roslyn often do:

• write temp file
• rename/replace temp file into final name

So the bug is not limited to apply_patch. It also breaks normal file rename/replace semantics inside writable workspace roots.

I can reproduce a related apply_patch failure in the Codex Windows desktop app, but with a different and deterministic trigger: the host automatically injects a second writable root for visualization artifacts.

Environment:

• Codex Windows package: OpenAI.Codex_26.707.3748.0_x64
• Native Windows desktop app
• Sandbox mode: workspace-write
• Network: restricted
• Workspace: a normal writable local directory
• visualize@openai-bundled was disabled in ~/.codex/config.toml before this installation/session was started:

[plugins."visualize@openai-bundled"]
enabled = false

Initially, the permission profile contained only the project workspace as a filesystem writable path and apply_patch succeeded.

The Codex host later automatically added a session-specific path similar to:

C:\Users\<user>\.codex\visualizations\2026\07\12\<thread-id>

The generated turn context then contained:

"sandbox_policy": {
  "type": "workspace-write",
  "writable_roots": [
    "C:\\Users\\<user>\\.codex\\visualizations\\2026\\07\\12\\<thread-id>"
  ]
}

The same path was also added as a writable entry in permission_profile. In a later environment context it was additionally promoted to a second workspace_root.

After that injection, a minimal update to an existing file using the internal apply_patch tool failed before patch parsing with:

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

No shell-write fallback or elevated execution was used. The file remained unchanged.

This is not caused by patch syntax, file permissions, Unicode paths, or a user-configured additional directory. The visualization directory is injected by the host even though the bundled visualization plugin is disabled.

The injected path is also recorded in every generated turn_context, so existing valuable conversations remain affected when resumed. Editing conversation JSONL files would not solve it because the host regenerates the sandbox policy for each turn.

Expected behavior:

1. The Windows restricted-token sandbox should support the complete writable-root set generated by the Codex host; or
2. The host should not inject the visualization artifact directory when visualization support is disabled; or
3. Visualization artifacts should be placed inside the existing workspace/temp root without creating a split writable-root set.

At minimum, the app should avoid generating a sandbox policy that its own Windows wrapper explicitly refuses to enforce.

Additional measurements from another native Windows 11 machine (10.0.26200 x64), using the standalone Codex CLI 0.144.4.

Configuration:

• approval_policy = "never"
• sandbox_mode = "workspace-write"
• [windows] sandbox = "unelevated" for the working configuration
• official Codex bin first in PATH; MSI PowerShell 7 second

Observed results:

• Raw filesystem write outside Codex sandbox setup: about 0.1 s; file read: about 47 ms.
• With windows.sandbox = "elevated" and the normal user TEMP, sandbox startup took 27.1 s and failed with helper_unknown_error: setup refresh had errors.
• Elevated mode with a project-local TEMP took 22.3 s and succeeded, so TEMP/ACL refresh strongly affects the result.
• Unelevated mode completed in 2.3 s with project-local TEMP and 3.5 s with normal TEMP.
• A write outside the workspace was still correctly denied (Access denied, about 4.0 s), so the workaround did not disable isolation.
• Two internal apply_patch calls in a fresh child directory succeeded in about 17.9 s and 10.4 s.
• A later repeat, explicitly forcing two apply_patch calls under the trusted workspace root, succeeded in 20.599 s and 13.814 s.

One extra detail: running codex exec -C <new child directory> automatically added that child as a trusted project in config.toml. Re-running from the already trusted workspace root and targeting relative child paths avoided that config mutation.

The main remaining problem is latency in the internal apply_patch/sandbox refresh path: it is much faster than the earlier 60–210 s behavior, but still 10–21 s while raw disk I/O is effectively immediate.

Post-update retest on Codex CLI 0.144.5 (same Windows 11 machine):

• codex doctor --json: overall OK, installation consistent, installed/latest both 0.144.5.
• Unelevated launcher smoke: 0.661 s; direct sandbox write/isolation probe: 0.671 s.
• Two apply_patch calls executed automatically immediately after the update: 13.040 s and 12.148 s.
• A separate final full dry-run produced 16.159 s and 14.220 s.
• Outside-workspace write remained blocked.
• EXE and config hashes were unchanged by the final dry-run.

So 0.144.5 does not remove the internal apply_patch latency on this machine. It remains roughly 12–16 s per fresh call even though the sandbox smoke itself is below 0.7 s.

Packaging note: after the update, codex-windows-sandbox-setup.exe and codex-command-runner.exe were no longer adjacent to the public codex.exe; they are under the release codex-resources directory. A launcher that assumes adjacent helpers will report a false failure even though Codex itself works.

One more stateful timing detail after the 0.144.5 retest:

Immediately after the two forced elevated failures, the next normal unelevated launcher smoke succeeded but took 19.5 s, so the launcher's 10 s safety threshold stopped the session. Repeating the identical unelevated smoke once returned to 0.675 s.

Sequence on the same process environment:

1. elevated + normal TEMP: fail after 19.838 s
2. elevated + project TEMP: fail after 2.277 s
3. next unelevated smoke: success but 19.5 s
4. immediate identical unelevated retry: success in 0.675 s

This suggests the elevated attempt can leave transient sandbox/setup-refresh state affecting the next unelevated initialization, even though the following run recovers.

I can consistently reproduce this issue in the Codex desktop app on Windows.

Environment

• Product: Powered by Codex & OWL
• Version: 26.715.21425
• Platform: Windows
• Date: July 17, 2026
• Workspace: C:\tmp\codex-sandbox-probe
• The workspace was explicitly configured as writable.
• The test was performed twice with identical results.

Reproduction steps

I used only the internal apply_patch tool—no PowerShell, Python, redirection, or other filesystem-writing methods.

1. Create probe.txt:

``diff
*** Begin Patch
*** Add File: probe.txt
+step-1
*** End Patch
``

Result: Succeeded

1. Update probe.txt:

``diff
*** Begin Patch
*** Update File: probe.txt
@@
-step-1
+step-2
*** End Patch
``

Result: Failed

``text
apply_patch verification failed: Failed to read file to update
C:\tmp\codex-sandbox-probe\probe.txt:
fs sandbox helper failed with status exit code: 1:
windows sandbox failed: helper_unknown_error:
setup refresh had errors
``

1. Delete probe.txt:

``diff
*** Begin Patch
*** Delete File: probe.txt
*** End Patch
``

Result: Failed

``text
apply_patch verification failed: Failed to read
C:\tmp\codex-sandbox-probe\probe.txt:
fs sandbox helper failed with status exit code: 1:
windows sandbox failed: helper_unknown_error:
setup refresh had errors
``

Observed behavior

The first apply_patch call succeeds, but every subsequent patch targeting the newly created file fails during the Windows sandbox setup refresh, before the patch can be applied.

Because the delete operation failed, the file should remain with the original step-1 content. I intentionally did not use another filesystem tool to verify it, keeping the reproduction strictly limited to apply_patch.

Expected behavior

Files created in an explicitly writable workspace should remain readable and modifiable by subsequent apply_patch calls. The sandbox setup refresh should not fail after the first successful write.

Still reproducible on Codex CLI 0.144.6, Windows 11 build 26200, with [windows] sandbox = "unelevated".

The session root was C:\Users\<user>, with the repository nested under it. apply_patch successfully created a new file, but two attempts to update an existing file returned empty output with no patch completion event. Normal shell-based edits worked, and the existing/new files had identical ACLs.

A separate sandboxed command also failed with: SetTokenInformation(TokenDefaultDacl) failed: 1344

This appears related to the same path-sensitive Windows sandbox/ACL issue.