Repository navigation
Windows CLI 0.144.1: exec-tool setup refresh spawns codex-windows-sandbox-setup.exe by bare name (program not found), while code-mode host path resolves the versioned full path in the same session #32359
Description
What version of Codex CLI is running?
0.144.1 (Windows installer build; CLI shim at %LOCALAPPDATA%\Programs\OpenAI\Codex\bin\codex.exe, versioned helper dir at %LOCALAPPDATA%\OpenAI\Codex\bin\<hash>\ — its codex-command-runner copy is tagged 0.144.0-alpha.4)
What platform is your computer?
Microsoft Windows 11 Pro for Workstations 10.0.26200 x64
What steps can reproduce the bug?
- Machine with the elevated Windows sandbox fully set up and healthy:
CodexSandboxOffline/CodexSandboxOnlineusers exist, firewall rules in place, setup refreshes complete witherrors=[]. - Start a fresh session:
codex exec --json --sandbox read-only - <<'EOF' ... EOF(cwd was a git worktree; likely irrelevant). - The model's first shell/exec tool calls fail immediately with
orchestrator_helper_launch_failed ... error=program not found, twice; the model then falls back to the code-mode host (node_repl), whose launch path resolves the helper fine and the rest of the session (includingcodex exec resume) works normally — sandbox fully engaged.
What is the bug?
codex.exe has two different resolution code paths for codex-windows-sandbox-setup.exe, and only one of them is correct. The setup refresh that precedes a direct exec-tool (pwsh) spawn tries to launch the helper by bare file name, which is not on PATH and not next to the CLI shim, so it fails. Eleven seconds later, in the same session, the setup refresh that accompanies the code-mode host launch resolves the full versioned path and succeeds.
From %USERPROFILE%\.codex\.sandbox\sandbox.2026-07-11.log (timestamps local UTC+8; paths redacted):
14:17:20.059 codex.exe START: C:\Program Files\PowerShell\7\pwsh.exe -NoProfile ...
14:17:20.098 codex.exe setup refresh: spawning codex-windows-sandbox-setup.exe (cwd=<workspace>, payload_len=3276)
14:17:20.099 codex.exe setup refresh: setup refresh failed to launch helper: helper=codex-windows-sandbox-setup.exe, ... error=program not found
14:17:24.960 codex.exe START: C:\Program Files\PowerShell\7\pwsh.exe -NoProfile ...
14:17:24.999 codex.exe setup refresh: spawning codex-windows-sandbox-setup.exe (cwd=<workspace>, payload_len=3276)
14:17:25.000 codex.exe setup refresh: setup refresh failed to launch helper: ... error=program not found
14:17:36.950 codex.exe START: %LOCALAPPDATA%\OpenAI\Codex\runtimes\cua_node\<hash>\bin\node.exe --experimental-vm-modules ...\kernel.js
14:17:36.987 codex.exe setup refresh: spawning %LOCALAPPDATA%\OpenAI\Codex\bin\a7c12ebff69fb123\codex-windows-sandbox-setup.exe (cwd=<workspace>, payload_len=3276)
14:17:37.016 codex-windows-sandbox-setup.exe setup binary completed
14:17:37.021 codex.exe helper copy: validating command-runner source=%LOCALAPPDATA%\OpenAI\Codex\bin\a7c12ebff69fb123\codex-command-runner.exe destination=%USERPROFILE%\.codex\.sandbox-bin\codex-command-runner-0.144.0-alpha.4.exe
14:17:37.022 codex.exe helper launch resolution: using copied command-runner path ...
Note the failing spawns log the helper without any directory (spawning codex-windows-sandbox-setup.exe) while the succeeding spawn logs the full versioned path. The helper binary itself is present and healthy the whole time.
The stderr the user sees on every fresh codex exec:
ERROR codex_core::exec: exec error: windows sandbox: orchestrator_helper_launch_failed: setup refresh failed to launch helper: helper=codex-windows-sandbox-setup.exe, cwd=<workspace>, log=%USERPROFILE%\.codex\.sandbox\sandbox.2026-07-11.log, error=program not found
ERROR codex_core::tools::router: error=execution error: Io(Custom { kind: Other, error: "windows sandbox: orchestrator_helper_launch_failed: ..." })
What is the expected behavior?
The exec-tool setup-refresh path should resolve the helper the same way the code-mode host launch path does (versioned %LOCALAPPDATA%\OpenAI\Codex\bin\<hash>\ directory), instead of spawning by bare file name.
Impact
- The model's first direct shell attempts in every fresh session fail and it silently degrades to the code-mode host for shell work — wasted tool calls, scary ERROR noise, and (for
--sandbox read-onlyreview workflows) the direct shell tool is effectively unavailable. - Users are likely to misdiagnose this as "helper not installed" (we did at first) since the error says
program not found, and may be tempted to copy a stale helper next tocodex.exe, which would hand elevated ACL work to an outdated binary after auto-updates rotate the hashed dir.
Related issues
Probably related but not identical resolution-path reports: #28457 (0.140.0 standalone launcher, persistent), #27125 (0.138.0 regression), #30829 (clean-install bin junction), #30732 (app packages helpers under resources but launcher searches app/PATH). What distinguishes this report is that both the failing bare-name path and the working versioned-path resolution are observable in the same session/log, which should pinpoint the divergent code path.
Activity
github-actions commentedon Jul 11, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
momadacoding commentedon Jul 12, 2026
same here
git10135405 commentedon Jul 12, 2026
The official
install.ps1script completed the installation; Codex Doctor reported that the installation was complete; the officialPATHentry failed, but thecurrent\binentry succeeded.arbaminim commentedon Aug 6, 2026
Reproduced on Codex Desktop 26.730.8199.0 with Codex CLI 0.146.1 on Windows x64.
Additional diagnostics (sanitized):
%LOCALAPPDATA%\Programs\OpenAI\Codex\bin\codex.exe.bindirectory is a junction into%USERPROFILE%\.codex\packages\standalone\releases\0.146.1-x86_64-pc-windows-msvc\bin.codex-windows-sandbox-setup.exeandcodex-command-runner.exeare absent from thatbindirectory but are present in the release's siblingcodex-resourcesdirectory.%LOCALAPPDATA%\OpenAI\Codex\bin\<hash>directory. The Store-package and versioned local helper copies are byte-identical.Status: Ok.binand the release'scodex-path, but no directory containingcodex-windows-sandbox-setup.exe.where.exe codex-windows-sandbox-setup.exefinds nothing.This affects ordinary sandboxed shell calls and also prevents browser/computer-use startup paths that depend on the same launcher. Escalated/fallback command execution still works, which is consistent with the divergent resolution paths described here.
This confirms the helper-resolution regression persists in stable 0.146.1. The durable fix appears to be resolving both helper paths from the detected standalone package root (and passing absolute paths), or changing the junction/install layout so
binretains a valid relationship tocodex-resources.yasuyuki commentedon Aug 15, 2026
Reproduced on Codex CLI 0.147.0 on Windows x64. The active process is the official standalone launcher:
Environment:
10.0.26200.0x647.6.426.810.4967.0is also installed and reportsStatus: Okbindirectory is a junction to%USERPROFILE%\.codex\packages\standalone\current\binThe matching 0.147.0 helpers are installed and present under:
However, ordinary shell and filesystem-helper calls still try to spawn the setup helper by bare filename and fail before the requested command runs:
The same session's code-mode host resolves the absolute versioned helper path and completes setup successfully:
Minimal behavioral check:
orchestrator_helper_launch_failed ... program not foundrather than a normal sandbox access denial.Test-Pathconfirmed that the outside probe file was not created.This confirms the divergent helper-resolution path reported here persists in stable 0.147.0 on Windows x64. The error can look like an installation omission, but in this installation the helpers are present; the failing path does not resolve them from the standalone package's
codex-resourcesdirectory.etraut-openai commentedon Oct 12, 2026
(response from codex)
Closing in favor of #32655, which tracks sandbox helpers resolved relative to the standalone PATH shim instead of the active package directory. The contrasting successful code-mode host lookup and the Windows x64 reproductions here should be retained in that investigation. This is a duplicate closure, not a claim that sandboxed Windows exec is fixed.