›_ Codex Issues
Codex Issues / #30251

Windows sandbox state file corrupted with NUL bytes, causing repeated ACL/permission failures

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

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

26.616.81150

What subscription do you have?

Plus

What platform is your computer?

Windows 10

What issue are you seeing?

Codex Desktop on Windows got stuck with repeated sandbox ACL / permission failures for normal workspace operations.

Symptoms:

  • Repeated approvals / blocks for normal workspace operations
  • Local image reads failed with Windows sandbox ACL errors
  • Some files were reported as owned by CodexSandboxOffline
  • %USERPROFILE%\.codex\.sandbox\deny_read_acl_state.json was filled with NUL bytes instead of valid JSON

What steps can reproduce the bug?

I do not have exact repro steps, but I believe it happened after cancelling/stopping prompts while Codex was doing image generation / local image inspection / file editing.

Manually adding deny_read_acl_state.json filled with null bytes could potentially reproduce the issue.

What is the expected behavior?

Cancelling a prompt should not leave persistent corrupted Windows sandbox state. If deny_read_acl_state.json is invalid, Codex should detect that and regenerate it automatically.

Additional information

_No response_

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 2 months ago

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

  • #29867
  • #29593
  • #30084

Powered by Codex Action

Nicolas0315 · 2 months ago

I put up a focused branch for the corrupted deny_read_acl_state.json path: https://github.com/openai/codex/compare/main...Nicolas0315:codex:codex/windows-deny-read-state-recover

Commit: d0618f3ebc2c8554cd13e0b1e12b59ecb8b1eb45

What changed:

  • The generated Windows deny-read ACL state loader now treats malformed state JSON, including NUL-filled files, as empty state instead of failing sandbox setup repeatedly.
  • State persistence now writes through a same-directory temporary file and atomically replaces the state file, reducing the truncate/partial-write window for future updates.
  • Added regression coverage for loading a NUL-filled state file and replacing a corrupt file with valid JSON.

Validation:

  • Local rtx4090: just fmt, git diff --check, targeted new tests -> 2/2 passed; just test -p codex-windows-sandbox -> 130/130 passed, 2 skipped.
  • cyberagent-mac-m5max over SSH at the exact commit: git diff --check HEAD~1 HEAD, just test -p codex-windows-sandbox -> 10/10 passed on macOS-exposed tests.
  • nicolas2025 over SSH at the exact commit: git diff --check HEAD~1 HEAD, cargo test -p codex-windows-sandbox deny_read_state::tests -> 2/2 passed. A full cargo test -p codex-windows-sandbox on this host compiled and ran the new tests successfully, but later failed in unrelated legacy unified-exec process tests (legacy_capture_* / legacy_non_tty_*) that are outside this state-file path.
  • nicolas-macbook-pro over SSH at the exact commit: git diff --check HEAD~1 HEAD passed; Rust tests skipped because cargo is not installed on that host.
  • rtx5060ti over SSH at the exact commit: git diff --check HEAD~1 HEAD passed; Rust tests skipped due the known local MSVC linker configuration issue on that host.

Remaining caveat: once the state file is already unrecoverably corrupt, Codex cannot know the old per-SID path inventory from that file. This patch prioritizes regenerating usable state so sandbox setup can proceed and future writes are valid/atomic.

f-pound · 12 days ago

I hit the same failure on Codex Desktop for Windows, and can add a diagnostic-cost/recovery data point.

Environment

  • Windows 10 Pro 22H2, build 19045.7548, x64
  • Failure first recorded with app package 26.730.7989.0
  • Still reproduced with app package 26.803.8161.0 / runner 0.147.0-alpha.6.5

Captured state

The preserved file is exactly 22 NUL bytes:

00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
SHA-256: 6A4875DDACEAA91FB3369F0F6D962F77442DAF1B1D97733457D12BCABDF79441

The first parse failure in my retained logs is 2026-08-05 13:22:46 UTC. The same corrupt file was still aborting setup on 2026-08-16 02:12:43 UTC. Across those two daily logs there are 200 parse deny-read ACL state entries. The internal log identifies the file and parser error:

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

But the user/tool-facing failure was only helper_unknown_error: apply deny-read ACLs. Because this occurs before the requested process starts, that message strongly suggests workspace or endpoint ACL trouble and can drive a long investigation of unrelated repository ACLs, installer/uninstaller code, service code, test harnesses, and NTFS/event logs.

Quarantining the file and retrying immediately regenerated the valid 22-byte state:

{
  "principals": {}
}

The next log entries show processed 3 write roots ... errors=[], setup binary completed, and read ACL run completed.

This reinforces four changes already suggested here and in related reports:

  1. Treat unparseable reconstructible state as absent.
  2. Quarantine it automatically and regenerate.
  3. Surface the failing state path/parser error in the user-visible error.
  4. Persist with an interprocess transaction lock plus durable atomic replacement.

I can provide the preserved corrupt file and private raw sandbox logs to OpenAI support if useful; I am not attaching the raw logs publicly because they contain local paths and command text.