Windows elevated sandbox setup fails with SetNamedSecurityInfoW error 5 #39245

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   sandboxIssues related to permissions or sandboxingIssues related to permissions or sandboxing

   on Aug 18, 2026
2. github-actions commented on Aug 18, 2026

   

   github-actionsBot

   on Aug 18, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • [Windows] "Finish Windows setup" loops with no UAC prompt; sandbox runner gets Access Denied on C:\Users\Default #37940

   Powered by Codex Action
3. RedXi commented on Sep 12, 2026

   

   RedXi

   on Sep 12, 2026

   Last edited by RedXi

   More actions

   I can reproduce this consistently on Windows 11 with Codex / OWL 26.908.40834.

   Windows setup fails immediately after approving the UAC prompt with:

   Windows setup didn't finish • helper_failed

   setup_error.json contains:

   {
     "code": "helper_sandbox_lock_failed",
     "message": "lock sandbox bin dir C:\\Users\\<user>\\.codex\\.sandbox-bin failed: SetNamedSecurityInfoW sandbox dir failed: 5"
   }
   

   I already tried a full uninstall/reinstall, removed the previous Codex state, rebooted Windows, and ran setup again. Same result.

   What makes this more interesting: the exact same Codex / OWL build (26.908.40834) works correctly on another Windows installation available to me. So this does not look like a general build regression, but rather an environment-specific failure in Codex’s Windows sandbox/ACL bootstrap.

   The .sandbox-bin ACL itself looked sane before reinstall, yet Codex still tries to rewrite it and fails with ERROR_ACCESS_DENIED.

   “Continue with limited access” is not a meaningful workaround for local development — Codex becomes severely restricted and is barely useful.

   What is especially frustrating is that there is no actionable explanation or supported recovery path beyond helper_failed. A permissions bootstrap should either work reliably or tell the user exactly what Windows security condition is blocking it.

   For a flagship developer product, having Codex rendered effectively unusable on one otherwise normal Windows installation for no understandable reason is disappointing and frankly embarrassing.

   Is this SetNamedSecurityInfoW / error 5 failure understood internally? Is there a supported way to diagnose which ACL, security policy, Defender setting, or ownership condition is causing it?

   Happy to provide additional diagnostics or compare the working and failing Windows installations if that helps.
4. RedXi commented on Sep 12, 2026

   

   RedXi

   on Sep 12, 2026

   More actions

   Update: I was able to fix this on my machine.

   The workaround from #40550 worked for me:

   icacls "$env:USERPROFILE\.codex\.sandbox-bin" /inheritance:e

   I ran this from an elevated PowerShell, then restarted ChatGPT/Codex and ran the Windows setup again. This time the setup completed successfully.

   So in my case the problem was indeed related to .sandbox-bin being left with inheritance disabled in a state where the setup helper could no longer replace the ACL and failed with:

   helper_sandbox_lock_failed
   SetNamedSecurityInfoW sandbox dir failed: 5
   

   The relevant workaround was posted here:
   #40550 (comment)

   Might be worth checking whether this is the same underlying cause here as well. At least for me, temporarily re-enabling inheritance was enough to make the setup succeed.

   It would be good if Codex could detect and repair this state automatically, since from the UI the only visible error is helper_failed, which gives the user no useful indication of what is actually wrong.
5. zhya237-byte commented on Sep 13, 2026

   

   zhya237-byte

   on Sep 13, 2026

   More actions

   Hi, I reproduced the Windows elevated sandbox issue described here.

   I am not a native English speaker, so I used AI to help me write and translate this report. Sorry if some of the wording is not perfect.

   Environment:

   Windows 11
   Codex for Windows (Microsoft Store version)
   Codex CLI 0.154.0
   The sandbox helper is validly signed by OpenAI

   The sandbox log repeatedly reports:

   helper_sandbox_lock_failed: lock sandbox bin dir ....codex.sandbox-bin failed: SetNamedSecurityInfoW sandbox dir failed: 5

   I checked the affected .sandbox-bin directory:

   Owner and ACLs appear normal
   The DACL is protected and canonical
   My Windows user has Modify access
   icacls reports no errors

   I also tested a normal Windows directory with a protected DACL, and Windows was able to modify its ACL successfully. My normal Windows user can also create, read, and delete files in my user profile.

   Most importantly, I found a reliable A/B result on the same machine:

   Default/elevated sandbox:
   --sandbox workspace-write

   The setup repeatedly fails with SetNamedSecurityInfoW ... failed: 5, and Codex falls back to:

   sandbox: read-only

   Unelevated sandbox:

   With:

   [windows]
   sandbox = "unelevated"

   Codex reports:

   sandbox: workspace-write

   A real PowerShell write/read test succeeds, for example:

   Set-Content .\test.txt 'sandbox works'

   followed by:

   Get-Content .\test.txt

   returns:

   sandbox works

   This makes me think the problem is specific to the Windows elevated sandbox provisioning/ACL-lock path, rather than a general Windows permission problem.

   For now, windows.sandbox = "unelevated" works as a workaround on my machine.

   I hope these details are useful. Thank you for looking into this issue.
