Windows sandbox may auto-apply NTFS deny ACE on world-writable workspace paths

Open 💬 1 comment Opened Mar 8, 2026 by Gorillic

Bug description

Codex Windows sandbox can automatically apply an NTFS deny ACE to workspace paths when its world-writable scan flags the directory (for example with broad ACLs like BUILTIN\\Users:(F) / Everyone-like access). This can cause write failures or unstable write behavior in the active workspace.

Reproduction steps

Use a workspace directory on Windows NTFS with broad write ACLs (world-writable style).
Start a new Codex sandbox session in that workspace.
Check Codex logs and ACL entries for the workspace path.

Expected behavior

Codex should not inject blocking deny ACE entries into user workspace paths by default.

Actual behavior

Codex audit log records automatic deny ACE insertion on the workspace path after world-writable scan failure.

Logs and evidence

Source file: C:\\Users\\<USER>\\.codex\\sandbox.log

[2026-03-09 00:01:47.328 codex.exe] AUDIT: world-writable scan FAILED; cwd="D:\\WorkspaceSample"; checked=291; duration_ms=16; flagged:
 - D:\\WorkspaceSample\\example-subdir
 - \\?\\D:\\WorkspaceSample
[2026-03-09 00:01:47.369 codex.exe] AUDIT: applied capability deny ACE to \\?\\D:\\WorkspaceSample

Similar deny-ACE audit lines also exist in the same log for other directories (D:\\ProjectA, D:\\ProjectB).

Source file: C:\\Users\\<USER>\\.codex\\.sandbox\\sandbox.log (setup timeline and ACL workflow context)

Before/after verification on `D:\\ProjectB`

Before scan

Time: 2026-03-09 00:36:02

Command:

icacls "D:\\ProjectB"

Output excerpt (no explicit DENY ACE at this moment):

D:\ProjectB HOSTNAME\user:(OI)(CI)(F)
           NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(F)
           NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
           BUILTIN\Administrators:(I)(OI)(CI)(F)
           Everyone:(I)(OI)(CI)(F)
           BUILTIN\Users:(I)(OI)(CI)(F)

After running Codex in `D:\\ProjectB`

Time: 2026-03-09 00:36:53

Command:

icacls "D:\\ProjectB"

Output excerpt (new unknown SID deny ACE appears):

D:\ProjectB S-1-5-21-<REDACTED-SID>:(DENY)(W,D,Rc,DC)
           S-1-5-21-<REDACTED-SID>:(OI)(CI)(IO)(DENY)(W,D,Rc,GW,DC)
           HOSTNAME\user:(OI)(CI)(F)
           NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(F)
           NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
           BUILTIN\Administrators:(I)(OI)(CI)(F)
           Everyone:(I)(OI)(CI)(F)
           BUILTIN\Users:(I)(OI)(CI)(F)

Correlated log lines from C:\\Users\\<USER>\\.codex\\sandbox.log:

[2026-03-09 00:36:19.792 codex.exe] AUDIT: world-writable scan FAILED; cwd="D:\\ProjectB"; checked=297; duration_ms=17; flagged:
 - D:\ProjectB\.git
 - D:\ProjectB\frontend
 - D:\ProjectB\notes
 - D:\ProjectB\server
 - \\?\D:\ProjectB
[2026-03-09 00:36:20.163 codex.exe] AUDIT: applied capability deny ACE to \\?\D:\ProjectB

Additional verification (Authenticated Users present)

Check 1

Time: 2026-03-09 00:39:28

ACL snapshot:

D:\ProjectB HOSTNAME\user:(OI)(CI)(F)
           NT AUTHORITY\Authenticated Users:(OI)(CI)(F)
           NT AUTHORITY\SYSTEM:(OI)(CI)(F)
           BUILTIN\Administrators:(OI)(CI)(F)
           BUILTIN\Users:(OI)(CI)(F)

Check 2 (after running Codex command in `D:\\ProjectB`)

Time: 2026-03-09 00:39:37

ACL snapshot:

D:\ProjectB HOSTNAME\CodexSandboxUsers:(OI)(CI)(M,DC)
           S-1-5-21-<REDACTED-SID>:(OI)(CI)(M,DC)
           HOSTNAME\user:(OI)(CI)(F)
           NT AUTHORITY\Authenticated Users:(OI)(CI)(F)
           NT AUTHORITY\SYSTEM:(OI)(CI)(F)
           BUILTIN\Administrators:(OI)(CI)(F)
           BUILTIN\Users:(OI)(CI)(F)

Result in this specific run:

DENY did not reappear.
Sandbox-specific M,DC ACE entries were added back.

Latest verification (cleaned ACL set, write/delete test executed)

Precondition applied

Removed broad entries such as Everyone and BUILTIN\Users.
Kept:
HOSTNAME\user:(OI)(CI)(F)
NT AUTHORITY\Authenticated Users:(OI)(CI)(F)
NT AUTHORITY\SYSTEM:(OI)(CI)(F)
BUILTIN\Administrators:(OI)(CI)(F)

Post-test snapshot

Time: 2026-03-09 00:43:41

Command:

icacls "D:\\ProjectB"

Output:

