›_ Codex Issues
Codex Issues / #35718

Windows: NUL-filled .sandbox/deny_read_acl_state.json permanently breaks sandbox setup and survives reinstall ("Windows setup didn't finish")

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

Summary

A single zero-byte-filled state file permanently breaks Codex sandbox setup, and the failure survives a full uninstall/reinstall because the file lives in CODEX_HOME rather than in the app package. The app then shows the "Finish Windows setup" screen with "Windows setup didn't finish" on every launch, and "Try Windows setup again" fails instantly without ever raising a real UAC prompt.

The underlying trigger is an unclean shutdown (power loss / hard reset) while Codex is running. NTFS records the file's allocated size but never flushes its contents, so on reboot the file exists at its original length and is filled entirely with NUL (0x00) bytes. The JSON/TOML parsers then fail at the first byte.

This appears to be the actual root cause behind several existing reports that were attributed to Windows Home / Windows Sandbox availability, e.g. #28566 and #32492.

Root cause

codex-windows-sandbox-setup.exe reads <CODEX_HOME>/.sandbox/deny_read_acl_state.json unconditionally at startup. When that file is NUL-filled, setup aborts:

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(ExitStatus(1))

expected value at line 1 column 1 is the parser hitting 0x00 as the first byte.

Setup then writes .sandbox/setup_error.json, which persists the failed state so the "setup didn't finish" screen reappears on every subsequent launch — even after the corrupt file itself would otherwise be harmless.

<CODEX_HOME>/config.toml was corrupted the same way in the same event (correct file size, 100% NUL bytes), which independently prevents config load.

Why reinstalling does not help

Remove-AppxPackage removes the package but leaves both CODEX_HOME and the app's per-user LocalCache/LocalState intact. The corrupt state is re-read immediately by the fresh install, so the user sees an identical failure and reasonably concludes the app itself is broken.

Environment

  • Windows 11 Home Single Language, build 10.0.26200 (x64)
  • ChatGPT/Codex desktop app 26.721.4979.0 (also reproduced on 26.715.4045.0)
  • Sandbox marker version: 5; CodexSandboxOffline / CodexSandboxOnline users present and enabled
  • WebView2 Runtime 150.0.4078.99, intact
  • UAC enabled (EnableLUA = 1), user is a local administrator

Worth noting: Windows Sandbox is not the issue here. That optional feature is unavailable on Home SKUs by design, and Codex's own ACL/restricted-token sandbox does not require it. Setup fails purely on the unparseable state file.

Steps to reproduce

  1. Run the Codex desktop app normally so .sandbox/deny_read_acl_state.json exists.
  2. Hard-power-off the machine while the app is running (or simulate: overwrite the file with NUL bytes of the same length).
  3. Boot and launch the app.

Expected: setup detects the unreadable state file, discards it, and regenerates a default.
Actual: setup aborts; "Windows setup didn't finish" appears on every launch; "Try Windows setup again" fails instantly; reinstalling does not clear it.

Minimal simulation of the corrupt state:

$p = "$env:USERPROFILE\.codex\.sandbox\deny_read_acl_state.json"
[System.IO.File]::WriteAllBytes($p, (New-Object byte[] (Get-Item $p).Length))

Workaround

Fully exit the app (including tray), then delete the corrupt state and let it regenerate:

Remove-Item "$env:USERPROFILE\.codex\.sandbox\deny_read_acl_state.json" -Force
Remove-Item "$env:USERPROFILE\.codex\.sandbox\setup_error.json" -Force
# only if it is also NUL-filled:
Remove-Item "$env:USERPROFILE\.codex\config.toml" -Force

Both files regenerate correctly on next launch (deny_read_acl_state.json → {"principals": {}}), setup completes, and the log shows setup binary completed / read ACL run completed / errors=[]. No reinstall required.

To detect the condition:

$p = "$env:USERPROFILE\.codex\.sandbox\deny_read_acl_state.json"
$b = [System.IO.File]::ReadAllBytes($p)
"NUL bytes: $(($b | Where-Object { $_ -eq 0 }).Count) / $($b.Length)"