6. languno commented on Sep 13, 2026

   

   languno

   on Sep 13, 2026 – with ChatGPT Codex Connector

   More actions

   Confirmed another working recovery path on Windows 11 25H2.

   Environment:

   • Windows 11 25H2, Build 26200.9445
   • Microsoft Store package OpenAI.Codex version 26.908.4834.0
   • Package status: Ok
   • codex-windows-sandbox-setup.exe exists and its Authenticode signature is valid

   The UI showed:

   Windows setup didn't finish • helper_failed

   The sandbox log showed that sandbox-user creation, firewall rules and WFP setup succeeded, but provisioning failed specifically on:

   helper_sandbox_lock_failed: lock sandbox bin dir C:\Users\<user>\.codex\.sandbox-bin failed: SetNamedSecurityInfoW sandbox dir failed: 5
   

   What fixed it on this machine:

   1. Completely close ChatGPT/Codex.
   2. Open an elevated PowerShell.
   3. Rename the existing sandbox directory instead of modifying global Windows permissions:

   Rename-Item `
     "$env:USERPROFILE\.codex\.sandbox-bin" `
     ".sandbox-bin.backup-$(Get-Date -Format yyyyMMdd-HHmmss)"

   4. Restart ChatGPT/Codex and retry Windows setup.

   After that, Codex recreated %USERPROFILE%\.codex\.sandbox-bin, the Windows setup completed successfully, and the app started normally.

   So at least in this case, recreating .sandbox-bin was sufficient. This seems consistent with the existing inheritance/ACL workaround reported above, but has the advantage that it does not require manually editing the ACL itself.

   It may be useful for the setup helper to detect ERROR_ACCESS_DENIED on .codex\.sandbox-bin and offer a targeted recovery/recreation path instead of surfacing only helper_failed.
7. Freemlen commented on Sep 19, 2026

   

   Freemlen

   on Sep 19, 2026 – with ChatGPT Codex Connector

   More actions

   Related deep-dive: #43373.

   A later exact-version instrumented run + zero-loss ETW investigated SetNamedSecurityInfoW(...)=5 during Windows sandbox ACL setup.

   Important diagnostic finding: in the real failing AppData traversal, all 22,486 observed SetSecurity operations succeeded; the observed ACCESS_DENIED events were descendant Create/open operations during traversal. Two synthetic controls then reproduced matching denied-open patterns while top-level SetNamedSecurityInfoW still returned success.

   So SetNamedSecurityInfoW failed: 5 should not automatically be interpreted as “the target root SetSecurity itself was denied.” The exact Windows-internal aggregation rule remains unresolved, but the RCA may help distinguish root ACL failure from descendant traversal failure here.
8. drevendev commented on Oct 10, 2026

   

   drevendev

   on Oct 10, 2026 – with ChatGPT Codex Connector

   More actions

   Historical independent confirmation of the same general Windows elevated-sandbox setup failure class, without claiming the exact ACL root cause established in this issue.

   On August 14–15, 2026, our Windows Codex Desktop workflow began returning helper_unknown_error: setup refresh had errors before any requested process began. Even harmless Get-Location commands and required patch operations could not start on the affected projects; no partial repository files were changed. Some other Codex projects/workspaces on the same setup still worked, and the user had previously run the same workflow successfully on multiple machines. The regression seemed to start roughly a week earlier.

   We want to retain the elevated sandbox with its actual protection, not treat disabling/changing it to unelevated as the fix. We did not capture a reliable raw SetNamedSecurityInfoW failed: 5 entry or exact ACL/workspace-owner diagnostic from those particular August failures, so this comment confirms the surface error and project-specific behavior only. It does not prove the precise cause in the OP.

   Expected: sandbox setup either works before a read-only command or returns an actionable diagnostic naming the failing path/ACL operation, with the host keeping an accessible error trace.