Windows: sandbox helper resolved by bare filename through a dangling PATH junction — every command fails before it runs

Summary

On Windows, launching the sandbox setup helper fails with error=program not found before any
user command runs, so every command in the session fails — including trivial ones like whoami.
The helper binary exists and is intact; the failure is a dangling PATH junction combined with a
change in how the helper is resolved (full path → bare filename).

Environment

Symptom

Reproduced 14/14 times. Identical text from exec_command and from the node_repl kernel:

orchestrator_helper_launch_failed: setup refresh failed to launch helper:
helper=codex-windows-sandbox-setup.exe,
cwd=C:\Program Files\WindowsApps\OpenAI.Codex_26.908.4834.0_x64__<hash>\app,
log=<USERPROFILE>\.codex\.sandbox\sandbox.<date>.log,
error=program not found

Failures include whoami and a JavaScript expression that only prints a string — the failure is in
the pre-execution setup step, not in the command. Granting additional file permissions via the
permission request flow does not help. require_escalated is rejected (cannot ask for escalated permissions, see issue 2 below).

Root cause

The app resolves the helper by bare filename, which Windows resolves through PATH. That PATH
entry is a directory junction whose target does not exist:

<USERPROFILE>\AppData\Local\Programs\OpenAI\Codex\bin          <- on the user PATH
      |  junction
      v
<USERPROFILE>\.codex\packages\standalone\current\bin
      |
      v
<USERPROFILE>\.codex\packages\...      <- MISSING ENTIRELY

CreateProcess returns ERROR_FILE_NOT_FOUND (2). The helper is present and intact in three
separate runtime directories (<USERPROFILE>\AppData\Local\OpenAI\Codex\bin\<hash>\), so this is a
path-resolution failure, not a packaging gap.

Evidence

(a) The resolution method changed — full path → bare filename. Not present in 13 days of logs,
then appears exactly when the failure starts:

# before — resolves fine
setup refresh: spawning <USERPROFILE>\AppData\Local\OpenAI\Codex\bin\<hash>\codex-windows-sandbox-setup.exe
setup binary completed

# after — bare filename, fails
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

(b) Per-day counts of the two forms (from <USERPROFILE>\.codex\.sandbox\sandbox.*.log):

The correlation is with the build, not with the date.

(c) The junction is dangling — Test-Path on the shim returns True (the junction itself
exists) while Get-ChildItem on it throws DirectoryNotFoundException. That combination is the
fingerprint of a dangling junction.

Reproduction

Cannot be reproduced from a clean install — the missing packages tree is a precondition. To
simulate it: rename <USERPROFILE>\.codex\packages\standalone\current and run any command.
To recover: recreate the tree (see Suggested fix).

Impact

Total. Every command in every session fails, in every execution channel (exec_command, the
node_repl kernel, and anything built on them such as CUA/computer-use). Skills that depend on a
shell all fail. The app's own MCP tools keep working, which makes it look like a partial outage
rather than a total one.

Suggested fix

Consider resolving the helper relative to the package layout instead of relying on PATH, or
resolving the junction target with GetFinalPathNameByHandle and falling back when it does not
exist. A dangling junction currently produces the same error as a genuinely missing file, which
makes this hard to diagnose from the error text alone.

Start at the sandbox setup refresh path that spawns codex-windows-sandbox-setup.exe, comparing the logged full-path and bare-filename resolution behavior. Reproduce by renaming the standalone/current package tree and verify that commands execute or produce a diagnostic that distinguishes a dangling PATH junction from a genuinely missing helper.