Suggested fix

  1. Treat an unparseable deny_read_acl_state.json as empty state rather than a fatal error — log a warning, back the file up, and regenerate the default. Nothing in it is unrecoverable; it rebuilds from {"principals": {}}.
  2. Apply the same tolerance to other CODEX_HOME state files corrupted by the same mechanism (config.toml was hit in the same event).
  3. Write these files atomically (write to a temp file, FlushFileBuffers, then rename) so an unclean shutdown leaves either the old or the new content, never a NUL-filled file.
  4. Surface the underlying parse error in the setup UI. The current screen implies a declined UAC prompt, which sends users toward UAC settings, BIOS virtualization, and reinstalls — none of which can fix a corrupt state file.

Related

  • #28566 — "read ACL run had errors" on Windows 11 Home (build 26200); same build, same ACL stage
  • #32492 — setup never triggers a real UAC prompt, Retry fails instantly; matches this failure mode

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 1 month ago

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

  • #34841

Powered by Codex Action

jcqsoluciones · 22 days ago

Additional reproduction after updating the Windows desktop app:

  • Codex desktop app version: 26.730.8199.0
  • Date reproduced: 2026-08-05
  • Environment: fresh local task, managed workspace-write profile
  • Workspace and temp were declared writable; runtime was readable
  • A minimal read-only PowerShell command never started. The task failed during sandbox preparation with:

windows sandbox: helper_unknown_error: apply deny-read ACLs

  • A separate Chrome-control attempt also failed before connecting. The Node REPL kernel exited with code 1 and stderr:

windows sandbox failed: helper_unknown_error: apply deny-read ACLs

  • The failure therefore occurs before the requested executable or Chrome session starts and is scoped to Windows sandbox initialization, not to the target workspace or browser.
  • No broad ACL changes, sandbox-user changes, or personal-file changes were attempted.
  • The task cannot inspect deny_read_acl_state.json from inside the sandbox because every local process is terminated at the same pre-launch ACL stage.

This confirms the issue still reproduces on 26.730.8199.0 and blocks both local shell tools and Chrome-control tooling in a newly created local task.

Archeo3012 · 20 days ago

Workaround that fixed the “Windows setup was not completed” issue for me

Codex App version: 26.803.5235.0

What worked:

  1. Fully close the Codex app, including any remaining Codex processes.
  2. Delete the entire %USERPROFILE%\.codex folder.
  3. Delete the OpenAI/Codex app data under %AppData% / %LocalAppData%.
  4. Start Codex again.
  5. Sign in again.
  6. Run the Windows setup again.

After doing this, the Windows setup completed successfully.

Renaming/deleting only .codex\.sandbox and .codex\.sandbox-bin did not fix it for me. A full reset of the .codex folder and the OpenAI app data was required.

Note: this resets local Codex settings/cache and requires signing in again, so back up anything important from .codex first.

juansoriano · 13 days ago

Follow-up / resolution from my Windows machine.

This is the same machine from my earlier reproduction comment on this issue. I was able to isolate and resolve the failure without changing the repository ACLs or reinstalling Codex.

Symptoms

  • Every sandboxed filesystem operation failed during setup with:

windows sandbox: helper_unknown_error: apply deny-read ACLs

  • Creating a file could sometimes succeed, but subsequent sandboxed read/modify/delete operations failed.
  • The same files were readable and removable outside the Codex sandbox, which ruled out normal workspace permissions.
  • A fresh project/workspace showed the same behavior, so the failure was not repository-specific.

ACL checks

CodexSandboxUsers had only RX on %USERPROFILE%\.codex, but .codex\.sandbox had an explicit inheritable Modify grant. The state file also inherited Modify. There were no explicit Deny entries on these paths.

So this was not caused by missing write permission on .codex\.sandbox.

State-file finding

%USERPROFILE%\.codex\.sandbox\deny_read_acl_state.json existed with a length of 22 bytes, but:

