codex-windows-sandbox-setup.exe not found by CLI setup after clean install due to bin junction

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

• #30047
• #30732

Powered by Codex Action

* Codex Windows sandbox repeatedly fails to launch command runner. #30047

I didn't understand the steps to reproduce. Possibly the bug reported here is what is meant by the note in step 1, but the rest sounds more like an issue with the sandbox setup itself.

* Windows app sandbox helpers are packaged under resources but launcher searches app/PATH #30732

This seems to be a related issue with the Codex App. The steps to reproduce were too unclear for me to follow but seems different, and possibly also the fix would be different if it targets the installation mechanism instead of the executable lookup.

Workaround found for the standalone Windows CLI case on codex-cli 0.144.0.

In my install, Codex was launched from the PATH shim/junction location:

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

and sandboxed file edits failed with:

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

A direct check showed the helper was not present next to the active codex.exe:

Test-Path "$env:LOCALAPPDATA\Programs\OpenAI\Codex\bin\codex-windows-sandbox-setup.exe"
# False

But the helper did exist in the real installed/cache location:

C:\Users\<user>\AppData\Local\OpenAI\Codex\bin\ea1c60319a1dcb19\codex-windows-sandbox-setup.exe

Size observed: 8833328 bytes.

The workaround was to copy the signed helper from the actual package/cache location into the bin directory where the active codex.exe expects to resolve it.

$helper = "$env:LOCALAPPDATA\OpenAI\Codex\bin\ea1c60319a1dcb19\codex-windows-sandbox-setup.exe"
$target = "$env:LOCALAPPDATA\Programs\OpenAI\Codex\bin\codex-windows-sandbox-setup.exe"

Get-AuthenticodeSignature $helper | Format-List Status, SignerCertificate
# Continue only if Status is Valid / trusted.

Copy-Item -LiteralPath $helper -Destination $target -Force

Test-Path $target
Get-Item $target | Select-Object FullName, Length

After this, the immediate program not found failure should be bypassed. This is only a local workaround, not the real fix: the CLI should either resolve helpers from the real package/cache location or materialize/copy the helper into the PATH-facing Programs\OpenAI\Codex\bin directory during install/update.

Related diagnostic command that exposed the mismatch:

Get-ChildItem "$env:LOCALAPPDATA\OpenAI\Codex" -Recurse -Filter "codex-windows-sandbox-setup.exe" -ErrorAction SilentlyContinue |
  Select-Object FullName, Length

This seems consistent with the issue title: the helper exists, but the active CLI lookup path is wrong because codex.exe is reached through the Programs\OpenAI\Codex\bin path while the helper lives elsewhere.

Correction / better workaround source:

Do not blindly use the helper from %LOCALAPPDATA%\OpenAI\Codex\bin\<hash>\.... On my machine that hash directory existed, but launching from it ran an older Codex (v0.142.5).

For the standalone CLI, the matching 0.144.0 helpers were present under the standalone package cache:

C:\Users\<user>\.codex\packages\standalone\current\bin\codex-windows-sandbox-setup.exe
C:\Users\<user>\.codex\packages\standalone\current\codex-resources\codex-windows-sandbox-setup.exe
C:\Users\<user>\.codex\packages\standalone\releases\0.144.0-x86_64-pc-windows-msvc\bin\codex-windows-sandbox-setup.exe
C:\Users\<user>\.codex\packages\standalone\releases\0.144.0-x86_64-pc-windows-msvc\codex-resources\codex-windows-sandbox-setup.exe

So the safer workaround is to copy from ~\.codex\packages\standalone\current\... or the exact matching release folder, not from the stale %LOCALAPPDATA%\OpenAI\Codex\bin\<hash> cache.

Example:

$dst = "$env:LOCALAPPDATA\Programs\OpenAI\Codex\bin"
$src = "$env:USERPROFILE\.codex\packages\standalone\current\bin"

