›_ Codex Issues
Codex Issues / #32655

Windows standalone: sandbox helpers resolved relative to PATH shim, not package release dir (breaks all sandboxed exec)

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

On a standalone Windows install, every sandboxed codex exec (read-only and workspace-write) fails at the first tool call because the sandbox helper binaries cannot be found.

Symptoms

ERROR codex_core::exec: exec error: windows sandbox: orchestrator_helper_launch_failed:
  setup refresh failed to launch helper: helper=codex-windows-sandbox-setup.exe, error=program not found

and, once the setup helper is located, a second failure:

helper copy failed for command-runner: helper not found next to current executable or under
  codex-resources: C:\Users\<user>\AppData\Local\Programs\OpenAI\Codex\bin\codex.exe;
  falling back to legacy path codex-command-runner.exe
ERROR codex_core::exec: exec error: windows sandbox: CreateProcessWithLogonW failed: 2

Root cause

codex resolves codex-windows-sandbox-setup.exe and codex-command-runner.exe "next to the current executable or under codex-resources" — but the current executable is the PATH shim at AppData\Local\Programs\OpenAI\Codex\bin\codex.exe, whereas the helpers actually ship under the package release dir: ~/.codex/packages/standalone/releases/<version>/codex-resources/. The command-runner then falls back to a bare filename, and because it is launched via CreateProcessWithLogonW for the restricted CodexSandboxOffline user (fresh environment, no inherited PATH), that bare name cannot be found, giving error 2.

Workaround (confirmed)

Copy both helpers from the release codex-resources dir into the shim's bin dir:

copy "~\.codex\packages\standalone\releases\<ver>\codex-resources\codex-windows-sandbox-setup.exe"  "~\AppData\Local\Programs\OpenAI\Codex\bin\"
copy "~\.codex\packages\standalone\releases\<ver>\codex-resources\codex-command-runner.exe"        "~\AppData\Local\Programs\OpenAI\Codex\bin\"

After copying, a sandboxed workspace-write codex exec completes normally. This must be re-applied after every CLI upgrade, since the new release dir's helpers are not copied to the shim bin.

Environment

Windows 11 (10.0.26200), standalone install, reproduced on both codex-cli 0.144.0 and 0.144.1. Not elevation-related; the elevated desktop instance works only because its helpers happen to be co-located. Suggested fix: resolve helpers relative to the resolved package release dir, which codex doctor already reports, rather than the PATH shim, and/or pass an absolute command-runner path into the CreateProcessWithLogonW launch.

View original on GitHub ↗

10 Comments

github-actions[bot] contributor · 1 month ago

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

  • #32359
  • #31510

Powered by Codex Action

u2giants · 1 month ago

Confirming this still reproduces on codex-cli 0.144.5 (Windows 11 10.0.26200, standalone install). The report cites 0.144.0/0.144.1, so it survives at least through .5.

We hit this independently and arrived at the same root cause before finding this issue. One detail that may help: the failure isolates cleanly to the invocation path, with everything else held constant.

Minimal A/B — same binary, same version, same flags, same cwd

# via the PATH shim  ->  FAILS, no file written
C:\Users\<u>\AppData\Local\Programs\OpenAI\Codex\bin\codex.exe exec --sandbox workspace-write \
  --skip-git-repo-check "Create probe.txt containing OK"
# ERROR ... orchestrator_helper_launch_failed: setup refresh failed to launch helper:
#   helper=codex-windows-sandbox-setup.exe, error=program not found

# via the real package bin  ->  SUCCEEDS, file written
C:\Users\<u>\.codex\packages\standalone\current\bin\codex.exe exec --sandbox workspace-write \
  --skip-git-repo-check "Create probe.txt containing OK"

Both are codex-cli 0.144.5. …\Programs\OpenAI\Codex\bin is a junction to …\.codex\packages\standalone\current\bin, so only bin is visible there — the sibling codex-resources\ never is. The package itself is complete and passes the installer's own Test-PackageContentsAreComplete check (codex-package.json, bin\codex.exe, codex-path\rg.exe, codex-resources\codex-command-runner.exe, codex-resources\codex-windows-sandbox-setup.exe all present).

Why this is worse than it looks: it fails silently

codex --version and codex login status both succeed and exit 0 through the shim. codex exec then reports no error to the caller and simply changes nothing. Any health check that asks --version reports green while every sandboxed write is broken — this cost us a full debugging session before we thought to test an actual write rather than trust the version probe. Worth considering for severity.

Workaround that survives upgrades

The "copy both helpers into the shim's bin" workaround in the issue body works, but as noted it must be re-applied after every upgrade. Prepending the real package bin to PATH instead does not:

