›_ Codex Issues
Codex Issues / #32359

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

Open 💬 5 comments Opened Jul 11, 2026 by medking82
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 1 month ago

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

  • #31153

Powered by Codex Action

momadacoding · 1 month ago

same here

git10135405 · 1 month ago

The official install.ps1 script completed the installation; Codex Doctor reported that the installation was complete; the official PATH entry failed, but the current\bin entry succeeded.

arbaminim · 21 days ago

Reproduced on Codex Desktop 26.730.8199.0 with Codex CLI 0.146.1 on Windows x64.

Additional diagnostics (sanitized):

  • The active launcher is %LOCALAPPDATA%\Programs\OpenAI\Codex\bin\codex.exe.
  • That bin directory is a junction into %USERPROFILE%\.codex\packages\standalone\releases\0.146.1-x86_64-pc-windows-msvc\bin.
  • codex-windows-sandbox-setup.exe and codex-command-runner.exe are absent from that bin directory but are present in the release's sibling codex-resources directory.
  • Current helper copies are also present under the Desktop app's Store-package resources and its versioned %LOCALAPPDATA%\OpenAI\Codex\bin\<hash> directory. The Store-package and versioned local helper copies are byte-identical.
  • The AppX package reports Status: Ok.
  • The active process PATH includes the launcher bin and the release's codex-path, but no directory containing codex-windows-sandbox-setup.exe. where.exe codex-windows-sandbox-setup.exe finds nothing.
  • The sandbox log shows the failing setup-refresh path spawning only the bare filename:

``
setup refresh: spawning codex-windows-sandbox-setup.exe
setup refresh failed to launch helper: helper=codex-windows-sandbox-setup.exe ... error=program not found
``

  • Microsoft Store App Repair followed by a complete restart did not change the behavior.
  • Windows Defender and Code Integrity logs show no relevant Codex/helper detections.

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 bin retains a valid relationship to codex-resources.

yasuyuki · 13 days ago

Reproduced on Codex CLI 0.147.0 on Windows x64. The active process is the official standalone launcher:

%LOCALAPPDATA%\Programs\OpenAI\Codex\bin\codex.exe

Environment:

  • Windows 11 10.0.26200.0 x64
  • PowerShell 7.6.4
  • Codex Desktop 26.810.4967.0 is also installed and reports Status: Ok
  • The launcher bin directory is a junction to %USERPROFILE%\.codex\packages\standalone\current\bin

The matching 0.147.0 helpers are installed and present under:

%USERPROFILE%\.codex\packages\standalone\releases\0.147.0-x86_64-pc-windows-msvc\codex-resources\codex-windows-sandbox-setup.exe
%USERPROFILE%\.codex\packages\standalone\releases\0.147.0-x86_64-pc-windows-msvc\codex-resources\codex-command-runner.exe

However, ordinary shell and filesystem-helper calls still try to spawn the setup helper by bare filename and fail before the requested command runs:

[2026-08-15 11:42:14.645 codex.exe] setup refresh: spawning codex-windows-sandbox-setup.exe (cwd=%USERPROFILE%\work, payload_len=3160)
[2026-08-15 11:42:14.646 codex.exe] setup refresh: setup refresh failed to launch helper: helper=codex-windows-sandbox-setup.exe, cwd=%USERPROFILE%\work, log=%USERPROFILE%\.codex\.sandbox\sandbox.2026-08-15.log, error=program not found

The same session's code-mode host resolves the absolute versioned helper path and completes setup successfully:

[2026-08-15 11:25:53.101 codex.exe] setup refresh: spawning %LOCALAPPDATA%\OpenAI\Codex\bin\<hash>\codex-windows-sandbox-setup.exe (cwd=%USERPROFILE%\work, payload_len=3160)
[2026-08-15T02:25:53.138788+00:00] setup refresh: processed 2 write roots (read roots delegated); errors=[]

Minimal behavioral check:

  • Creating and deleting a temporary file inside the configured workspace succeeded.
  • A write attempt outside the workspace did not execute, but failed with orchestrator_helper_launch_failed ... program not found rather than a normal sandbox access denial.
  • An unsandboxed Test-Path confirmed that the outside probe file was not created.
  • Subsequent ordinary read-only tool calls reproduced the same helper-launch failure.

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-resources directory.