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.
2. 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:

   $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.)
3. Start Codex and run anything that needs the sandbox, e.g. an apply_patch.
4. 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)

Start by locating the Windows sandbox setup path that reads %USERPROFILE%.codex.sandbox\deny_read_acl_state.json and reproducing the failure with the provided PowerShell command. Check how parse failures are reported and how the state is rebuilt. Done means an invalid state file is discarded and recreated with a warning, and failures identify state-file reading rather than ACL application.