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

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?

1. Machine with the elevated Windows sandbox fully set up and healthy: CodexSandboxOffline/CodexSandboxOnline users exist, firewall rules in place, setup refreshes complete with errors=[].
2. Start a fresh session: codex exec --json --sandbox read-only - <<'EOF' ... EOF (cwd was a git worktree; likely irrelevant).
3. 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 (including codex 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-only review 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 to codex.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.