[Windows][Codex App] Sandbox setup fails in elevated and unelevated modes with helper_sandbox_lock_failed #49025

Activity

1. ruimpsousa-jpg

   added

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

   on Sep 28, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   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 Sep 28, 2026
3. ruimpsousa-jpg commented on Sep 28, 2026

   

   ruimpsousa-jpg

   on Sep 28, 2026

   Author

   More actions

   Update: after closing ChatGPT Desktop, I renamed C:\Users<USER>.codex.sandbox-bin to .sandbox-bin.bak and restarted the app. Codex recreated the sandbox environment and local commands started working again.
   Current configuration:
   [windows] sandbox = "unelevated"
   Git commands now execute normally inside Codex.
   This appears to be a working workaround for the helper_sandbox_lock_failed issue on my system.
4. zengweiyi1223 commented on Sep 30, 2026

   

   zengweiyi1223

   on Sep 30, 2026

   More actions

   Independent reproduction on 2026-09-30 with the same helper_sandbox_lock_failed / open directory signature.

   Environment:

   • Codex Desktop 26.928.2636.0 (Microsoft Store package)
   • Windows 11 Home, version 10.0.26200, x64, Chinese locale
   • Native Windows sandbox configured as elevated

   Observed behavior:

   • Desktop repeatedly shows Finish Windows setup / Setup stopped.
   • Retrying never produces a real UAC prompt.
   • The failure persists after a full Windows restart and a Codex restart.
   • The failure occurs before any project command runs.

   Sanitized setup_error.json:

   {
     "code": "helper_sandbox_lock_failed",
     "message": "lock sandbox bin dir <USERPROFILE>\\.codex\\.sandbox-bin failed: open directory <USERPROFILE>\\.codex\\.sandbox-bin"
   }

   Relevant sanitized log sequence:

   ensuring sandbox users offline=CodexSandboxOffline online=CodexSandboxOnline
   firewall rules configured for CodexSandboxOffline
   WFP setup succeeded for CodexSandboxOffline with 12 installed filters
   setup error: helper_sandbox_lock_failed: lock sandbox bin dir <USERPROFILE>\\.codex\\.sandbox-bin failed: open directory <USERPROFILE>\\.codex\\.sandbox-bin
   

   Additional checks:

   • .sandbox-bin exists and is readable in Explorer.
   • Resource Monitor handle search for sandbox-bin returned no holder.
   • Microsoft Defender Protection History contains no matching recent event.
   • setup_marker.json remains empty after the failed setup.
   • No .sandbox-bin / .sandbox-secrets deletion, ownership takeover, broad ACL grant, or Full Access workaround was attempted.

   This appears to match the report exactly. Please let me know if a fully sanitized log attachment or additional supported diagnostic is useful.
5. Hidesc commented on Sep 30, 2026

   

   Hidesc

   on Sep 30, 2026 – with ChatGPT Codex Connector

   More actions

   Adding another reproduction with a more specific timeline and a note about the error's meaning.

   Environment: Windows 11 Home x64, build 10.0.26300; Microsoft Store package OpenAI.Codex 26.928.2636.0; command-runner 0.159.2; workspace-write with the elevated Windows sandbox.

   Even a harmless read-only PowerShell command fails before it starts: sandbox provisioning failed / exec-server rejected request (-32603). The UI reports incomplete Windows setup; clicking reconfigure has no visible effect. Updating the app, restarting it, and a full Windows reboot have not resolved this.

   Diagnostic signatures (paths sanitized):

   • sandbox setup required: sandbox setup marker missing or incompatible
   • helper_sandbox_lock_failed: lock sandbox bin dir %USERPROFILE%\.codex\.sandbox-bin failed: open directory %USERPROFILE%\.codex\.sandbox-bin

   Timeline on 2026-09-30, UTC+8:

   • 20:23:57: the earlier diagnostic report records successful setup/service/users/WFP steps; these earlier entries were not all independently rechecked.
   • 20:47:42.058: directly checked log entry shows offline firewall settings changing ports [] to [7897].
   • From 20:47:55.278: directly checked entries report the missing/incompatible setup marker and provisioning failure.
   • 21:36:42.260: directory-open failure above, timestamp 2026-09-30T13:36:42.2608526Z in UTC.

   This is an observed sequence, not evidence that the port change caused the failure. .sandbox-bin exists and is readable, contains the Codex executable/runner, and setup_marker.json is 0 bytes.

   In the official 0.159.2 source reviewed for this report, “lock sandbox bin dir” is an ACL-lockdown operation; the message does not establish a mutex/process-lock conflict. The ProvisionOnly path opens the directory with READ_CONTROL | WRITE_DAC, and the wrapper may omit the inner cause. No underlying Win32 error code is present in the observed error.

   No manual ACL/marker changes or directory deletion have been performed, and neither Full Access nor unelevated mode has been enabled. Is there a safe supported recovery that preserves the elevated sandbox, or a specific additional diagnostic maintainers need to identify the failing Windows operation?
