Windows codex exec can fail to launch sandbox setup helper when PATH resolves mismatched Codex entry point

Open 💬 1 comment Opened Jun 15, 2026 by chin1hanwu

Summary

On Windows, codex exec can fail in non-interactive automation when the codex.exe entry point resolved by the parent process does not have the matching Codex resources directory on PATH.

The failure appears when Codex tries to launch the Windows sandbox setup helper:

ShellExecuteExW failed to launch setup helper: 1223

In the same run, initial read-only shell commands can succeed, but later write-oriented steps fail repeatedly and may show a Windows popup saying that codex-windows-sandbox-setup.exe cannot be found or launched.

Environment

  • OS: Windows 11
  • Codex CLI version: 0.137.0
  • Codex App also installed
  • Codex VS Code extension also installed
  • Invocation mode: another local automation tool calls codex exec, following the non-interactive mode documentation

Observed installation shape

Multiple Codex entry points can exist on the same machine, including:

%LOCALAPPDATA%\Programs\OpenAI\Codex\bin\codex.exe
%USERPROFILE%\.codex\packages\standalone\releases\<version>\bin\codex.exe
%APPDATA%\...\npm-global\codex.cmd
%APPDATA%\...\npm-global\codex.ps1
%ProgramFiles%\WindowsApps\OpenAI.Codex_...\app\resources\codex.exe

The helper exists under the standalone resources directory:

%USERPROFILE%\.codex\packages\standalone\releases\<version>\codex-resources\codex-windows-sandbox-setup.exe

However, when a parent process invokes the bare codex command, it may resolve a codex.exe entry point without also inheriting the matching codex-resources directory on PATH. In that state, codex exec can start, run a few read-only commands, and then fail when it needs the helper.

Reproduction shape

  1. On Windows, install Codex CLI, Codex App, and the VS Code extension.
  2. Invoke codex exec from another local automation process using the bare codex command.
  3. Run a task that starts with simple read-only shell commands and later performs file writes.
  4. Observe that the read-only commands may succeed, then helper launch failures begin once write execution is needed.

Expected behavior

codex exec should locate the matching Windows helper reliably relative to the active Codex runtime/resources directory, or emit a clear diagnostic that identifies the expected helper path and the PATH/runtime mismatch.

Actual behavior

The run repeatedly fails with:

ShellExecuteExW failed to launch setup helper: 1223

The Windows popup refers to codex-windows-sandbox-setup.exe. The behavior also occurs when broad sandbox/approval bypass flags are used, so the issue appears to be helper discovery/launch rather than only a sandbox policy setting.

Workaround

Using an absolute standalone CLI path and prepending both the matching bin and codex-resources directories to the process PATH appears to avoid the entry-point mismatch:

$root = "$env:USERPROFILE\.codex\packages\standalone\releases\<version>"
$env:Path = "$root\bin;$root\codex-resources;$env:Path"
& "$root\bin\codex.exe" exec --sandbox workspace-write --skip-git-repo-check -C <workspace> "<prompt>"

Related issues

This may be related to:

  • #18845
  • #24490

This report is focused specifically on the non-interactive codex exec path when launched by another local automation process and multiple Windows Codex entry points are present.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