Get-ChildItem $src -Filter "*.exe" |
  Where-Object { $_.Name -like "*sandbox*" -or $_.Name -like "*runner*" } |
  ForEach-Object {
    Get-AuthenticodeSignature $_.FullName | Format-List Status, Path, SignerCertificate
  }

Get-ChildItem $src -Filter "*.exe" |
  Where-Object { $_.Name -like "*sandbox*" -or $_.Name -like "*runner*" } |
  Copy-Item -Destination $dst -Force

Get-ChildItem $dst |
  Where-Object { $_.Name -like "*sandbox*" -or $_.Name -like "*runner*" } |
  Select-Object FullName, Length

If CreateProcessWithLogonW failed: 2 appears after fixing codex-windows-sandbox-setup.exe, that may indicate another helper/runner executable is also being resolved from the PATH-facing Programs\OpenAI\Codex\bin directory but only exists in the real standalone package cache. Copying all signed *sandbox* / *runner* helper executables from standalone\current\bin into the PATH-facing bin folder is the local workaround.

Also, if switching back to [windows] sandbox = "elevated" after the helper copy produces:

helper_setup_marker_write_failed: create protected setup marker file C:\Users\<user>\.codex\.sandbox\setup_marker.json failed: 80

then removing/renaming the stale sandbox state can help:

Stop-Process -Name codex -Force -ErrorAction SilentlyContinue
$sandbox = "$env:USERPROFILE\.codex\.sandbox"
if (Test-Path $sandbox) {
  Rename-Item $sandbox "$sandbox.broken.$((Get-Date).ToString('yyyyMMddHHmmss'))"
}

Then restart Codex with the matching helpers copied from ~\.codex\packages\standalone\current.

Final tip after getting the local Windows CLI sandbox workable again:

There are two separate missing-helper symptoms in this layout bug.

1. Missing sandbox setup helper:

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

Fix/workaround: copy the matching codex-windows-sandbox-setup.exe from the standalone package cache, preferably:

%USERPROFILE%\.codex\packages\standalone\current\bin\codex-windows-sandbox-setup.exe

into:

%LOCALAPPDATA%\Programs\OpenAI\Codex\bin\codex-windows-sandbox-setup.exe

1. Missing command runner after the setup helper is fixed:

The sandbox log may then show:

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

and commands fail with:

windows sandbox: CreateProcessWithLogonW failed: 2

Fix/workaround: also copy the matching codex-command-runner.exe from the standalone package cache into both expected locations:

%LOCALAPPDATA%\Programs\OpenAI\Codex\bin\codex-command-runner.exe
%LOCALAPPDATA%\Programs\OpenAI\Codex\codex-resources\codex-command-runner.exe

A compact local workaround script:

$srcBin = "$env:USERPROFILE\.codex\packages\standalone\current\bin"
$dstBin = "$env:LOCALAPPDATA\Programs\OpenAI\Codex\bin"
$dstRes = "$env:LOCALAPPDATA\Programs\OpenAI\Codex\codex-resources"

New-Item -ItemType Directory -Force $dstBin, $dstRes | Out-Null

# Optional: stop Codex first so files are not locked.
taskkill /IM codex.exe /F
taskkill /IM codex-windows-sandbox-setup.exe /F
taskkill /IM codex-command-runner.exe /F

Copy-Item "$srcBin\codex-windows-sandbox-setup.exe" "$dstBin\codex-windows-sandbox-setup.exe" -Force
Copy-Item "$srcBin\codex-command-runner.exe" "$dstBin\codex-command-runner.exe" -Force
Copy-Item "$srcBin\codex-command-runner.exe" "$dstRes\codex-command-runner.exe" -Force

# Verify the important files are present.
Test-Path "$dstBin\codex-windows-sandbox-setup.exe"
Test-Path "$dstBin\codex-command-runner.exe"
Test-Path "$dstRes\codex-command-runner.exe"

