›_ Codex Issues
Codex Issues / #34841

Windows sandbox cannot recover when `deny_read_acl_state.json` becomes 22 NUL bytes after a system crash

Open 💬 5 comments Opened Jul 22, 2026 by sajidfarooq
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Product and environment

  • Codex desktop app on native Windows
  • Observed app package: OpenAI.Codex_26.715.8383.0_x64
  • Windows 11 25H2, build 26200.8875
  • Sandbox mode: ordinary native-Windows workspace-write execution
  • State path: %USERPROFILE%\.codex\.sandbox\deny_read_acl_state.json

Problem

After a Windows kernel crash, the Codex Windows sandbox can become persistently unusable because deny_read_acl_state.json contains exactly 22 zero bytes rather than JSON. Every ordinary sandbox setup tries to deserialize or reconcile this state and fails before the requested command process starts. Execution outside the sandbox still works because it bypasses this setup path.

This has now occurred three times on the same machine. Renaming the malformed file allows the next ordinary sandbox setup to regenerate valid state immediately, confirming that the requested command and repository are not the cause.

The upstream machine crashes are a separate Microsoft Wof.sys issue. This Codex report is about durability and recovery: an external crash can leave a reconstructible state artifact malformed, and Codex then turns that artifact into a persistent outage for every future sandboxed command.

Observed error and file contents

Ordinary commands fail before PowerShell or the requested process starts:

windows sandbox: helper_unknown_error: apply deny-read ACLs

The malformed file is:

Length: 22 bytes
Hex:    00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00

The intended empty serialized state is also 22 bytes:

{
  "principals": {}
}

Reproduction using captured state

  1. Place a captured 22-NUL deny_read_acl_state.json at the state path.
  2. Run any ordinary sandboxed command from a valid workspace.
  3. Observe that sandbox setup fails before the requested process starts.
  4. Preserve and rename the malformed file.
  5. Run an ordinary sandboxed command again.
  6. Codex regenerates a valid 22-byte JSON file and the command starts successfully.

This recovery has been repeated after multiple crashes.

Evidence from three incidents

| Incident | State length | State content | Write-to-reboot interval | Result after reboot |
|---|---:|---|---:|---|
| 1 | 22 bytes | all NUL | ~20.6 seconds | every ordinary sandbox setup failed |
| 2 | 22 bytes | all NUL | ~17.3 seconds | same |
| 3 | 22 bytes | all NUL | 17.364 seconds | same |

The first two Windows minidumps independently identify the upstream crashes as bugcheck 0x139/A in Wof!WofPreDirectoryControlCallback+0x695, with the same Microsoft failure hash. The third Windows event is also 0x139/A; its dump has not yet been independently analyzed. Those kernel details establish the external-crash context, but they are not required to reproduce Codex's malformed-state failure.

Relevant implementation

The current Windows deny-read state implementation serializes with serde_json::to_vec_pretty and persists using a direct std::fs::write(path, bytes):

codex-rs/windows-sandbox-rs/src/deny_read_state.rs

The observed implementation does not provide:

  • same-directory temporary-file creation followed by atomic replacement;
  • explicit durable flushing before publication;
  • validation of the newly written file before replacing the prior state;
  • malformed-state quarantine and safe reconstruction;
  • an interprocess lock around state reconciliation.

Regardless of the upstream kernel fault, a malformed reconstructible state file should not permanently disable sandbox setup.

Expected behavior

  • A crash during or shortly after persistence should leave either the previous valid state or a complete new state.
  • If state is malformed, setup should quarantine it for diagnostics, reconstruct safe state, and continue or emit a targeted actionable diagnostic.
  • A corrupt reconstructible state artifact should not prevent every sandboxed command from launching indefinitely.

Requested fix

  1. Serialize and validate the complete next state in memory.
  2. Write it to a unique temporary file in the same directory.
  3. Flush the temporary file durably (sync_all or the appropriate Windows equivalent).
  4. Atomically replace the destination while preserving the previous valid file until publication.
  5. Coordinate writers with an interprocess mutex or equivalent lock.
  6. On deserialization failure, quarantine the malformed file and safely reconstruct state.
  7. Report a specific malformed-state diagnostic rather than the generic ACL-application error.

Privacy

This public report intentionally excludes usernames, repository names and paths, thread IDs, raw dumps, .codex databases, sandbox logs, credentials, and secrets. Sanitized debugger conclusions can be supplied publicly; raw evidence can be offered to OpenAI through a private channel if requested.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 1 month ago

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

  • #34276

Powered by Codex Action

sajidfarooq · 1 month ago

The primary addition this report provides is the “why it happens”. I have provided concrete evidence that it happens when windows crashes. I have also provided the fix. This should help prevent it in the future.
I have separately provided Microsoft with the relevant report on the Windows crash.

Spiralis · 1 month ago

Independent confirmation from another native Windows Codex Desktop machine.

