Windows: corrupted deny_read_acl_state.json prevents Chrome/Node runtime startup

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

26.901.6511.0

What subscription do you have?

Pro 100$

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Summary

Chrome/browser tools previously worked in Codex Desktop on my Windows computer.
They now fail before any browser tabs can be accessed.

Local diagnostics identified a corrupted Windows sandbox state file:
%USERPROFILE%.codex.sandbox\deny_read_acl_state.json

The file contains 22 null bytes rather than valid JSON.

Environment

• OS: Windows (I can provide the exact version if needed)
• Codex CLI diagnostic version: 0.153.4, windows-x86_64
• Browser: Google Chrome
• Using Codex Desktop with the Chrome/browser integration

Steps to reproduce

1. Open Chrome with a website loaded.
2. Open Codex Desktop.
3. Ask Codex to access Chrome.
4. The browser tool fails during initialization, before returning any tabs.

The failing tool call was:
await cua.getState();

Expected behavior

The browser tool initializes and returns the available browser tabs.

Actual behavior

node_repl kernel exited unexpectedly

Diagnostics:
kernel_status: exited(code=1)
kernel_stderr_tail:
windows sandbox failed: helper_unknown_error: apply deny-read ACLs
reason: stdout_eof

Relevant sandbox log

The sandbox log records:

apply deny-read ACLs
Caused by:
parse deny-read ACL state
%USERPROFILE%.codex.sandbox\deny_read_acl_state.json
expected value at line 1 column 1

Read-only inspection confirmed that the state file contains 22 null bytes.
Ordinary sandboxed shell commands also fail during initialization.

codex doctor reports:
"elevated Windows sandbox provisioning recorded a structured failure"

Troubleshooting already attempted

• Retried the browser tool.
• Restarted Codex Desktop.
• Restarted the entire computer.
• The same failure persists.
• No sandbox state files or ACLs have been manually changed.

Request

Please provide a supported repair procedure for the corrupted
deny_read_acl_state.json file that preserves or correctly reconciles
existing sandbox permissions.

I would like to avoid deleting application data, conversation history,
or project files.

Submitted feedback ID

01a07d65-2ff2-7b02-be38-50c1caf721b1

What steps can reproduce the bug?

1. Open Google Chrome with a website loaded.
2. Open Codex Desktop and select the Chrome integration using @Chrome.
3. Ask: “Can you read the website open in my Chrome browser?”
4. The browser tool attempts to initialize with:
   await cua.getState();
5. Initialization fails before any tabs are returned.

Error:
node_repl kernel exited unexpectedly
windows sandbox failed: helper_unknown_error: apply deny-read ACLs

This happens consistently, including after restarting Codex and rebooting Windows.

Sandbox logs identify a parsing failure in:
%USERPROFILE%.codex.sandbox\deny_read_acl_state.json

Read-only inspection found that this file contains 22 null bytes instead of valid JSON. I do not know what originally corrupted it.

Feedback/session ID:
01a07d65-2ff2-7b02-be38-50c1caf721b1

What is the expected behavior?

Codex should initialize its browser runtime, connect to Chrome, and return the available tabs so it can read the requested website.

If sandbox state is corrupted, Codex should show an actionable error and provide a supported recovery procedure that preserves sandbox permissions and user data.

Additional information

Chrome integration worked previously on this computer.

The problem also affects ordinary sandboxed shell commands, suggesting a shared sandbox-initialization failure rather than a website-specific issue.

Codex Doctor v0.153.4 reports:
“elevated Windows sandbox provisioning recorded a structured failure”

Restarting Codex and rebooting Windows did not resolve it. No sandbox state files or Windows ACLs have been manually changed.

Please advise how to recover the corrupted sandbox state while preserving existing permissions, project files, and conversation history.

Submitted feedback ID:
01a07d65-2ff2-7b02-be38-50c1caf721b1

Start by tracing Windows sandbox initialization around parsing %USERPROFILE%.codex.sandbox\deny_read_acl_state.json, then reproduce the failure with codex doctor and a sandboxed shell command. Use the reported null-byte state and await cua.getState() failure as the test case; done means recovery handles the corrupted state, preserves permissions and user data, and restores browser and shell startup.