6. spidikor commented on Oct 1, 2026

   

   spidikor

   on Oct 1, 2026 – with ChatGPT Codex Connector

   More actions

   Quick update for the same helper_sandbox_lock_failed / open directory failure: a narrow permissions workaround worked locally.

   On Codex Desktop 26.928.2636.0 / Windows 11 Home, build 26300, the service was running as LocalSystem, while SYSTEM had Modify but lacked WRITE_DAC on the protected .sandbox-bin directory.

   After saving the DACL and checking that the path wasn't redirected, I added only SYSTEM's WRITE_DAC, additively on that directory itself, and retried the normal setup. Actual sandbox PowerShell commands then exited 0, and workspace/ACL reads worked! Ownership, Administrators' rights and the sandbox user group's rights stayed unchanged.

   Full anonymized steps, backup/path checks, and source comparison.

   The catch: Codex removed the temporary permission afterward. Shell startup and reads were verified; workspace writes, an upgrade and another provisioning cycle weren't. So this is a temporary workaround for the matching LocalSystem/ACL case, with recurrence still possible.
7. Pronto-Sage commented on Oct 1, 2026

   

   Pronto-Sage

   on Oct 1, 2026

   More actions

   Additional reproduction: shell execution and file editing unavailable

   I’m seeing a matching failure in a Linux execution environment. Basic commands such as pwd, true, and source-file reads fail before the requested command executes:

   bwrap: loopback: Failed RTM_NEWADDR: Operation not permitted
   

   Direct apply_patch operations also fail with:

   Failed to write file [workspace path redacted]
   

   I cannot confirm whether the patch failure has exactly the same underlying cause.

   Observed diagnostics

   • Reported execution profile: workspace-write, with restricted network access and approval policy never.
   • Shell commands fail in both the project workspace and /tmp.
   • Both /bin/bash and /bin/sh fail.
   • Disabling login-shell behavior and trying a TTY did not resolve it.
   • Earlier Codex execution successfully performed development work.
   • The triggering change, Codex build, OS distribution, and kernel version have not been verified.

   Impact

   Codex cannot inspect source files, edit them, run tests, or verify development changes. Repeated requests produce the same executor failure without further repository work.

   This establishes an execution-tool failure, not an application, repository, or deployment defect.

   Expected behavior

   Workspace commands and edits should work within the configured permissions. If sandbox initialization fails, Codex should provide an actionable diagnostic and a supported recovery path rather than repeatedly retrying operations that cannot start.
8. anye2627 commented on Oct 1, 2026

   

   anye2627

   on Oct 1, 2026 – with ChatGPT Codex Connector

   More actions

   Confirmed recovery on October 1, 2026, with the setup helper from package OpenAI.Codex_26.928.3736.0.

   Process Monitor captured codex-windows-sandbox-setup.exe running as SYSTEM at System integrity. Opening the .sandbox-bin directory failed with ACCESS DENIED while requesting READ_CONTROL | WRITE_DAC. SYSTEM had Modify permission but lacked Change permissions.

   After backing up the original directory ACL, I added a separate Allow entry for SYSTEM with only Change permissions, scoped to This folder only. Existing entries, ownership, and inheritance were left unchanged; no Full Control grant was added.

   Retrying the normal Windows setup then succeeded. Get-Date also executed successfully in the previously blocked Codex task.

   This independently corroborates the narrowly scoped workaround for this specific permission mismatch. We have not verified whether the added permission survives setup. Other reports indicate it may be removed again, so this should not be treated as a permanent fix.