D:\ProjectB HOSTNAME\CodexSandboxUsers:(OI)(CI)(M,DC)
           S-1-5-21-<REDACTED-SID>:(OI)(CI)(M,DC)
           HOSTNAME\user:(OI)(CI)(F)
           NT AUTHORITY\Authenticated Users:(OI)(CI)(F)
           NT AUTHORITY\SYSTEM:(OI)(CI)(F)
           BUILTIN\Administrators:(OI)(CI)(F)

Observed behavior

DENY did not reappear in this run.
Codex re-added sandbox capability entries (CodexSandboxUsers and capability SID) with M,DC.
No new matching applied capability deny ACE to \\?\D:\ProjectB line was observed during this final check window.

Current ACL snapshot (after cleanup/restart)

Command:

icacls "D:\\WorkspaceSample"

Output:

D:\WorkspaceSample S-1-5-21-<REDACTED-SID>:(OI)(CI)(M,DC)
                   HOSTNAME\CodexSandboxUsers:(OI)(CI)(M,DC)
                   NT AUTHORITY\SYSTEM:(OI)(CI)(F)
                   BUILTIN\Administrators:(OI)(CI)(F)
                   BUILTIN\Users:(OI)(CI)(F)

At report time, no active DENY line is visible on D:\\WorkspaceSample, but prior session logs confirm automatic deny ACE application.

Impact

Possible write failures in workspace/repo.
Repeated manual ACL checks and cleanup.
Disruptive session behavior in normal development flow.

Requested fix

Do not auto-apply deny ACE to user workspace paths by default.
If ACL hardening is required, provide a documented opt-out/policy toggle.
Show a clear user-facing warning before any ACL mutation is performed.

Environment

OS: Windows (NTFS)
Codex mode: sandbox (workspace-write) (v0.111.0) gpt-5.3-codex
Workspace example: D:\\WorkspaceSample
Observed on: 2026-03-08 to 2026-03-09

## Severity / Why this matters

High impact: modifies Windows ACLs on user workspaces.
Can cause write/delete failures and interrupt active development.
Behavior is inconsistent (deny ACE appears in some runs, not others), making it hard to predict and debug.
Requires repeated manual ACL cleanup, increasing operational risk and user confusion.

## Effect on Codex operation
When the deny ACE is present on the workspace path, Codex may fail or behave inconsistently on file operations that
require write access, such as:

creating/editing files,
deleting/renaming files,
applying patches and other write-based tasks.

This can lead to partial task execution, repeated retries, and unreliable session behavior until ACLs are manually
repaired.

## Investigation summary
We narrowed the issue by running controlled ACL experiments on NTFS workspaces and comparing ACL snapshots with Codex
sandbox logs at each step.

Sequence used:

Baseline check with broad ACLs (Everyone / BUILTIN\Users present).
Run Codex in the target workspace and re-check ACL + logs.
Remove broad groups, keep only user/admin/system (+ optionally Authenticated Users), then run Codex again.
Compare outcomes across runs.

Correlated evidence:

Log lines show world-writable scan FAILED followed by applied capability deny ACE.
ACL snapshots confirm deny ACE can appear after Codex run under broad ACL conditions.
After tightening ACLs (removing Everyone and BUILTIN\Users), deny did not reappear in later tests; only sandbox

M,DC ACE entries were re-added.

## Current mitigation / workaround

Remove broad principals from workspace ACLs, especially:
Everyone
BUILTIN\Users (when possible in your environment)
Keep a minimal ACL set:
current user: Full Control
SYSTEM: Full Control
Administrators: Full Control
Authenticated Users only if operationally required
Verify with icacls before/after starting Codex.

## Proposed product-level fix

Do not auto-apply deny ACE to user workspace paths by default.
If hardening is needed, provide a clear opt-in/opt-out policy.
Show explicit user-facing warning before ACL mutation.
Log exact decision criteria for “world-writable” classification to aid diagnosis.

Why we did not use full-access mode or broader alternatives

We intentionally avoided “full-access/no-sandbox” as a primary workaround because it weakens isolation and increases
host risk.
The goal was to keep normal sandbox protections enabled while identifying a stable ACL configuration that prevents
unexpected deny-ACE mutations.

We also avoided masking the issue with one-off/manual cleanup as a long-term solution, because:

it is operationally fragile,
it does not explain root cause behavior,
and it is hard to scale across sessions/machines.

So the investigation prioritized reproducible ACL conditions, evidence-backed logs, and least-privilege mitigation
rather than disabling protections globally.

Thanks

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗

Windows sandbox may auto-apply NTFS deny ACE on world-writable workspace paths

Bug description

Reproduction steps

Expected behavior

Actual behavior

Logs and evidence

Before/after verification on D:\\ProjectB

Before scan

After running Codex in D:\\ProjectB

Additional verification (Authenticated Users present)

Check 1

Check 2 (after running Codex command in D:\\ProjectB)

Latest verification (cleaned ACL set, write/delete test executed)

Precondition applied

Post-test snapshot

Observed behavior

Current ACL snapshot (after cleanup/restart)

Impact

Requested fix

Environment

Why we did not use full-access mode or broader alternatives

Before/after verification on `D:\\ProjectB`

After running Codex in `D:\\ProjectB`

Check 2 (after running Codex command in `D:\\ProjectB`)