Windows: NUL-filled deny_read_acl_state.json prevents Computer Use and exec startup (0.153.4)

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

Installed Windows package: OpenAI.Codex 26.901.6511.0 (queried with Get-AppxPackage).
The running app's bundled binary reports codex-cli 0.153.4.

What subscription do you have?

Not provided.

What platform is your computer?

Windows 11 Pro, 64-bit, OS version 10.0.26200, build 26200.
Native Windows sandbox configured as elevated.

What issue are you seeing?

A corrupt %USERPROFILE%\.codex\.sandbox\deny_read_acl_state.json prevents both ordinary shell commands and the Computer Use JavaScript runtime from starting. The UI plugin can be enabled and the user can authorize computer control, but the runtime exits before it can enumerate windows or capture a screenshot.

This matches existing reports #34841 and #39453. This report records a confirmed occurrence on the versions above, the Computer Use impact, and a tested recovery. The event that originally corrupted the file is unknown; a crash or power loss was not established in this case.

An ordinary Get-Location command failed before its process started:

Failed to create unified exec process:
helper_unknown_error: apply deny-read ACLs

Computer Use initialization failed as well:

node_repl kernel exited unexpectedly
kernel_status: exited(code=1)
kernel_stderr_tail:
windows sandbox failed: helper_unknown_error: apply deny-read ACLs

The dated sandbox log exposed the underlying error:

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

The state file was exactly 22 bytes, all 0x00 (zero nonzero bytes). Its SHA-256 was:

6A4875DDACEAA91FB3369F0F6D962F77442DAF1B1D97733457D12BCABDF79441

What steps can reproduce the bug?

Observed sequence, using the naturally corrupted state file rather than deliberately damaging a working installation:

1. Attempt an ordinary sandboxed command from a valid writable workspace.
2. It fails with apply deny-read ACLs before command execution.
3. Reset and initialize the Computer Use JavaScript runtime. It fails with the same sandbox error before importing the Windows-control API.
4. Inspect the dated sandbox log and the state file using an approved diagnostic command. The log reports a JSON parse failure, and the file contains only NUL bytes.
5. Preserve the corrupt state file and allow the regular sandbox setup to regenerate its state as described below.
6. Retry the same ordinary shell command and Computer Use initialization. Both now work.

What is the expected behavior?

The error should identify the malformed state file and provide an actionable recovery path. The sandbox should safely recover from corrupted bookkeeping state without disabling its permission boundaries, or provide a supported repair operation when automatic reconstruction would not be safe.

State persistence should protect against incomplete writes and coordinate concurrent writers. These are proposed hardening measures, not a claim that a particular corruption mechanism was proved here.

Additional information

Confirmed recovery on this machine:

1. Copied the malformed file to a separate backup and verified matching SHA-256 hashes.
2. Renamed only the malformed state file to a unique quarantine filename in its existing directory.
3. Ran an ordinary sandboxed Get-Location again. The regular setup regenerated valid state and the command succeeded.
4. Confirmed the new state was valid JSON:

{
  "principals": {}
}

5. Reset and initialized the Computer Use JavaScript runtime again. Initialization, app enumeration, and a target-window screenshot succeeded.

The sandbox mode, permission profile, and Codex configuration were not changed. No manual Windows ACL modification or security disabling was used. The original damaged bytes were retained. This is a verified local workaround; an upstream code fix has not been tested.

Only sanitized excerpts are included. No private task content, credentials, full logs, local databases, or sandbox secrets are attached.

Start by tracing the Windows sandbox setup that parses %USERPROFILE%.codex.sandbox\deny_read_acl_state.json, using the dated sandbox log and the reported NUL-filled file as the failure case. Determine how malformed state is reported or regenerated, then verify that ordinary sandbox commands and Computer Use initialization recover without weakening permission boundaries.