Environment

  • Windows: Microsoft Windows NT 10.0.26200.0
  • Current Codex app package: 26.715.10079.0
  • Codex app package recorded in the incident-period sandbox log: 26.715.3651.0
  • Sandbox: native Windows workspace-write/elevated backend

Timeline and evidence

All times below are local (Europe/Oslo) on 2026-07-18:

  • Around 01:40:13, the active Codex sandbox log output became NUL-filled while the helper was updating sandbox state.
  • deny_read_acl_state.json received a last-write timestamp of 01:40:15.
  • Windows then recorded an unexpected restart/Kernel-Power event and bugcheck around 01:40:45.
  • After reboot, every ordinary sandboxed process failed before the requested command started. The failure persisted across app restarts and app updates until 2026-07-23.

The repeated error was:

setup error: apply deny-read ACLs

Caused by:
  0: parse deny-read ACL state <USERPROFILE>\.codex\.sandbox\deny_read_acl_state.json
  1: expected value at line 1 column 1

The preserved malformed state has:

Length:        22 bytes
Non-zero bytes: 0
SHA-256:       6A4875DDACEAA91FB3369F0F6D962F77442DAF1B1D97733457D12BCABDF79441

It contains no paths, usernames, credentials, tokens, or other data—only 22 NUL bytes. The file can be supplied if useful, although the size, hash, and byte description fully characterize it.

Recovery confirmation

Moving only the malformed state file to a .bak path allowed the next ordinary sandbox setup to regenerate:

{
  "principals": {}
}

setup_error.json disappeared, and ordinary sandboxed PowerShell, Git reads, rg, Node, and workspace writes immediately succeeded again. A disposable write probe was created and removed successfully.

This independently confirms that:

  1. the failure is machine-global sandbox state, not a particular repository, drive, or worktree;
  2. a separate worktree cannot avoid it because setup fails before the requested workspace process starts;
  3. malformed-state quarantine/reconstruction is needed even if atomic replacement and writer locking prevent future corruption.

I did not analyze the Windows minidump; the relevant Codex defect is the persistent outage caused by failure to recover reconstructible local state. This also corroborates the recovery behavior described in #34276.

Spiralis · 1 month ago

Follow-up from the same Windows machine after recovering the corrupt ACL-state file: I hit a second, reproducible workspace-write failure that may help isolate the ACL refresh path.

Inside a Codex-managed Git worktree declared as the writable root:

  1. An existing tracked file could be rewritten by a sandboxed formatter.
  2. A file newly created by Codex apply_patch in the same directory could be read but not rewritten by the same formatter:
EPERM: operation not permitted, open '<worktree>\services\web-app\src\routes\index.tsx'
  1. icacls showed that the parent directory had an inheritable (OI)(CI)(M) workspace-grant ACE and the pre-existing file had the corresponding inherited (I)(M) ACE. The newly created/replaced file was missing only that workspace-grant ACE; its normal CodexSandboxUsers:(I)(M) and other inherited entries were present.
  2. A second tracked file in the same formatter invocation (one that existed before the session) formatted successfully.
  3. Re-running only the formatter outside the sandbox succeeded immediately.

This looks consistent with apply_patch creating or atomically replacing a file with a DACL that does not retain the per-workspace grant marker, even though the parent ACE is inheritable. It also explains why using a separate worktree did not eliminate all sandbox failures: Git isolation was correct, but the newly created files themselves became unwritable to later sandboxed processes.

I redacted machine-local account names and SIDs here; I can provide the full icacls before/after output if useful.

ashjo42 · 22 days ago

Confirming the exact 22-NUL corruption and persistent recovery failure on a newer Codex Desktop build, with explicit user approval to share these sanitized diagnostics.

Environment:

  • Windows 11 Pro, version 10.0.26200 (build 26200), x64
  • Codex Desktop MSIX: OpenAI.Codex_26.730.8199.0_x64
  • Custom CODEX_HOME on a local NTFS drive

Current state:

  • .sandbox/deny_read_acl_state.json length: 22 bytes
  • All 22 bytes are 0x00
  • SHA-256: 6A4875DDACEAA91FB3369F0F6D962F77442DAF1B1D97733457D12BCABDF79441
  • Last write: 2026-08-04 14:15 local time
  • The failure persists across Codex Desktop restarts.

The sandbox 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: expected value at line 1 column 1

setup refresh: exited with status ExitStatus(1)

On 2026-08-06 the same sequence recurred many times during command startup/refresh. The sandbox never recovers or quarantines/regenerates the reconstructible state file.

User-visible impact in Desktop:

  • Ordinary sandboxed commands fail before the requested process starts.
  • The agent retries through escalation, producing a repeated approval-dialog loop.
  • Restarting the app does not recover it.
  • Unattended work becomes impossible.

This machine also shows the permission-persistence symptom in #36497: after restart, active tasks are effectively workspace-write/on-request despite selecting Full access, which makes the corrupt-state retry path especially visible as repeated approvals.

No credentials, transcripts, databases, usernames, thread IDs, or private project paths are attached.