If copying says the .exe is being used by another process, either stop Codex/sandbox processes first or reboot and copy before launching Codex.

After copying, it may help to reset only the sandbox state:

$sandbox = "$env:USERPROFILE\.codex\.sandbox"
if (Test-Path $sandbox) {
  Rename-Item $sandbox "$sandbox.broken.$((Get-Date).ToString('yyyyMMddHHmmss'))"
}

Then use:

sandbox_mode = "workspace-write"
approval_policy = "on-request"

[windows]
sandbox = "elevated"

After this, normal sandboxed reads and apply_patch edits became workable locally.

One remaining expected/acceptable behavior: Git commands that mutate .git metadata can still require escalation, e.g.:

fatal: Unable to create '.git/index.lock': Permission denied

That happens for commands like git restore, git add, git update-index, etc., because they create/update .git/index.lock. In this state, the sandbox itself is working; approve narrowly scoped Git metadata commands case-by case rather than treating it as the original helper lookup failure.

This is still reproducible with Codex CLI 0.144.1 on native Windows ARM64.

Environment:

• Windows 11, build 10.0.26200
• ARM64
• Codex CLI 0.144.1
• Native package: 0.144.1-aarch64-pc-windows-msvc
• Normal launcher:

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

Both required helpers are present in the current 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

Their sizes in this installation are:

codex-windows-sandbox-setup.exe  7,761,200 bytes
codex-command-runner.exe         1,092,912 bytes

Nevertheless, when Codex is invoked using the normal installed launcher, sandboxed commands fail with:

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

The sandbox log contains:

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

Adding the package's current resources directory to PATH allows Codex to find the helpers:

$package = (Resolve-Path "$HOME\.codex\packages\standalone\current").Path
$env:Path = "$package\codex-resources;$env:Path"
& "$package\bin\codex.exe"

This confirms that the ARM64 package contains the correct helper executables, but the normal installed launcher does not expose or resolve its matching codex-resources directory.

The problem therefore appears to persist beyond 0.142.5 and is not x64-specific.

It would also be useful if codex doctor checked that both Windows helper executables can actually be resolved from the runtime launch context, rather than merely reporting that the standalone installation is consistent.

Thanks @smartnuf for the independent ARM64 reproduction on 0.144.1. That confirms the standalone helper-discovery failure is not limited to x64 or to the original 0.142.5 package.

The newer #32359 report provides another useful data point on 0.144.1: the normal installed PATH entry fails after attempting to spawn codex-windows-sandbox-setup.exe by bare name, while launching through the active package's current\bin path succeeds. That behavior is consistent with helper lookup being anchored to the visible standalone bin Junction rather than its resolved release path.

I refreshed the Junction-path candidate onto current main (9e552e9d1, checked on 2026-07-12) and reran its real Windows Junction regression test.

Branch:

https://github.com/starriet9/codex/tree/fix/windows-sandbox-helper-junction

Current commit:

https://github.com/starriet9/codex/commit/6dc8d424aec6597196a4c182cd6bd4b6300ca389

The reproduced standalone layout is:

%LOCALAPPDATA%\Programs\OpenAI\Codex\bin
  -> Junction to the active release bin

<release>\bin\codex.exe
<release>\codex-resources\codex-command-runner.exe
<release>\codex-resources\codex-windows-sandbox-setup.exe

Lookup from the visible current_exe() path searches around the Junction's visible parent and misses the release's sibling codex-resources directory. The candidate preserves the existing literal lookup first, then retries the same lookup from dunce::canonicalize(exe). Canonicalization resolves the Junction to the real release bin, allowing ../codex-resources to find both matching helper binaries without changing the installer layout or relying on PATH.

The regression test creates an actual directory Junction with mklink /J and verifies both sides of the behavior: literal lookup misses the helpers, while the canonicalized fallback finds both.

Current-main validation on Windows:

