›_ Codex Issues
Codex Issues / #36087

Windows sandbox fails with helper_unknown_error: apply deny-read ACLs in workspace-write mode

Open 💬 8 comments Opened Jul 30, 2026 by akiyastudio
💡 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.721.81911

What subscription do you have?

Pro

What platform is your computer?

OS: Windows 11 Pro, 64-bit

What issue are you seeing?

Description

Codex Desktop on Windows intermittently fails to initialize the filesystem sandbox for a normal writable workspace.

Sandboxed shell commands and apply_patch fail with:

windows sandbox: helper_unknown_error: apply deny-read ACLs

The workspace itself is readable and writable outside the sandbox. The same read/write test succeeds when executed with escalated sandbox permissions.
The problem persists after:
Moving the repository to a new directory with normal inherited Windows permissions.
Adding the new directory as the project folder.
Fully exiting and restarting the Codex Desktop application.

Environment

  • Codex Desktop package version: 26.721.11231.0
  • OS: Windows 11 Pro, 64-bit
  • Windows version: 10.0.26200
  • Windows build: 26200
  • Shell: PowerShell
  • Workspace: C:\dev\app1
  • Sandbox mode: workspace-write
  • The workspace is included in the configured writable roots.

What steps can reproduce the bug?

Open Codex Desktop on Windows.

Open a local Git repository under C:\dev\app1.

Run a simple read-only command in the normal sandbox, for example:

Get-Content -LiteralPath .\package.json -TotalCount 1

Observe that the command fails before normal execution with:

windows sandbox: helper_unknown_error: apply deny-read ACLs

Try creating a small file with apply_patch.

In some attempts, the first patch succeeds, but a subsequent patch that reads or deletes the same file fails with the same sandbox error.

Run an equivalent read/write/delete test with escalated sandbox permissions. It succeeds.

What is the expected behavior?

Actual behavior

Normal sandbox operations fail during sandbox initialization:

execution error: Io(Custom {
  kind: Other,
  error: "windows sandbox: helper_unknown_error: apply deny-read ACLs"
})

A representative apply_patch failure is:

apply_patch verification failed:
Failed to read C:\dev\app1\.codex-patch-test.txt:
fs sandbox helper failed with status exit code: 1:
windows sandbox failed: helper_unknown_error: apply deny-read ACLs

The behavior is inconsistent: one apply_patch call may create a file successfully, while the immediately following patch fails to read or delete it.

Expected behavior

Sandboxed read and write operations should work consistently for files inside a configured writable workspace.
apply_patch should be able to create, read, update, and delete workspace files without requiring escalated execution.
Filesystem verification
A direct read/write/read-back/delete test performed outside the failing sandbox succeeded:

