Windows codex exec can fail to launch sandbox setup helper when PATH resolves mismatched Codex entry point
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
- On Windows, install Codex CLI, Codex App, and the VS Code extension.
- Invoke
codex execfrom another local automation process using the barecodexcommand. - Run a task that starts with simple read-only shell commands and later performs file writes.
- 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.
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