just test -p codex-windows-sandbox helper_source_lookup
just fix -p codex-windows-sandbox
cargo fmt --all -- --check
git diff --check origin/main...HEAD

All 5 helper-source lookup tests passed, including the real Junction test, and the Clippy fix pass completed without changing the source. Rustfmt and diff checks also passed.

An earlier full-crate run of the same one-file candidate passed 131 of 133 tests. The two unrelated failures were legacy_capture_cancellation_is_not_reported_as_timeout and legacy_workspace_write_delete_is_limited_to_writable_roots; both failed identically from unmodified main in the same environment.

This candidate is scoped to the standalone Junction layout. It does not claim to fix the distinct Desktop app\resources packaging layout reported in #30732. The branch remains a one-file, one-commit change and is ready for a focused PR invitation if maintainers want this fix.

I experienced the same issue on my Windows system.

I installed the Codex CLI from PowerShell using:

powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex"

mode.

The sandbox log showed:

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

I then found this Korean blog post and tried its workaround:

Codex CLI Windows Sandbox 실행 불가 문제 해결하기

First, I only added the standalone package resource directories to PATH:

$root = "$env:USERPROFILE\.codex\packages\standalone\current"
$env:Path = "$root\codex-resources;$root\codex-path;$env:Path"

After this change, the Windows alert about the missing codex-windows-sandbox-setup.exe no longer appeared. However, sandboxed commands still failed with:

windows sandbox: CreateProcessWithLogonW failed: 2

Therefore, adding the resource directories to PATH alone was not sufficient.

I also encountered the following separate helper-launch error during troubleshooting:

orchestrator_helper_launch_canceled: ShellExecuteExW failed to launch setup helper: 1223

Finally, I added the following function-based workaround from the blog post to my PowerShell profile:

function codex {
  $root = (Resolve-Path "$env:USERPROFILE\.codex\packages\standalone\current").Path
  $oldPath = $env:Path

  try {
    $env:Path = "$root\codex-resources;$root\codex-path;$oldPath"
    & "$root\bin\codex.exe" @args
  } finally {
    $env:Path = $oldPath
  }
}

After starting a new Codex session through this PowerShell profile function, sandboxed commands worked correctly again. For example, a previously failing Get-ChildItem command succeeded.

I checked the resolution order with Get-Command codex -All. Without the function, the executable resolved to:

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

With the function in the PowerShell profile, codex instead explicitly launches:

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

This executable-path change, together with the matching codex-resources and codex-path directories, appears to be the key difference. Adding those directories to PATH alone did not fix sandbox execution; starting the matching
standalone codex.exe did.

Additional source and package validation against official rust-v0.147.0: the standalone Junction failure remains in the redesigned helper-materialization path.

Current main obtains the visible current_exe() path and performs only literal sibling/package-resource checks:

• https://github.com/openai/codex/blob/1f4ea798538d2c947ce215a65bc166db517a2df6/codex-rs/windows-sandbox-rs/src/helper_materialization.rs#L184-L211

For the standalone layout, that visible path is under the installed bin Junction while codex-resources is a sibling of the real release bin. The literal lookup therefore cannot see the matching helpers.

I semantically ported the earlier candidate to 0.147's materialization code:

1. Keep the existing literal lookup first.
2. Only when it fails, canonicalize the executable path through the Junction.
3. Retry the exact same direct/package-resource lookup against the resolved release path.

Validation used a real NTFS directory Junction, not a mocked path. The visible package root deliberately had no codex-resources, while the Junction target's release package did. The fallback found the matching helper, and the packaged CLI completed isolated shell/patch smoke plus the later controlled Windows sandbox runner/setup validation without copying helpers beside the installed Junction entry point.

This is still scoped to the standalone package-Junction shape. It does not claim to fix the distinct Microsoft Store/Desktop resource layout in #30732. The old public branch demonstrates the same literal-first/canonicalized-fallback algorithm, but the 0.147 port adapts it to the newer helper materialization architecture rather than applying that patch mechanically.