%USERPROFILE%\.codex\packages\standalone\current\bin

current is itself a junction that the updater re-points to the new release dir, so the fix persists across version bumps and needs no file copying.

Agree with the suggested fix — resolve helpers relative to the resolved package release dir (following the junction / using the final path, e.g. GetFinalPathNameByHandle) rather than the invoked shim path. Junctioning the package root instead of just bin would also make bin\ and codex-resources\ siblings from the visible path.

tagorr · 1 month ago

Confirming this on Codex CLI 0.144.3 with a standalone Windows installation.

Environment

  • Codex CLI: 0.144.3
  • Install method: standalone
  • OS: Windows 10 Enterprise LTSC 2019, build 17763
  • Shell: Windows PowerShell 5.1
  • Sandbox configuration:
sandbox_mode = "workspace-write"

[windows]
sandbox = "elevated"

Observed behavior

Even simple read-only commands inside the workspace could not start in the elevated sandbox.

The first sandboxed command failed with:

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

Codex then fell back to requesting permission to execute the command outside the sandbox. With Approve for me enabled, the auto-reviewer approved those unsandboxed executions.

codex doctor reported the standalone installation as consistent:

install consistent
runtime standalone
version 0.144.3

The active executable was:

C:\Users\<user>\AppData\Local\Programs\OpenAI\Codex\bin\codex.exe

Both required helpers were present in the standalone package:

C:\Users\<user>\.codex\packages\standalone\current\codex-resources\codex-windows-sandbox-setup.exe
C:\Users\<user>\.codex\packages\standalone\current\codex-resources\codex-command-runner.exe

So the package itself was complete, but the active executable could not resolve the helpers from the release package directory.

Workaround

I copied both helpers next to the active codex.exe:

$src="$HOME\.codex\packages\standalone\current\codex-resources"; $dst="$env:LOCALAPPDATA\Programs\OpenAI\Codex\bin"; Copy-Item -LiteralPath "$src\codex-windows-sandbox-setup.exe","$src\codex-command-runner.exe" -Destination $dst -Force

After fully restarting Codex, a sandboxed command such as:

git status --short

completed successfully without:

  • orchestrator_helper_launch_failed
  • program not found
  • an approval request
  • an auto-reviewed unsandboxed fallback

This confirms the same helper path-resolution problem on Windows 10 LTSC and Codex CLI 0.144.3.

The workaround fixes the current installation, but the copied helpers may need to be refreshed after a Codex update unless helper resolution or the standalone installation layout is corrected.

tagorr · 1 month ago

Update: still reproducible on 0.144.6

After upgrading the standalone Windows installation from 0.144.3 to 0.144.6, the installer removed the two helper files previously copied into the active shim directory:

%LOCALAPPDATA%\Programs\OpenAI\Codex\bin

The helpers were still present in:

%USERPROFILE%\.codex\packages\standalone\current\codex-resources

A fresh Codex session again failed with:

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

Copying both helpers into the active bin directory restored sandbox execution:

$src="$HOME\.codex\packages\standalone\current\codex-resources"; $dst="$env:LOCALAPPDATA\Programs\OpenAI\Codex\bin"; Copy-Item -LiteralPath "$src\codex-windows-sandbox-setup.exe","$src\codex-command-runner.exe" -Destination $dst -Force

One additional detail: resuming a session in which the sandbox had already failed continued to use auto-approved unsandboxed fallback. After fully exiting Codex and starting a new session, the same command ran without orchestrator_helper_launch_failed and without auto-review approval.

So, on my machine:

  • the bug still reproduces on 0.144.6;
  • the workaround must be reapplied after an upgrade;
  • a new Codex session is required after copying the helpers.
Stanleyshen0415 · 1 month ago

0.142.1 install.

codex doctor reported 17 ok / 0 fail while codex sandbox -- cmd.exe /d /c exit 0 failed before the requested command ran (doctor does not exercise the helper spawn path).

Workaround n=4: copying both same-version helpers from codex-resources\ to bin\ restores exit 0 (2026-07-03 x2, 2026-07-18, 2026-07-19). The failure recurs with every new release directory.

See #30829 for a commit-level analysis (bundled_executable_path_for_exe junction fallback). Suggested fix direction: resolve helpers via the install context's resources dir, or canonicalize the visible bin junction before executable-relative lookup — and add an end-to-end Windows standalone test that launches through the visible junction chain (current tests appear to cover only the physical package\bin path).

lallittarrte-dev · 1 month ago

Confirming this remains reproducible on Codex CLI 0.145.0 using the official standalone Windows installer.

