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

[romansydiuk-dev]

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

5. Run:

Get-ChildItem .

6. 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

What is the expected behavior?

No response

Additional information

No response

[github-actions]

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

• ACL bug #27672
• Windows elevated sandbox setup fails after Codex Desktop 26.609 update/reinstall: SetNamedSecurityInfoW failed: 5 on WindowsApps package directory #27889

Powered by Codex Action

[romansydiuk-dev]

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.

[romansydiuk-dev]

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

[coro-bot]

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

[chalkplum]

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

[romansydiuk-dev]

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!

[zippiguy]

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.

[niejiaqiang]

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.