Skip to content

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

Open
Open
Windows sandbox fails with helper_unknown_error: apply deny-read ACLs in workspace-write mode#36087
Labels
appIssues related to the Codex desktop appbugSomething isn't workingsandboxIssues related to permissions or sandboxingwindows-osIssues related to Codex on Windows systems

Description

@akiyastudio
akiyastudio
opened on Jul 30, 2026

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.

Activity

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

  3. github-actions commented on Jul 30, 2026

    @github-actions
    github-actionsbot
    on Jul 30, 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. gaoshanyan1-oss commented on Jul 30, 2026

    @gaoshanyan1-oss
    gaoshanyan1-oss
    on Jul 30, 2026 – with ChatGPT Codex Connector

    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.

  5. kecskeslaszlo94 commented on Aug 14, 2026

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

    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.

  6. tico0505 commented on Aug 16, 2026

    @tico0505
    tico0505
    on Aug 16, 2026 – with ChatGPT Codex Connector

    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.

  7. meSATYA commented on Aug 20, 2026

    @meSATYA
    meSATYA
    on Aug 20, 2026

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

  8. IvanDosBarbas commented on Aug 21, 2026

    @IvanDosBarbas
    IvanDosBarbas
    on Aug 21, 2026 – with ChatGPT Codex Connector

    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.

  9. Barragek0 commented on Aug 23, 2026

    @Barragek0
    Barragek0
    on Aug 23, 2026

    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.

  10. patricio4-wsl commented on Aug 28, 2026

    @patricio4-wsl
    patricio4-wsl
    on Aug 28, 2026

    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.

  11. mychun1111-jpg commented on Aug 30, 2026

    @mychun1111-jpg
    mychun1111-jpg
    on Aug 30, 2026 – with ChatGPT Codex Connector

    Additional reproduction matching this issue:

    • OS: Windows 10 Pro 22H2, build 19045.6466.
    • ChatGPT/Codex Desktop using a trusted primary workspace on an NTFS D: volume.
    • Active permission profile: workspace-write / Ask for approval.
    • The Windows user can manually create and delete files in the repository.
    • The repository ACL includes Authenticated Users and CodexSandboxUsers with Modify/Write permissions and no Deny entries.
    • A fresh chat bound to the correct primary workspace still cannot create a temporary file.

    Observed behavior:

    • With the elevated Windows sandbox, diagnostics reported helper_unknown_error: setup refresh had errors, followed by Failed to write file D:\<redacted-workspace>\codex_sandbox_write_test.tmp.
    • After changing to the documented unelevated fallback, fully exiting/restarting the desktop app, and starting a new project chat, the same write failure occurred.
    • The project path, trust status, primary folder binding, NTFS format, and ACLs were all verified.

    Impact:
    A paid user was blocked from applying a one-line local configuration update and completing an otherwise straightforward deployment. The troubleshooting path required repeated restarts, permission-mode changes, sandbox configuration changes, fresh-chat tests, filesystem checks, and manual ACL inspection, without producing an actionable error. Besides fixing the sandbox helper failure, it would help if Codex stopped after bounded checks and surfaced a clear product-level failure instead of shifting extended platform debugging effort to the user.

    No secrets, account IDs, full local paths, or production credentials are included in this report.

  12. esko666sm-lgtm commented on Sep 19, 2026

    @esko666sm-lgtm
    esko666sm-lgtm
    on Sep 19, 2026 – with ChatGPT Codex Connector

    We are seeing the same helper_unknown_error: apply deny-read ACLs failure on Windows with workspace-write, including cases where ordinary reads work but apply_patch cannot create or modify files in the workspace.

    A useful diagnostic/workaround path from our repeated runs:

    1. First verify the repository is normally writable outside the Codex sandbox. In our case it was.
    2. Avoid broad ACL changes. Where a specific repository subtree genuinely lacked effective write permission, granting the logged-in Windows account Modify only on the required subtree restored writes there; we did not change global/system ACLs.
    3. Importantly, this did not eliminate the underlying Codex sandbox-helper problem globally: after fixing one subtree (docs), the same sandbox error later appeared when apply_patch needed to create files under src/tests.
    4. The practical fallback has therefore been to keep the repository/security gates unchanged and use the Codex apply_patch helper outside the failing sandbox boundary only when necessary, rather than progressively broadening repository ACLs or disabling Windows security controls.
    5. After the narrowly scoped ACL repair, our full project verification remained green (tests, clean worktree, secret scan, loopback-security checks). The recurrence in other directories is strong evidence that the root cause is the sandbox ACL helper rather than ordinary NTFS write access.

    So I would caution against treating a recursive/full-repository ACL grant as the fix. A narrow ACL correction can resolve a real local permission mismatch, but the reproducible apply deny-read ACLs failure can remain and reappear on another writable subtree.

  13. esko666sm-lgtm commented on Oct 2, 2026

    @esko666sm-lgtm
    esko666sm-lgtm
    on Oct 2, 2026 – with ChatGPT Codex Connector

    Follow-up from the Windows environment I reported earlier.

    Thanks for the additional reproductions and especially the ownership finding around workspace-local .codex / .git paths. Our later runs are consistent with the broader conclusion that this is not solved by granting wider NTFS permissions to the repository.

    What we have observed:

    • normal host-side read/write access can succeed while the Codex sandbox helper still fails with helper_unknown_error: apply deny-read ACLs;
    • narrowly repairing a genuinely affected subtree can restore that subtree, but the helper failure may later recur elsewhere;
    • broad/recursive ACL changes are therefore not a reliable fix and unnecessarily weaken the boundary;
    • using the standalone Codex CLI / an execution path outside the failing Desktop sandbox has been a workable fallback for us while keeping the repository security gates intact.

    The report from @Barragek0 is particularly useful because it identifies a concrete owner mismatch (CodexSandboxOffline) that can produce the same failure class. I think it would be valuable for the helper to surface the exact failing path, owner and Win32 error in the UI instead of collapsing this to helper_unknown_error, and where safe detect/recover sandbox-owned workspace state.

    For anyone testing the empty-.codex workaround: please verify the directory is actually empty before deleting it; I would not recommend deleting a non-empty workspace state directory or recursively changing ownership/ACLs just to make the error disappear.

    I can provide another sanitized Windows reproduction/log comparison if maintainers need a specific probe.

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