Environment

  • Windows 11 Professional, build 10.0.26200
  • Codex CLI 0.145.0
  • Official standalone install via install.ps1

Additional reproduction evidence

I reproduced the same helper-resolution failure both before and after a genuinely clean official reinstall:

  1. Renamed the previous %LOCALAPPDATA%\Programs\OpenAI\Codex installation out of the way.
  2. Left %USERPROFILE%\.codex untouched.
  3. Re-ran the official installer into the empty installation location.
  4. Re-tested the native sandbox.

The freshly installed PATH launcher still fails:

codex sandbox -- cmd.exe /d /s /c "echo CODEX_SANDBOX_OK"

with:

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

Invoking the physical release binary directly succeeds:

& "C:\Users\<user>\.codex\packages\standalone\releases\0.145.0-x86_64-pc-windows-msvc\bin\codex.exe" `
  sandbox -- cmd.exe /d /s /c "echo CODEX_SANDBOX_OK"

Result:

CODEX_SANDBOX_OK

The PATH-resolved and physical-release executables resolve to the same SHA-256:

83751f15cb6a0a7b97df67752c001e3fe1c20e18ffbfec3ff63567296205eb6c

The observed junction chain is:

%LOCALAPPDATA%\Programs\OpenAI\Codex\bin
→ %USERPROFILE%\.codex\packages\standalone\current\bin

%USERPROFILE%\.codex\packages\standalone\current
→ releases\0.145.0-x86_64-pc-windows-msvc

Only bin is exposed through the PATH installation. The physical sibling codex-resources directory is not exposed at the visible launcher root, so sibling-relative helper resolution fails.

One further diagnostic concern: codex doctor reports the installation as healthy with no warnings or failures despite the PATH-native sandbox being unusable. A harmless actual sandbox-launch check in codex doctor would detect this condition.

This currently blocks a read-only orchestration workflow that deliberately fails closed rather than allowing Codex to fall back to an unsandboxed command path.

Guffawaffle · 1 month ago

Additional Windows reproduction (Codex 0.145.0, 2026-07-25):

  • The visible installer path under %LOCALAPPDATA%\Programs\OpenAI\Codex\bin\codex.exe is a junction-backed entry point.
  • Launching through that path failed sandbox helper discovery during read-only/workspace-write validation.
  • Launching the same standalone install through the canonical package path %USERPROFILE%\.codex\packages\standalone\current\bin\codex.exe passed both validations.
  • Putting the canonical current\bin first on the user PATH is a working workaround.

This looks consistent with helper/resource discovery being based on the unresolved launcher path instead of the canonical executable/package directory.

arthercz · 26 days ago

Still reproducing on 0.146.0 (x86_64-pc-windows-msvc, standalone installer, Windows 11).

Two data points that might help narrow this down.

1. It regressed between releases: 0.145.0 shipped the helpers in bin/, 0.146.0 does not

Both release dirs are on the same machine. Timestamps distinguish what the installer wrote from what I copied in later while working around this:

releases/0.145.0-x86_64-pc-windows-msvc/bin/
  2026-07-21 11:11  codex-code-mode-host.exe
  2026-07-21 11:11  codex-command-runner.exe          <- shipped
  2026-07-21 11:11  codex-windows-sandbox-setup.exe   <- shipped
  2026-07-21 11:11  codex.exe

releases/0.146.0-x86_64-pc-windows-msvc/bin/
  2026-07-28 18:33  codex-code-mode-host.exe
  2026-07-28 18:33  codex.exe
  # the two helpers were absent as installed; the copies present now are
  # dated 2026-08-01 08:16 and are mine

codex-package.json is identical in shape for both, and both carry the helpers under codex-resources/:

{"layoutVersion":1,"target":"x86_64-pc-windows-msvc","variant":"codex",
 "entrypoint":"bin/codex.exe","resourcesDir":"codex-resources","pathDir":"codex-path"}

So whether a user hits this appears to depend on whether a given build happens to duplicate the helpers into bin/ — the resolution logic itself is unchanged. That may explain why some reports get closed as fixed and then resurface.

The symptom timeline lines up exactly with the upgrade. Count of setup refresh: ... error=program not found per day in ~/.codex/.sandbox/sandbox.<date>.log:

Jul 23-28    0      (on 0.145.0)
Jul 28 21:18        0.146.0 installed
Jul 29     139
Jul 30     296

Nothing hard-fails, which is what makes it nasty — commands still run, but the elevated sandbox's setup refresh silently never executes.

2. A workaround that survives upgrades

Copying the helpers into bin/ works but has to be redone on every upgrade. Since the setup-helper spawn does resolve by bare name through PATH, putting the junction path on PATH instead is upgrade-proof:

%USERPROFILE%\.codex\packages\standalone\current\codex-resources

packages\standalone\current is a junction that the installer repoints at the new release directory, so the PATH entry keeps resolving after an upgrade with no manual step.

Verified by removing codex-windows-sandbox-setup.exe from bin/ entirely and running with only that PATH entry present:

setup refresh: spawning codex-windows-sandbox-setup.exe (cwd=..., payload_len=5188)
setup refresh: processed 0 write roots (read roots delegated); errors=[]
setup binary completed

The program not found counter stayed flat and the sandboxed command succeeded.

This only covers the setup helper spawn, which happens in the normal user environment. The command-runner is a separate path and already launches via an absolute path out of ~/.codex/.sandbox-bin/:

helper launch resolution: using copied command-runner path
  C:\Users\<user>\.codex\.sandbox-bin\codex-command-runner-0.146.0.exe

so the empty-environment CreateProcessWithLogonW problem described above is unaffected by the PATH entry either way.

One caveat for anyone applying this: write it via the registry / [Environment]::SetEnvironmentVariable, not setx — setx silently truncates PATH at 1024 characters.

yzyf1312 · 20 days ago

Confirmed still reproducible on 0.147.0 (Windows 11, standalone install).

A workaround variant that avoids copying helpers and survives upgrades - expose codex-resources at the visible install root via a junction to the active package:

New-Item -ItemType Junction `
  -Path "$env:LOCALAPPDATA\Programs\OpenAI\Codex\codex-resources" `
  -Target "$env:USERPROFILE\.codex\packages\standalone\current\codex-resources"

Why it works: with the visible launcher %LOCALAPPDATA%\Programs\OpenAI\Codex\bin\codex.exe, bundled_executable_path_for_exe sees the launcher's parent as ...\bin, derives package_dir as %LOCALAPPDATA%\Programs\OpenAI\Codex, and checks package_dir\codex-resources\<helper>. Both helpers resolve through that function - codex-windows-sandbox-setup.exe via find_setup_exe and codex-command-runner.exe via the helper copy path - so this single junction covers both lookup paths, independently of PATH (unlike adding current\codex-resources to PATH, which only covers the setup helper's bare-name spawn in the normal user environment).

Differences from the copy-into-bin workaround:

  • Survives upgrades: the target is packages\standalone\current, which the installer re-points to each new release, so nothing needs re-applying.
  • Takes effect in the current session: helper resolution happens at runtime, no restart required.
  • No files copied and package contents untouched; fully reversible by removing the junction.

Verified on 0.147.0: sandboxed command ran, .sandbox-bin materialized codex-command-runner-0.147.0.exe, codex doctor reports 17 ok / 1 idle / 0 warn / 0 fail.

This is the "expose resources at the visible root" direction from the 2026-07-16 comment (junction the package root), scoped down to just the resources directory - sufficient because both helpers only need package_dir\codex-resources. On the installer side, the gap is Ensure-Junction in install.ps1 only creating the visible bin junction and never a codex-resources one - that is why this fails out of the box on builds that ship helpers under codex-resources.

smartnuf · 20 days ago

Still reproducible on native Windows ARM64 with codex-cli 0.147.0 (2026-08-07).

Environment:

  • Windows 11 ARM64
  • Codex CLI 0.147.0, native aarch64-pc-windows-msvc
  • standalone install
  • native ARM64 PowerShell 7 installed by MSI under C:\Program Files\PowerShell\7\pwsh.exe

The standalone package itself is healthy and sandboxing works when launched through my existing workaround shim, which ensures the real package codex-resources directory is available.

However, invoking the installed AppData launcher directly still reproduces the helper-resolution failure:

& "$env:LOCALAPPDATA\Programs\OpenAI\Codex\bin\codex.exe" sandbox -- cmd /c echo test

Result:

windows sandbox failed: CreateProcessWithLogonW failed: 2

The real package is:

%USERPROFILE%\.codex\packages\standalone\current\
  -> releases\0.147.0-aarch64-pc-windows-msvc\

and its sandbox helpers are present under its codex-resources directory.

By contrast, my existing codex.cmd shim, which puts the real package resources on the appropriate search path before invoking Codex, succeeds:

codex sandbox -- cmd /c echo CODEX_ELEVATED_OK
CODEX_ELEVATED_OK

It also successfully launches the native MSI-installed:

C:\Program Files\PowerShell\7\pwsh.exe

inside the sandbox.

So this appears to confirm that the standalone launcher/helper-location issue described here remains present in 0.147.0 and is architecture-independent; this reproduction is native ARM64.