I faced this issue myself. The following recap is AI-written.

Still reproduces on codex-cli 0.147.0 (standalone installer, Windows 11 Home 10.0.26200).

I can add the "why" for recent versions. Comparing the two release packages cached under
%USERPROFILE%\.codex\packages\standalone\releases\:

• 0.145.0-x86_64-pc-windows-msvc ships codex-windows-sandbox-setup.exe and

codex-command-runner.exe in BOTH bin\ and codex-resources\

• 0.147.0-x86_64-pc-windows-msvc ships them ONLY in codex-resources\. Its bin\ holds just

codex.exe and codex-code-mode-host.exe

The resolver still looks for the helper as a program (next to the running exe or on PATH,
where the only entry is the %LOCALAPPDATA%\Programs\OpenAI\Codex\bin junction, which never
had it). The packaging moved the file; the lookup did not move with it.

Exact failure:

codex sandbox -- cmd /c "type package.json"
windows sandbox failed: orchestrator_helper_launch_failed: setup refresh failed to
launch helper: helper=codex-windows-sandbox-setup.exe, error=program not found

Workaround verified end to end: copy the two exes from the release's codex-resources\ into
that release's bin\ and into %LOCALAPPDATA%\Programs\OpenAI\Codex\bin\. After that,
codex exec --sandbox read-only reads files correctly again. (A later codex update will
probably drop the copies.)

Two side effects that make this worse than a hard failure:

1. codex doctor reports the sandbox section green the whole time. It seems to report

policy, not an actual sandboxed read. Same family as #24259.

1. With the helper missing, codex exec does not error. It answers without file access and

can fabricate: asked for the "name" field of package.json, it returned the directory
name instead. Only a prompt demanding a verbatim line, with "reply CANNOT-READ if you
cannot read the file", made it admit it had no access.

Suggested guards: a packaging test asserting every helper the resolver can name exists in
a directory it actually searches, and a doctor check that performs one real sandboxed
file read.

I used Claude to resolve this unfortunate Codex issue. Basically, the steps were:

Symptom: Codex CLI works fine until it tries to run a shell command, then you get a native Windows error dialog saying:

▎ Windows cannot find 'codex-windows-sandbox-setup.exe'. Make sure you typed the name correctly, and then try again.

Every command after that just spins/fails.

What's actually going on: By default on Windows, Codex sets sandbox = "elevated" under [windows] in your config. That mode needs to do a one-time elevated (UAC) setup step, which calls a helper binary called codex-windows-sandbox-setup.exe to configure the sandbox. That helper genuinely exists on disk (I checked — it's buried under %LOCALAPPDATA%\OpenAI\Codex\bin<hash>), so it's not a missing/corrupted install. The problem is in how Codex tries to auto-elevate and launch it — that step is broken right now, and Windows just throws the generic "cannot find" dialog instead of a real error, because the process never even got created.

The fix: Open your Codex config file at %USERPROFILE%.codex\config.toml and find:
buried under %LOCALAPPDATA%\OpenAI\Codex\bin<hash>), so it's not a missing/corrupted install. The problem is in how Codex tries to auto-elevate and launch it — that step is broken right now, and Windows just throws the generic "cannot find" dialog instead of a real error, becauscreated.

The fix: Open your Codex config file at %USERPROFILE%.codex\config.toml and find:

[windows]
sandbox = "elevated"

Change it to:

[windows]
sandbox = "unelevated"

(FYI, elevated and unelevated are the only t it you'll get a config parse error tellingyou exactly that, which is how I confirmed it.)

Save the file, then test it without even ope

codex sandbox -- whoami

If it prints your username with no popup, you're good — the sandbox is now running commands without needing that broken UAC/elevation path at all.

No reinstall needed, no need to mess with PATH, registry, or scheduled tasks — it's purely a one-line config change.