Windows sandbox permanently unusable after a truncated deny_read_acl_state.json write

What version of the Codex App are you using (From “About Codex” dialog)?

26.814.41407

What subscription do you have?

plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Summary

A single interrupted write leaves deny_read_acl_state.json as a fixed-length run of
NUL bytes. From that moment the Windows sandbox can never start again. Every
sandboxed operation fails, and the failure is unrecoverable through the UI: restarting
the app, updating to a new build and rebooting Windows all leave the corrupt file in
place. In my case it silently blocked all apply_patch work for ten days.

Two things make this worse than an ordinary crash-recovery gap:

1. The error names the wrong subsystem. It reports apply deny-read ACLs, so

every diagnostic path — mine and the assistant's I asked for help — went hunting
Windows ACLs, Controlled Folder Access, antivirus interception and sandbox user
accounts. The code never reaches the ACL stage. It fails while *reading its own
state file*.

1. There is no automatic recovery. An unparseable cache file is treated as fatal

rather than discarded and rebuilt.

Error output

setup error: apply deny-read ACLs

Caused by:
    0: parse deny-read ACL state C:\Users\<user>\.codex\.sandbox\deny_read_acl_state.json
    1: expected value at line 1 column 1
[codex.exe] setup refresh: exited with status ExitStatus(ExitStatus(1))

expected value at line 1 column 1 is the serde_json error for input that is empty
or does not begin with valid JSON.

Root cause

The state file was 22 bytes, every byte 0x00:

00000000: 0000 0000 0000 0000 0000 0000 0000 0000  ................
00000010: 0000 0000 0000                           ......

The file that Codex writes on a healthy run is also 22 bytes. So the length was
preserved while the contents were not — the classic NTFS signature of metadata being
flushed before data, i.e. an interrupted write from a crash, forced shutdown or power
loss. The file's mtime matched the last date the sandbox ever worked.

Timeline

| When | What |
|---|---|
| 9 Aug, 05:30 | deny_read_acl_state.json written as 22 NUL bytes |
| 9 Aug, 06:29 | last successful CodexSandboxOffline logon — sandbox works |
| 9 Aug → 19 Aug | every sandbox setup fails identically |
| 19 Aug | file renamed aside; sandbox works again immediately |

What steps can reproduce the bug?

1. Use Codex Desktop on Windows until %USERPROFILE%\.codex\.sandbox\deny_read_acl_state.json exists.
2. Close Codex. Overwrite that file with NUL bytes, preserving its length:

``powershell
$p = "$env:USERPROFILE\.codex\.sandbox\deny_read_acl_state.json"
[IO.File]::WriteAllBytes($p, (New-Object byte[] ((Get-Item $p).Length)))
``
(An empty file, or any non-JSON first byte, reproduces it equally.)

1. Start Codex and run anything that needs the sandbox, e.g. an apply_patch.
2. It fails with the error above, and keeps failing.

What is the expected behavior?

An unreadable or unparseable sandbox state file should be discarded and rebuilt, with
a warning. It is a cache of applied ACEs, not authoritative data — losing it costs a
re-apply, not a working installation.

At minimum the error should name the actual failure: reading a state file, and the
path, so the user can delete it. Ideally the message would say so outright.

Additional information

What did not fix it

• Closing and reopening Codex Desktop, and starting a fresh task — no change
• Updating Codex — no change. My logs show two different builds producing

byte-identical failures:

• 16 Aug: ...\.devin\extensions\openai.chatgpt-26.5730.61309-win32-x64\...\codex-windows-sandbox-setup.exe
• 18 Aug: C:\Program Files\WindowsApps\OpenAI.Codex_26.814.5167.0_x64__...\codex-windows-sandbox-setup.exe
• Restarting Windows — no change

None of these touch a file in the user profile, which is why the advice to restart or
update cannot work for this failure mode.

What did fix it

Renaming deny_read_acl_state.json aside and letting Codex recreate it. Working
immediately, first attempt, no other change.

Ruled out during diagnosis

Recorded because the misleading error message sends people to all of these:

• Defender Controlled Folder Access — disabled; no block events
• Third-party AV/EDR — none; Defender only, normal mode
• Filesystem — NTFS; long paths enabled
• Workspace scale — 4,636 files, 1,124 dirs, longest path 145 chars, no symlinks
• Reparse points / OneDrive placeholders in the workspace — none
• User permissions — verified by applying a deny-read ACE to a temp file in the

workspace by hand: succeeded

• OneDrive redirection — Documents, Desktop and Pictures are all redirected to

OneDrive with cldflt running, and applying a deny ACL inside OneDrive Documents
also succeeded

• Orphaned SIDs — two unresolvable SIDs hold Modify on the workspace; irrelevant,

the sandbox works fine with them present

Environment

| | |
|---|---|
| OS | Windows 11 Pro, build 10.0.26200, UBR 9168 |
| Codex | OpenAI.Codex_26.814.5167.0_x64 (also reproduced on openai.chatgpt-26.5730.61309-win32-x64) |
| command-runner | codex-command-runner-0.148.0-alpha.15.exe |
| Sandbox accounts | CodexSandboxOffline, CodexSandboxOnline, both enabled |
| Workspace | local NTFS path under C:\Users\<user>\Documents |

Unrelated warning seen on every healthy run

Non-fatal, but noise in the log:

hide users: failed to hide current user profile dir (C:\Users\Default):
SetFileAttributesW failed for C:\Users\Default: 5 (Access is denied)