Corrupted deny_read_acl_state.json causes persistent "apply deny-read ACLs" sandbox failures

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

• #34013

Powered by Codex Action

Thanks for flagging #34013. I reviewed it, and the two issues appear closely related but cover different failure stages.

#34013 identifies a live concurrency race while multiple Windows sandbox helpers update the shared deny_read_acl_state.json file. The missing inter-process lock and direct std::fs::write() can expose an empty file during truncate/write and can also cause lost updates.

This issue, #34276, covers recovery after the state file is already persistently corrupted. In my case, the file was not only observed empty during a concurrent operation; it remained on disk as 22 NUL bytes across Codex and Windows restarts. Codex then failed on every startup until I manually renamed the file and allowed it to regenerate:

00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00

The persistent failure was:

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

After renaming the corrupted file, Codex regenerated:

{
  "principals": {}
}

and sandbox initialization completed successfully.

My understanding is:

• #34013: prevents corruption and lost updates during concurrent helper execution through a transaction-wide mutex and atomic replacement.
• #34276: recovers users whose state file is already malformed or filled with NUL bytes by backing it up and recreating a valid default state.

The race in #34013 is a plausible source of state corruption, although the exact path that left 22 persistent NUL bytes in my case is not proven by the available logs.

I would therefore prefer to keep this issue open unless maintainers consider existing-corruption recovery fully covered by another issue such as #30251 or #30540. A complete fix should ideally include both prevention and recovery:

1. serialize the full load → ACL update → store transaction;
2. write through a temporary file and atomically replace the state;
3. detect malformed existing JSON, preserve it as a .broken file, recreate the default state, and continue startup.

Additional reproducible Windows Codex Desktop report (2026-07-26, America/New_York):

Exact recurring failure:

node_repl kernel exited unexpectedly
node_repl diagnostics: {"kernel_status":"exited(code=1)","kernel_stderr_tail":"windows sandbox failed: helper_unknown_error: apply deny-read ACLs","reason":"stdout_eof"}

Reproduction:

1. Open Codex Desktop on Windows.
2. Invoke the Node-backed Chrome browser controller, Windows Computer Use controller, or even a trivial Node REPL call such as nodeRepl.write("ready").
3. The kernel exits in roughly 0.3–0.4 seconds before browser discovery, capture, or interaction begins.

Recovery attempts that did not work:

• Resetting the Node kernel repeatedly.
• Fully restarting Codex Desktop.
• Full Windows system reboot.
• Relaunching Codex as administrator.
• Keeping Chrome open and authenticated, then reconnecting after restart.

Scope/impact:

• Both the Chrome-control plugin and Windows Computer Use fail at the same ACL initialization stage.
• No webpage capture or click occurs, so this is below the browser-extension/session layer.
• The failure persisted across multiple fresh processes and a full OS reboot.
• After repeated occurrences, an ordinary Codex tool process also began failing with CreateProcess ... helper_unknown_error: apply deny-read ACLs, suggesting the sandbox state failure can spread beyond Node-backed UI tools.
• This blocked a user-authorized browser maintenance task; no external data was changed.

Environment visible from the failing session:

• Windows Codex Desktop
• Chrome control bundle: 26.721.41059
• Computer Use bundle: 26.721.41059

Expected behavior:

• Sandbox initialization should recover automatically from malformed/stale ACL state (ideally preserve the broken state file for diagnostics, regenerate a valid default atomically, and continue), rather than permanently disabling browser, computer-use, Node, and eventually ordinary tool processes.

This appears consistent with the persistent-state recovery problem described in this issue and may also relate to the race discussed in #34013.

Adding another data point on the "recovery after corruption" side of this, since #34013 explains the race but not why the state stays broken across restarts.

Same signature — 22 NUL bytes, persisted across multiple Codex/Windows restarts:
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
In my case the impact wasn't limited to Browser Use / Computer Use or Node-backed tools — all file read/write in a normal Codex task was blocked, including editing an existing document with no browser or computer-use tools invoked at all. So this state file failing to parse appears to block sandbox init broadly, not just the browser/computer-use/Node code paths mentioned above.

Same workaround: fully exit Codex, delete/rename the corrupted file, restart — regenerates cleanly as {"principals": {}} and everything works again.
+1 on parkswon1's point that a full fix needs both prevention (the #34013 race fix) and recovery (detect malformed JSON, back it up, regenerate default, continue startup) — since even with the race fixed, any future crash/power-loss mid-write could reproduce this same permanently-stuck state.