Windows sandbox fails all read operations with "apply deny-read ACLs" after power outage

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

• #27672
• #27889

Powered by Codex Action

This may be related to issue #27889.

Both issues appear to fail during Windows ACL operations.

My sandbox starts, but any read operation fails:

pwd
Get-ChildItem .
Get-Content .\hello.txt

All return:

windows sandbox: helper_unknown_error: apply deny-read ACLs

Unlike #27889, I do not use elevated sandbox mode and the issue started immediately after a power outage during an active Codex task.

After a power outage the issue persists across:

Codex reinstall
New projects
Full Access enabled
Windows SFC repair
DISM RestoreHealth
Multiple reboots

The sandbox cannot even execute:

pwd
Get-ChildItem .

Every operation fails with:

windows sandbox: helper_unknown_error: apply deny-read ACLs

I experienced this myself after a system crash while using vscode+codex
Symptoms:
<setup_error.json>

{
  "code": "helper_unknown_error",
  "message": "apply deny-read ACLs"
}

<sandbox{date}.log>

Caused by:
    0: parse deny-read ACL state C:\Users\{user}\.codex\.sandbox\deny_read_acl_state.json

I reviewed deny_read_acl_state.json and the file was empty filled with NULLs and malformed.
This points to the implementation of the sandbox not validating the ACL config files upon initialization and remedying the issue by rebuilding if it is malformed or missing. This shouldn't persist through resets and reinstalls.

Easy fix: delete .codex/.sandbox/deny_read_acl_state.json

can confirm on windows 10 started getting the same error: apply deny-read ACLs

deleting file at: $HOME\.codex\.sandbox\deny_read_acl_state.json

resolved the issue

Thank you so much! This fixed the issue completely.
I had been struggling with this for over a month and tried reinstalling Codex, SFC, DISM, changing permissions, and everything else.

Deleting deny_read_acl_state.json immediately resolved it.

Really appreciate you taking the time to investigate this and share the fix!

Confirmed the same issue and recovery on Codex Desktop for Windows.

Every sandboxed command failed before execution with:

windows sandbox: helper_unknown_error: apply deny-read ACLs

The affected file was:

C:\Users\YOUR_USERNAME\\.codex\.sandbox\deny_read_acl_state.json

It was exactly 22 bytes long, matching the reported NUL-byte corruption.

For a recoverable fix, I fully preserved the corrupted file by renaming it to:

deny_read_acl_state-corrupt_backup.json

I then fully exited Codex using File > Exit and reopened it.

After restarting Codex, direct read-only PowerShell commands worked normally again, including Get-Content against the previously inaccessible workspace. The sandbox error is resolved.

*** It would be helpful if Codex detected malformed, empty, or NUL-filled deny_read_acl_state.json files during startup and automatically rebuild them instead of permanently blocking sandbox initialization.

Independent confirmation that this issue is still present on Codex Desktop MSIX 26.727.6591.0 / bundled runner 0.146.0-alpha.9.2.

The affected file was:

%USERPROFILE%\.codex\.sandbox\deny_read_acl_state.json

It was exactly 22 bytes long and every byte was 0x00. The sandbox log repeatedly reported:

setup error: apply deny-read ACLs
Caused by:
    0: parse deny-read ACL state %USERPROFILE%\.codex\.sandbox\deny_read_acl_state.json

I preserved the corrupt file, replaced it with a valid empty state object, and then observed repeated setup refreshes complete with:

setup refresh: processed 3 write roots (read roots delegated); errors=[]

No reinstall or database repair was required. This is consistent with a state-write durability problem: notably, the NUL-filled file has the same 22-byte length as the formatted empty state currently written by Codex.

Suggested hardening:

1. Write the state to a sibling temporary file.
2. Flush it and atomically replace the destination.
3. On startup, treat empty, NUL-filled, or invalid JSON as recoverable state and rebuild it instead of blocking every sandboxed command.
4. Add a regression test that simulates interruption after file sizing but before payload persistence.

All usernames, machine names, project paths, SIDs, task/thread IDs, and business command text have been removed.

I can reproduce this on Windows in the Codex desktop environment after a recent update. CDP is enabled, but both the local PowerShell command runner and the Node/Computer Use bridge fail before user code runs with: windows sandbox failed: helper_unknown_error: apply deny-read ACLs. Browser/CDP control is unavailable as a consequence. Restarting/retrying did not resolve it. This also prevents mouse/desktop control from starting. Please investigate the Windows sandbox/helper regression.

The same issue was encountered. Here is the report generated by AI after it fixed the problem after referencing this issue.

ENVIRONMENT

• Codex Desktop: 26.810.7004.0
• Codex command runner: 0.148.0-alpha.9
• Browser plugin: 26.810.52044
• Browser Use Node.js runtime: v24.19.0
• Operating system: Windows 11
• Sandbox mode: workspace-write
• Incident date: 2026-08-16

ERROR

Sandboxed commands and Browser Use failed with:

windows sandbox failed: helper_unknown_error: apply deny-read ACLs

The sandbox log showed:

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

CAUSE

deny_read_acl_state.json was corrupted. It was 22 bytes long and contained 22 NUL (0x00) bytes instead of valid JSON.

FIX

Back up and remove the corrupted files from their active location:

$codexSandboxDir = Join-Path $env:USERPROFILE ".codex\.sandbox"
$backupDir = Join-Path $codexSandboxDir "recovery-backup"

New-Item -ItemType Directory -Path $backupDir -Force | Out-Null

Move-Item `
  (Join-Path $codexSandboxDir "deny_read_acl_state.json") `
  $backupDir

Move-Item `
  (Join-Path $codexSandboxDir "setup_error.json") `
  $backupDir

Codex then regenerated:

{
  "principals": {}
}

RESULT

Normal sandboxed commands worked again, but the first Browser Use retry failed with:

Error: EPERM: operation not permitted, lstat
'%USERPROFILE%\AppData'

CAUSE

The sandbox was still applying the required read permission to AppData. The log showed:

granting read ACE to %USERPROFILE%\AppData for sandbox users
read ACL run completed

This appears to be a timing issue during the first sandbox initialization after state regeneration.

FIX

Wait for the ACL refresh to finish and retry Browser Use. No manual ACL reset was required.

RESULT

The second Browser Use attempt succeeded.

Final status:

• Sandboxed commands: working
• Regenerated ACL state: valid JSON
• Sandbox setup: errors=[]
• Browser Use runtime: working
• In-app browser navigation: working

I just hit this one too -- power outage in the middle of a Codex session, upon restart the sandbox was broken. Error message led straight to this issue, and after renaming %USERPROFILE%\.codex\.sandbox\deny_read_acl_state.json (which was just 22 NULs) and restarting VS Code we're up and running again.

Environment: Windows 10 Home 25H2, build 26200.9168; VS Code 1.133.0 x64; Codex extension openai.chatgpt 26.810.52044; PowerShell.