sandbox problem #49677

Activity

1. Steven2007yhq

   added

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

   on Sep 30, 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 30, 2026
3. github-actions commented on Sep 30, 2026

   

   github-actionsBot

   on Sep 30, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • [Windows][Codex App] Sandbox setup fails in elevated and unelevated modes with helper_sandbox_lock_failed #49025
   • [Windows Sandbox] Setup fails when sandbox_mode is danger-full-access and cannot self-heal DACL on .sandbox-bin #49299

   Powered by Codex Action
4. spidikor commented on Oct 1, 2026

   

   spidikor

   on Oct 1, 2026 – with ChatGPT Codex Connector

   More actions

   Same failure here on Codex Desktop 26.928.2636.0, Windows 11 Home, build 26300. Adding just WRITE_DAC for SYSTEM got mine past the setup failure, and sandbox commands could run again! Posting the anonymized details in case they help someone else.

   Setup had already created the sandbox accounts and configured WFP (12 filters), then stopped at:

   helper_sandbox_lock_failed:
   lock sandbox bin dir <CODEX_HOME>/.sandbox-bin failed:
   open directory <CODEX_HOME>/.sandbox-bin
   

   The sandbox service was running as LocalSystem. The existing .sandbox-bin was an ordinary directory, owned by the interactive user, with inheritance disabled:

   Identity	Permissions before the workaround
   SYSTEM	Modify, Synchronize
   Administrators	Modify, Synchronize
   Interactive user / owner	Modify, ChangePermissions, Synchronize
   CodexSandboxUsers	ReadAndExecute, Synchronize

   So the owner could change the DACL, but SYSTEM lacked ChangePermissions / WRITE_DAC.

   What worked locally: save the existing DACL, add only SYSTEM's WRITE_DAC on that one directory, then retry the normal Codex sandbox setup.

   Here is the same operation with a backup and path checks, for the default $env:USERPROFILE\.codex location. Use it only when the service identity and ACL match the case above, and the interactive account already has permission to change that directory's DACL:

   $codexDir = Join-Path $env:USERPROFILE '.codex'
   $binDir = Join-Path $codexDir '.sandbox-bin'
   $aclBackup = Join-Path $env:TEMP (
       'codex-bin-acl-' + [guid]::NewGuid().ToString('N') + '.txt'
   )
   
   # Reject redirected paths before changing permissions.
   $checkDir = Get-Item -LiteralPath $binDir -Force -ErrorAction Stop
   while ($null -ne $checkDir) {
       if (-not $checkDir.PSIsContainer -or
           ($checkDir.Attributes -band [IO.FileAttributes]::ReparsePoint)) {
           throw 'Expected an ordinary directory path; stopping.'
       }
       $checkDir = $checkDir.Parent
   }
   
   Push-Location -LiteralPath $codexDir
   try {
       icacls.exe '.sandbox-bin' /save $aclBackup
       if ($LASTEXITCODE -ne 0) { throw 'ACL backup failed' }
       "ACL backup: $aclBackup"
   
       icacls.exe '.sandbox-bin' /grant '*S-1-5-18:(WDAC)'
       if ($LASTEXITCODE -ne 0) { throw 'Permission change failed' }
   } finally {
       Pop-Location
   }

   Then retry setup through Codex. This grant is additive and applies to the directory itself; it has no recursion or inheritance flags. The local recovery changed neither ownership nor the sandbox user group's rights, and added nothing to Administrators.

   After the change, an actual command through Codex's sandbox runner printed SANDBOX_PROBE_OK and exited 0. Follow-up commands could read the workspace and the directory ACL. A subsequent startup probe also exited 0.

   The catch: the post-setup ACL was back to the table above. Codex had removed the temporary SYSTEM WRITE_DAC grant itself. Shell startup and read access were verified; workspace writes, a future upgrade, and another provisioning cycle were not. This is a temporary provisioning workaround, with recurrence still possible.

   The 0.159.2 provisioning source fits that explanation: ProvisionOnly opens the directory with READ_CONTROL | WRITE_DAC, while the generated SYSTEM/Administrators masks omit WRITE_DAC. That is a source-based explanation supported by the before/after result; the original log did not expose the underlying Windows error code.

   Related reports: SYSTEM permission workaround and recurrence, and WRITE_DAC-only recovery for SYSTEM plus Administrators. This local test adds a SYSTEM-only result on the desktop build in this issue.
5. fbnkch commented on Oct 1, 2026

   

   fbnkch

   on Oct 1, 2026 – with ChatGPT Codex Connector

   More actions

   Another reproducible case on the same Windows app version.

   Environment

   • Codex / ChatGPT Windows app: 26.928.2636.0
   • Windows 11 Pro, build 10.0.26200, x64
   • Issue started only a few hours before this report; the same Work chats were usable before that.
   • Impact: existing Work chats are effectively unusable because the app requires Windows setup, then shows "Windows setup didn't finish / Setup stopped" when retrying. This blocks access to ongoing Work conversations that contain project instructions and files.

   codex doctor findings (separate npm CLI)

   • Doctor: v0.144.4 windows-x86_64 (newer CLI version available)
   • Summary: 15 ok · 1 idle · 3 notes · 2 warn · 0 fail degraded
   • Install consistent
   • State DB integrity OK
   • Auth configured with ChatGPT tokens
   • WebSocket connection succeeds (HTTP 101 Switching Protocols)
   • Provider endpoints reachable
   • Sandbox reports restricted fs + restricted network · approval OnRequest
   • Relevant warning: node_repl env var CODEX_WINDOWS_REGISTERED_CORE is not set
   • Additional thread-state warnings: rollout files missing from state DB / duplicate thread inventory entries. The DBs themselves report healthy.

   This looks less like a general auth/network failure and more like a Windows provisioning / Registered Core setup regression in the current desktop build.

   I can provide a redacted full codex doctor --json report if maintainers need it.