ExistingFileRead : {
WriteReadMatch   : True
Created          : True
CleanedUp        : True

The workspace has standard inherited Windows permissions:

BUILTIN\Administrators: Full control
NT AUTHORITY\SYSTEM: Full control
BUILTIN\Users: Read and execute
NT AUTHORITY\Authenticated Users: Modify

Therefore, the underlying workspace is accessible and writable; the failure appears to occur while the sandbox helper is applying its deny-read ACL rules.

Additional information

Additional observations

  • The same error occurred in the repository’s previous directory.
  • Moving the complete repository to a fresh project directory did not resolve it.
  • Fully restarting Codex Desktop did not resolve it.
  • Read-only commands may remain pending for tens of seconds before returning the sandbox initialization error.
  • Escalated commands can read and write the same workspace successfully.
  • No project source files were changed while diagnosing the issue; only uniquely named temporary test files were used and then removed.

Impact

The issue prevents reliable source editing because normal shell commands and apply_patch cannot consistently operate inside the workspace sandbox. Read-only inspection can be performed with escalation, but the standard safe patch workflow is unusable.

View original on GitHub ↗

8 Comments

github-actions[bot] contributor · 29 days ago

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

  • #35893
  • #35718

Powered by Codex Action

gaoshanyan1-oss · 28 days ago

Additional affected-user report (anonymized):

  • ChatGPT/Codex Desktop version shown in About: 26.721.81911 (Windows 11)
  • Every sandboxed local operation fails before the child process starts with: windows sandbox: helper_unknown_error: apply deny-read ACLs
  • Reproduced with a read-only PowerShell check, Node REPL startup, and apply_patch
  • Reproduced in both an existing local workspace and a newly created clean/projectless task
  • Fully restarting the app and rebooting Windows did not resolve it
  • The same local HTML files remain accessible directly in Chrome, so the files exist and ordinary host access is working
  • No project files were changed while diagnosing the failure

This may be a Windows ACL sandbox initialization regression in this desktop build. A recovery mechanism or official workaround would be very helpful.

kecskeslaszlo94 · 13 days ago

Additional reproduction on Codex Desktop 26.810.41047 (released 2026-08-13), Windows. With CDP enabled, the local PowerShell runner and Node/Computer Use bridge still fail before user code with windows sandbox: helper_unknown_error: apply deny-read ACLs; browser and mouse control are consequently unavailable. This persists on a newer desktop build than the original report.

tico0505 · 12 days ago

I can reproduce the same failure in Codex Desktop on Windows, with an additional create-then-update pattern that may help isolate the helper path.

Environment

  • Codex Desktop package: 26.810.7004.0
  • Windows 10 Pro 22H2, build 19045.6466
  • PowerShell
  • Runtime sandbox mode: workspace-write
  • Native Windows sandbox config: [windows] sandbox = "elevated"
  • Workspace is a configured writable root on D:\<workspace>

Minimal reproduction

  1. Confirm a uniquely named temporary file does not exist.
  2. Use apply_patch to create it with the content probe-step-created.
  3. Verify the file exists and can be read: creation succeeds.
  4. Immediately use apply_patch to replace that line with probe-step-modified.

The second patch fails before applying the edit:

apply_patch verification failed: Failed to read file to update
D:\<workspace>\.codex-apply-patch-probe-3.tmp:
fs sandbox helper failed with status exit code: 1:
windows sandbox failed: helper_unknown_error: apply deny-read ACLs

The modification is not applied; the original 19-byte content remains intact.

Read and ACL comparison

  • A normal shell read succeeds and returns probe-step-created (19 bytes).
  • An approved read-only execution also succeeds with the identical 19 bytes.
  • Workspace directory inheritance is enabled.
  • Probe file inheritance is enabled.
  • Neither ACL contains a Deny ACE.
  • CodexSandboxUsers has inherited Modify access on both paths.
  • Workspace owner: the interactive Windows user.
  • File created by apply_patch: BUILTIN\Administrators.

This makes an underlying NTFS read denial unlikely. The failure appears specific to the apply_patch verification/helper step that applies deny-read ACL state.

Logging observation

%USERPROFILE%\.codex\.sandbox\sandbox.log was stale: its last write was 2026-06-15, so it contained no entries for this August reproduction. That may be a separate diagnostics/logging gap.

No project source files, ownership, ACLs, or sandbox settings were changed during diagnosis.

meSATYA · 8 days ago

Removing \.cache\codex-runtimes folder and reinstalling codex might help.

IvanDosBarbas · 7 days ago

I can reproduce this in Codex Desktop on Windows in a normal workspace-write task.

Observed behavior:

  • Every sandboxed shell call fails before process creation, including a read-only Get-Content against a file inside the configured writable workspace.
  • apply_patch fails before reading the target file with fs sandbox helper failed ... helper_unknown_error: apply deny-read ACLs.
  • The Node/browser runtime also exits during startup with windows sandbox failed: helper_unknown_error: apply deny-read ACLs.
  • Granting explicit read/write permission for the exact workspace did not help.
  • Granting explicit read permission for the Codex runtime and the required local skill directory did not help.
  • Fully restarting Codex Desktop and reopening the same task did not help.
  • Both absolute and workspace-relative paths fail.
  • No project file was modified.

The workspace is under C:\Users\<redacted>\Documents\Codex\... and is listed in the task's writable roots. This blocks all inspection and editing, even for a single standalone HTML file.

Codex task/session ID for diagnostics: 01a01dc3-9460-7e50-99c3-9fd8c2c386fe.

Barragek0 · 5 days ago

Additional data point with a confirmed root cause and a no-admin workaround — posting here because the failure signature matches this issue exactly (SetNamedSecurityInfoW error 5 while applying deny ACEs during sandbox setup refresh).

Environment

  • Codex VS Code extension openai.chatgpt-26.818.41705-win32-x64
  • Windows 11 Pro, workspace under C:\... (local NTFS drive)
  • Sandbox mode: workspace-write
  • Error surfaced to the user: helper_unknown_error: setup refresh had errors, before PowerShell/cmd ever started

Root cause

A workspace-local .codex folder inside the repo had been left owned by CodexSandboxOffline (leftover from an earlier session where a sandboxed process had write access to the workspace):

(Get-Acl "C:\path\to\repo\.codex").Owner
# <MACHINE>\CodexSandboxOffline

Every subsequent command triggered a setup refresh, and the helper tried to apply its deny-read ACE on that folder. Since the helper runs as the interactive user (not the owner, not elevated), SetNamedSecurityInfoW returned error 5 (ACCESS_DENIED) and the whole refresh aborted:

deny ACE failed on C:\...\repo\.codex:
SetNamedSecurityInfoW failed for C:\...\repo\.codex: 5
setup refresh: processed 2 write roots (read roots delegated); errors=["deny ACE failed on ..."]
setup refresh completed with errors
setup error: setup refresh had errors

This repeated identically on every single command attempt (verified across ~20 entries in %USERPROFILE%\.codex\.sandbox\sandbox.<date>.log). Note the generic UI error (setup refresh had errors) hides the actual per-path ACL failure — you only see it in the sandbox log.

Workaround (no admin, no ownership changes)

In my case the mis-owned folder was completely empty, so it could simply be deleted — Codex recreates it with correct ownership on the next setup refresh:

$p = "C:\path\to\repo\.codex"
$items = @(Get-ChildItem $p -Recurse -Force -ErrorAction SilentlyContinue)
if ($items.Count -eq 0) { Remove-Item $p -Force }   # only if truly empty!

After deleting, the next command succeeded immediately. No ACLs were modified, no ownership taken, nothing disabled, no reinstall needed.

If the folder is not empty, don't delete it blindly — use the ownership-restore approach described in #38898 (comment) instead.

Suggestions for maintainers

  1. When a deny ACE fails with ACCESS_DENIED, the helper could detect owner-vs-caller mismatch (CodexSandbox* owning paths inside the workspace) and either self-heal or surface the specific path and Win32 error instead of the generic helper_unknown_error.
  2. Consider hardening against sandbox users taking ownership of workspace-local state dirs in the first place (e.g., create .codex in the workspace before granting write access, or exclude it from writable roots).
  3. Related but distinct: same failure class also reported via .git owned by CodexSandboxOffline in #38898.
patricio4-wsl · 2 hours ago

Seguimiento a solicitud del usuario. Codex Desktop identificó este issue como relacionado y realizó esta comparación técnica desde el propio entorno Desktop.

En Windows, con codex-cli 0.149.1 tanto en Desktop como en la CLI standalone, Desktop falla de forma reproducible al usar apply_patch en un workspace aprobado: incluso una prueba temporal inocua devuelve Access denied / Failed to write file. En una ocasión creó un archivo vacío pero no pudo escribirlo ni eliminarlo con el helper.

La misma operación mediante la CLI standalone funciona en el mismo workspace. No se cambiaron ACLs, owner, WindowsApps, permisos del repositorio ni el modo de sandbox. Eso refuerza que el problema está en la inicialización/identidad efectiva del sandbox o helper de Desktop, no en el contenido del proyecto.

Impacto: Desktop sigue siendo útil para análisis y validaciones read-only, pero obliga a desviar las ediciones de apply_patch a CLI. El informe no incluye rutas personales, SIDs, credenciales ni datos privados.

---

English translation

Follow-up at the user's request. Codex Desktop identified this issue as related and produced this technical comparison from within the Desktop environment itself.

On Windows, using codex-cli 0.149.1 in both Desktop and the standalone CLI, Desktop reproducibly fails when using apply_patch in an approved workspace: even a harmless temporary-file probe returns Access denied / Failed to write file. On one occasion it created an empty file but could neither write it nor delete it through the helper.

The same operation works through the standalone CLI in the same workspace. No ACLs, owner, WindowsApps installation, repository permissions, or sandbox mode were changed. This reinforces that the problem lies in Desktop's sandbox/helper initialization or effective identity, rather than in project content.

Impact: Desktop remains useful for analysis and read-only validations, but forces edits through apply_patch to be redirected to CLI. The report includes no personal paths, SIDs, credentials, or private data.