Skip to content

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

Open
Open
Windows sandbox fails all read operations with "apply deny-read ACLs" after power outage#28248
Labels
appIssues related to the Codex desktop appbugSomething isn't workingsandboxIssues related to permissions or sandboxingwindows-osIssues related to Codex on Windows systems

Description

@romansydiuk-dev
romansydiuk-dev
opened on Jun 15, 2026

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

Version 26.609.41114

What subscription do you have?

Plus

What platform is your computer?

Windows 11 x64

What issue are you seeing?

After a power outage during an active Codex task, all file read operations started failing.

Codex can create files and write to them, but cannot read files or even list the current directory.

The following commands fail:

pwd
Get-ChildItem .
Get-Content .\hello.txt
Get-Content C:\Users\advok\Documents\test\test.txt

Node.js also fails:

fs.readFile(...)

Error:

windows sandbox: helper_unknown_error: apply deny-read ACLs

The error occurs before file contents are read.

I already:

  • Reinstalled Codex
  • Created new projects
  • Enabled Full Access
  • Enabled Default Permissions
  • Ran sfc /scannow (found and repaired corrupted Windows files)
  • Ran DISM /Online /Cleanup-Image /RestoreHealth successfully
  • Rebooted multiple times

The issue persists.

What steps can reproduce the bug?

Feedback ID: 019ec94e-896f-73d3-9fe8-9f8620e51be6

  1. Create a new project.
  2. Create hello.txt.
  3. Write HELLO into hello.txt.
  4. Run:

pwd

  1. Run:

Get-ChildItem .

  1. Run:

Get-Content .\hello.txt

Expected:
The file contents should be displayed.

Actual:
All read operations fail with:

windows sandbox: helper_unknown_error: apply deny-read ACLs

Feedback ID:
019ec94e-896f-73d3-9fe8-9f8620e51be6

Image

What is the expected behavior?

No response

Additional information

No response

Activity

  1. romansydiuk-dev
    added
    appIssues related to the Codex desktop app
    on Jun 15, 2026
  2. github-actions
    added
    bugSomething isn't working
    windows-osIssues related to Codex on Windows systems
    sandboxIssues related to permissions or sandboxing
    on Jun 15, 2026

  3. github-actions commented on Jun 15, 2026

    @github-actions
    github-actionsBot
    on Jun 15, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  4. romansydiuk-dev commented on Jun 15, 2026

    @romansydiuk-dev
    romansydiuk-dev
    on Jun 15, 2026
    Author

    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.

  5. romansydiuk-dev commented on Jun 15, 2026

    @romansydiuk-dev
    romansydiuk-dev
    on Jun 15, 2026
    Author

    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

  6. coro-bot commented on Jun 20, 2026

    @coro-bot
    coro-bot
    on Jun 20, 2026

    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

  7. chalkplum commented on Jul 10, 2026

    @chalkplum
    chalkplum
    on Jul 10, 2026

    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

  8. romansydiuk-dev commented on Jul 12, 2026

    @romansydiuk-dev
    romansydiuk-dev
    on Jul 12, 2026
    Author

    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!

  9. zippiguy commented on Jul 27, 2026

    @zippiguy
    zippiguy
    on Jul 27, 2026

    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.

  10. niejiaqiang commented on Aug 2, 2026

    @niejiaqiang
    niejiaqiang
    on Aug 2, 2026 – with ChatGPT Codex Connector

    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.

  11. kecskeslaszlo94 commented on Aug 14, 2026

    @kecskeslaszlo94
    kecskeslaszlo94
    on Aug 14, 2026 – with ChatGPT Codex Connector

    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.

  12. hxguo-ic commented on Aug 15, 2026

    @hxguo-ic
    hxguo-ic
    on Aug 15, 2026

    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

  13. mmcgill commented on Aug 16, 2026

    @mmcgill
    mmcgill
    on Aug 16, 2026

    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.

  14. ryanportfolio
    added a commit that references this issue on Aug 25, 2026

    codex-review: add the corrupted deny-read ACL state row (#93)

    e1c64c3

  15. jakobboss1010-source commented on Sep 1, 2026

    @jakobboss1010-source
    jakobboss1010-source
    on Sep 1, 2026

    I have a ready-to-cherry-pick hardening patch against current main ade0cca that addresses both the observed NUL-filled state file and lost updates when multiple sandbox processes refresh ACL state concurrently.

    The patch makes ACL reconciliation and persistence one cross-process transaction using a named Windows mutex. State is written to a sibling temporary file, flushed and synced, then installed with ReplaceFileW or write-through MoveFileExW. Read handles allow delete sharing so replacement is not blocked. Invalid JSON, including the repeatedly reported 22-byte NUL file, is quarantined and rebuilt instead of permanently blocking every sandboxed command.

    Commit: jakobboss1010-source@3207dcb

    Verification on refreshed main ade0cca:

    • isolated NUL-filled-state quarantine/recovery test passed
    • cargo fmt check clean
    • just fix -p codex-windows-sandbox completed successfully

    The patch also includes regression tests for replacement while a reader is open and for concurrent thread/process updates. Those concurrency tests passed on the original patch base; this refreshed verification did not rerun the deliberate concurrency cases.

    This is intended to replace the manual delete-the-state-file recovery with durable write semantics plus automatic recovery from already-corrupt state.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingsandboxIssues related to permissions or sandboxingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions