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

Activity

1. parkswon1

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on Jul 20, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   sandboxIssues related to permissions or sandboxingIssues related to permissions or sandboxing

   on Jul 20, 2026
3. github-actions commented on Jul 20, 2026

   

   github-actionsbot

   on Jul 20, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Windows sandbox helpers race while updating deny_read_acl_state.json #34013

   Powered by Codex Action
4. parkswon1 commented on Jul 20, 2026

   

   parkswon1

   on Jul 20, 2026

   Author

   More actions

   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:

   • Windows sandbox helpers race while updating deny_read_acl_state.json #34013: prevents corruption and lost updates during concurrent helper execution through a transaction-wide mutex and atomic replacement.
   • Corrupted deny_read_acl_state.json causes persistent "apply deny-read ACLs" sandbox failures #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.
5. Slotz321 commented on Jul 26, 2026

   

   Slotz321

   on Jul 26, 2026 – with ChatGPT Codex Connector

   More actions

   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.
6. yjlhuang commented on Aug 18, 2026

   

   yjlhuang

   on Aug 18, 2026

   Last edited by yjlhuang

   More actions

   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.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.
7. warmthdawn commented on Sep 20, 2026

   

   warmthdawn

   on Sep 20, 2026

   More actions

   Additional confirmed persistent zero-byte state-file reproduction, observed on 2026-09-20. Posted at the affected user's request.

   Environment:

   • Windows 11 Pro x64, version 10.0.26200, build 26200.
   • Installed OpenAI.Codex Windows package: 26.915.4065.0 (package version, not an About-dialog version).
   • Running bundled CLI: codex-cli 0.155.0-alpha.9.2.
   • A workspace-write task with managed/restricted filesystem permissions.

   Read-only local inspection found that <CODEX_HOME>/.sandbox/deny_read_acl_state.json exists but is 0 bytes, with a last-write timestamp of September 15. Repeated inspections during this session still show 0 bytes; this is not a valid 22-byte JSON file or a 22-byte all-NUL file.

   The current daily log sandbox.2026-09-20.log repeatedly records:

   setup error: apply deny-read ACLs
   Caused by:
       0: parse deny-read ACL state <CODEX_HOME>/.sandbox/deny_read_acl_state.json
       1: EOF while parsing a value at line 1 column 0
   

   setup_error.json contains only:

   {"code":"helper_unknown_error","message":"apply deny-read ACLs"}

   Observed impact:

   • Browser controller initialization (cua.getState()) and the separate Computer Use Node runtime exit before returning any page/window state.
   • Tool output reports node_repl kernel exited unexpectedly, exit code 1, and windows sandbox failed: helper_unknown_error: apply deny-read ACLs.
   • Resetting and retrying the Node/browser sessions does not recover them.
   • Ordinary sandboxed read-only shell process creation also fails at the same stage. Approved out-of-sandbox diagnostic reads succeed.

   The immediate startup failure is therefore explained by parsing an empty persistent state file. The cause of the original truncation has not been established; #34013 is relevant context, not proof that this particular corruption was caused by the reported race. No ACLs, permission profiles, sandbox mode, or state file have been changed during this investigation, and the rename/regenerate workaround has not been tested on this machine.

   Please include the zero-byte/EOF variant when addressing recovery from existing corrupt state, preserve the corrupt file for diagnosis, and expose the nested parse error in the user-facing failure. Private URLs, project/document contents, usernames, full local paths, and session identifiers have been omitted.

   👍React with 👍1Reacted by mirs7mare