Get-Content "$env:USERPROFILE\.codex\.sandbox\deny_read_acl_state.json" -Raw |
    ConvertFrom-Json

failed with:

ConvertFrom-Json : Invalid JSON primitive

The file therefore was not valid JSON even though its length matched the normal empty-state file size.

Recovery

After fully closing Codex, I removed/renamed the corrupted sandbox ACL-state file and let Codex regenerate it. After restarting Codex, sandboxed read/write/modify/delete operations worked normally again.

No recursive ACL reset, repository permission change, reinstall, or full %USERPROFILE%\.codex reset was required.

This strongly corroborates the diagnosis in this issue and #34841: a malformed deny_read_acl_state.json can make the Windows sandbox fail globally before the requested command starts, while normal Windows access remains healthy.

For future users, checking whether this file parses as JSON before changing repository ACLs may prevent unnecessary permission changes.

ProfeDavid-AI · 6 days ago

Additional Windows reproduction + successful recovery. This case may be useful because deny_read_acl_state.json was not present; the NUL-filled file was config.toml.

Environment / trigger

  • Windows 11 x64, Codex/ChatGPT Windows desktop app; app had previously been working normally.
  • The machine experienced an abrupt BSOD while the app was open: DRIVER_IRQL_NOT_LESS_OR_EQUAL (0xD1), faulting driver rtux64w10.sys (Realtek USB GbE driver).
  • After the reboot, Codex repeatedly showed "Windows setup didn't finish" / "Try Windows setup again".
  • Continue with limited access allowed the UI/workspace to load, but the Windows setup error banner remained.
  • The same setup error still reproduced later with the USB Ethernet adapter physically disconnected and the machine using Wi-Fi only, so the network adapter was not required to reproduce the post-crash setup loop.

Diagnostics

A PowerShell byte check of the relevant files returned:

%USERPROFILE%\.codex\.sandbox\deny_read_acl_state.json   NOT PRESENT
%USERPROFILE%\.codex\.sandbox\setup_error.json         176 bytes / 0 NUL
%USERPROFILE%\.codex\config.toml                        3883 bytes / 3883 NUL

So config.toml retained a non-zero length but was 100% NUL bytes after the unclean shutdown.

Recovery

With Codex fully closed:

  1. Renamed %USERPROFILE%\.codex\config.toml to a backup name.
  2. Renamed %USERPROFILE%\.codex\.sandbox\setup_error.json to a backup name.
  3. Rebooted Windows.
  4. Relaunched Codex and allowed it to regenerate its configuration.

Result: the app opened normally with no Windows setup error. I fully closed and reopened the app three times and the fix persisted.

Observation

This appears to corroborate the unclean-shutdown/NUL-fill failure mode described in this issue, but in this reproduction deny_read_acl_state.json was absent and the clearly corrupted file was config.toml. Because setup_error.json was also moved during recovery, I cannot prove that config.toml alone was sufficient to keep the setup loop active.

It may be worth validating/recovering NUL-filled or unparsable config.toml at startup and surfacing a configuration-corruption error instead of routing the failure into the generic Windows setup screen. Atomic config writes (temp file + replace) may also help reduce exposure to abrupt shutdowns.

naipi11 · 6 days ago

If the Windows setup error started after a power loss or hard reset, first check for a corrupted Codex state file rather than reinstalling:

  1. Fully exit Codex, including the tray process.
  2. Back up the affected sandbox state/config files.
  3. Confirm that the sandbox state file is not valid JSON or is filled with NUL bytes. If config.toml is also unreadable, treat it as a separate corrupted file.
  4. Rename only the confirmed-corrupt file(s), leaving the rest of CODEX_HOME intact.
  5. Relaunch Codex and let Windows setup regenerate the defaults.
  6. Verify that setup completes and a normal sandboxed read/write test works.

Do not delete the entire Codex data directory, change repository ACLs, or reinstall before checking this condition. This is only applicable when the file is demonstrably corrupt; otherwise stop and preserve the state for diagnosis.