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

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

What version of Codex CLI is running?

codex-cli 0.142.5

What subscription do you have?

Enterprise

Which model were you using?

gpt-5.5

What platform is your computer?

Microsoft Windows NT 10.0.28000.0 x64

What terminal emulator and version are you using (if applicable)?

_No response_

Codex doctor report

{
  "schemaVersion": 1,
  "generatedAt": "1782914399s since unix epoch",
  "overallStatus": "ok",
  "codexVersion": "0.142.5",
  "checks": {
    "app_server.status": {
      "id": "app_server.status",
      "category": "app-server",
      "status": "ok",
      "summary": "background server is not running",
      "details": {
        "control socket": "C:\\Users\\vboxuser\\.codex\\app-server-control\\app-server-control.sock",
        "daemon state dir": "C:\\Users\\vboxuser\\.codex\\app-server-daemon",
        "mode": "ephemeral",
        "pid file": "C:\\Users\\vboxuser\\.codex\\app-server-daemon\\app-server.pid (missing)",
        "settings": "C:\\Users\\vboxuser\\.codex\\app-server-daemon\\settings.json (missing)",
        "status": "not running",
        "update-loop pid file": "C:\\Users\\vboxuser\\.codex\\app-server-daemon\\app-server-updater.pid (missing)"
      },
      "remediation": null,
      "durationMs": 0
    },
    "auth.credentials": {
      "id": "auth.credentials",
      "category": "auth",
      "status": "ok",
      "summary": "auth is configured",
      "details": {
        "auth file": "C:\\Users\\vboxuser\\.codex\\auth.json",
        "auth storage mode": "File",
        "stored API key": "false",
        "stored ChatGPT tokens": "true",
        "stored agent identity": "false",
        "stored auth mode": "chatgpt"
      },
      "remediation": null,
      "durationMs": 0
    },
    "config.load": {
      "id": "config.load",
      "category": "config",
      "status": "ok",
      "summary": "config loaded",
      "details": {
        "CODEX_HOME": "C:\\Users\\vboxuser\\.codex",
        "config.toml": "C:\\Users\\vboxuser\\.codex\\config.toml",
        "config.toml parse": "ok",
        "cwd": "C:\\Users\\vboxuser",
        "enabled feature flags": "<redacted>",
        "feature flag overrides": "none",
        "feature flags enabled": "33",
        "log dir": "C:\\Users\\vboxuser\\.codex\\log",
        "mcp servers": "0",
        "model": "<default>",
        "model provider": "openai",
        "sqlite home": "C:\\Users\\vboxuser\\.codex"
      },
      "remediation": null,
      "durationMs": 0
    },
    "git.environment": {
      "id": "git.environment",
      "category": "git",
      "status": "ok",
      "summary": "git executable not found",
      "details": {
        "PATH git entries": "0",
        "repo detected": "false",
        "selected git": "not found"
      },
      "remediation": null,
      "durationMs": 5
    },
    "installation": {
      "id": "installation",
      "category": "install",
      "status": "ok",
      "summary": "installation looks consistent",
      "details": {
        "PATH codex #1": "C:\\Users\\vboxuser\\AppData\\Local\\Programs\\OpenAI\\Codex\\bin\\codex.exe",
        "current executable": "C:\\Users\\vboxuser\\AppData\\Local\\Programs\\OpenAI\\Codex\\bin\\codex.exe",
        "install context": "standalone (windows, package C:\\Users\\vboxuser\\.codex\\packages\\standalone\\releases\\0.142.5-x86_64-pc-windows-msvc, bin C:\\Users\\vboxuser\\.codex\\packages\\standalone\\releases\\0.142.5-x86_64-pc-windows-msvc\\bin, resources C:\\Users\\vboxuser\\.codex\\packages\\standalone\\releases\\0.142.5-x86_64-pc-windows-msvc\\codex-resources, path C:\\Users\\vboxuser\\.codex\\packages\\standalone\\releases\\0.142.5-x86_64-pc-windows-msvc\\codex-path)",
        "managed by bun": "false",
        "managed by npm": "false",
        "managed package root": "not set"
      },
      "remediation": null,
      "durationMs": 75
    },
    "mcp.config": {
      "id": "mcp.config",
      "category": "mcp",
      "status": "ok",
      "summary": "no MCP servers configured",
      "details": {},
      "remediation": null,
      "durationMs": 0
    },
    "network.env": {
      "id": "network.env",
      "category": "network",
      "status": "ok",
      "summary": "network-related environment looks readable",
      "details": {
        "proxy env vars": "none"
      },
      "remediation": null,
      "durationMs": 0
    },
    "network.provider_reachability": {
      "id": "network.provider_reachability",
      "category": "reachability",
      "status": "ok",
      "summary": "active provider endpoints are reachable over HTTP",
      "details": {
        "ChatGPT base URL": "https://chatgpt.com/backend-api/ reachable (HTTP 403)",
        "reachability mode": "ChatGPT auth"
      },
      "remediation": null,
      "durationMs": 102
    },
    "network.websocket_reachability": {
      "id": "network.websocket_reachability",
      "category": "websocket",
      "status": "ok",
      "summary": "Responses WebSocket handshake succeeded",
      "details": {
        "DNS": "2 IPv4, 2 IPv6, first IPv4",
        "auth mode": "chatgpt",
        "connect timeout": "15000 ms",
        "endpoint": "wss://chatgpt.com/backend-api/<redacted>",
        "handshake result": "HTTP 101 Switching Protocols",
        "model provider": "openai",
        "models etag present": "true",
        "provider name": "OpenAI",
        "proxy env vars": "none",
        "reasoning header": "false",
        "server model present": "false",
        "supports websockets": "true",
        "wire API": "responses"
      },
      "remediation": null,
      "durationMs": 568
    },
    "runtime.provenance": {
      "id": "runtime.provenance",
      "category": "runtime",
      "status": "ok",
      "summary": "running standalone on windows-x86_64",
      "details": {
        "commit": "unknown",
        "current executable": "C:\\Users\\vboxuser\\AppData\\Local\\Programs\\OpenAI\\Codex\\bin\\codex.exe",
        "install method": "standalone (windows, package C:\\Users\\vboxuser\\.codex\\packages\\standalone\\releases\\0.142.5-x86_64-pc-windows-msvc, bin C:\\Users\\vboxuser\\.codex\\packages\\standalone\\releases\\0.142.5-x86_64-pc-windows-msvc\\bin, resources C:\\Users\\vboxuser\\.codex\\packages\\standalone\\releases\\0.142.5-x86_64-pc-windows-msvc\\codex-resources, path C:\\Users\\vboxuser\\.codex\\packages\\standalone\\releases\\0.142.5-x86_64-pc-windows-msvc\\codex-path)",
        "platform": "windows-x86_64",
        "version": "0.142.5"
      },
      "remediation": null,
      "durationMs": 0
    },
    "runtime.search": {
      "id": "runtime.search",
      "category": "search",
      "status": "ok",
      "summary": "search is OK (bundled)",
      "details": {
        "search command": "C:\\Users\\vboxuser\\.codex\\packages\\standalone\\releases\\0.142.5-x86_64-pc-windows-msvc\\codex-path\\rg.exe",
        "search command readiness": "file exists",
        "search provider": "bundled"
      },
      "remediation": null,
      "durationMs": 0
    },
    "sandbox.helpers": {
      "id": "sandbox.helpers",
      "category": "sandbox",
      "status": "ok",
      "summary": "sandbox configuration is readable",
      "details": {
        "approval policy": "OnRequest",
        "codex-linux-sandbox helper": "none",
        "execve wrapper helper": "none",
        "filesystem sandbox": "restricted",
        "network sandbox": "restricted"
      },
      "remediation": null,
      "durationMs": 0
    },
    "state.paths": {
      "id": "state.paths",
      "category": "state",
      "status": "ok",
      "summary": "state paths and databases are inspectable",
      "details": {
        "CODEX_HOME": "C:\\Users\\vboxuser\\.codex (dir)",
        "active rollout files": "0 files, 0 total bytes, 0 average bytes",
        "archived rollout files": "0 files, 0 total bytes, 0 average bytes",
        "goals DB": "C:\\Users\\vboxuser\\.codex\\goals_1.sqlite (file)",
        "goals DB integrity": "ok",
        "log DB": "C:\\Users\\vboxuser\\.codex\\logs_2.sqlite (file)",
        "log DB integrity": "ok",
        "log dir": "C:\\Users\\vboxuser\\.codex\\log (missing)",
        "memories DB": "C:\\Users\\vboxuser\\.codex\\memories_1.sqlite (file)",
        "memories DB integrity": "ok",
        "sqlite home": "C:\\Users\\vboxuser\\.codex (dir)",
        "standalone release cache": "1 entries in C:\\Users\\vboxuser\\.codex\\packages\\standalone\\releases",
        "state DB": "C:\\Users\\vboxuser\\.codex\\state_5.sqlite (file)",
        "state DB integrity": "ok"
      },
      "remediation": null,
      "durationMs": 102
    },
    "state.rollout_db_parity": {
      "id": "state.rollout_db_parity",
      "category": "threads",
      "status": "ok",
      "summary": "rollout files and state DB thread inventory agree",
      "details": {
        "default model provider": "openai",
        "rollout DB active files": "0",
        "rollout DB active rows": "0",
        "rollout DB archive mismatches": "0",
        "rollout DB archived files": "0",
        "rollout DB archived rows": "0",
        "rollout DB duplicate DB paths": "0",
        "rollout DB duplicate rollout thread ids": "0",
        "rollout DB malformed file names": "0",
        "rollout DB missing active rows": "0",
        "rollout DB missing archived rows": "0",
        "rollout DB model providers": "none",
        "rollout DB rows": "0",
        "rollout DB scan cap reached": "false",
        "rollout DB scan errors": "0",
        "rollout DB sources": "none",
        "rollout DB stale rows": "0"
      },
      "remediation": null,
      "durationMs": 8
    },
    "system.environment": {
      "id": "system.environment",
      "category": "system",
      "status": "ok",
      "summary": "OS language en-US",
      "details": {
        "EDITOR": "not set",
        "VISUAL": "not set",
        "os": "Windows 10.0.28000 (Windows 11 Professional) [64-bit]",
        "os language": "en-US",
        "os type": "Windows",
        "os version": "10.0.28000"
      },
      "remediation": null,
      "durationMs": 0
    },
    "terminal.env": {
      "id": "terminal.env",
      "category": "terminal",
      "status": "ok",
      "summary": "terminal metadata was detected",
      "details": {
        "WT_SESSION": "present",
        "color output": "enabled",
        "console input code page": "437",
        "console output code page": "437",
        "stderr console mode": "0x00000007 (VT processing: true)",
        "stderr is terminal": "true",
        "stdin is terminal": "true",
        "stdout console mode": "0x00000007 (VT processing: true)",
        "stdout is terminal": "true",
        "terminal": "Windows Terminal",
        "terminal size": "120x30"
      },
      "remediation": null,
      "durationMs": 2
    },
    "terminal.title": {
      "id": "terminal.title",
      "category": "title",
      "status": "ok",
      "summary": "terminal title default",
      "details": {
        "terminal title activity": "true",
        "terminal title items": "activity, project-name",
        "terminal title project source": "cwd",
        "terminal title project value": "vboxuser",
        "terminal title source": "default"
      },
      "remediation": null,
      "durationMs": 0
    },
    "updates.status": {
      "id": "updates.status",
      "category": "updates",
      "status": "ok",
      "summary": "update configuration is locally consistent",
      "details": {
        "cached latest version": "0.142.5",
        "check for update on startup": "true",
        "last checked at": "2026-07-01T13:59:15.103243600Z",
        "latest version": "0.142.5",
        "latest version status": "current version is not older",
        "update action": "standalone installer",
        "version cache": "C:\\Users\\vboxuser\\.codex\\version.json"
      },
      "remediation": null,
      "durationMs": 287
    }
  }
}

What issue are you seeing?

During setup of Codex CLI on a clean Windows virtual machine, the elevated sandbox setup fails with the following error dialog:

codex-windows-sandbox-setup.exe
Windows cannot find 'codex-windows-sandbox-setup.exe

What steps can reproduce the bug?

On a clean virtual computer with only Windows 11 installed:

  1. Open a Terminal window with a PowerShell session
  2. Run $env:CODEX_NON_INTERACTIVE=1; irm https://chatgpt.com/codex/install.ps1 | iex
==> Installing Codex CLI
==> Detected platform: Windows (x64)
==> Resolved version: 0.142.5
==> Downloading Codex CLI
==> PATH updated for future PowerShell sessions.
==> Current PowerShell session: codex
==> Future PowerShell windows: open a new PowerShell window and run: codex
Codex CLI 0.142.5 installed successfully.
  1. Run codex, sign in with ChatGPT, and trust the current directory. It asks about setting up the Codex agent sandbox:
  Set up the Codex agent sandbox to protect your files and control network access. Learn more
  <https://developers.openai.com/codex/windows>

› 1. Set up default sandbox (requires Administrator permissions)
  2. Use non-admin sandbox (higher risk if prompt injected)
  3. Quit
  1. Choose the first option to run the elevated sandbox setup.
  2. Note that you get an error dialog:

<img width="418" height="100" alt="codex-windows-sandbox-setup.exe
Windows cannot find 'codex-windows-sandbox-setup.exe'. Make sure you typed the name correctly, and then try again." src="https://github.com/user-attachments/assets/f34749b6-f361-4ac7-b387-b3665a47c181" />

  1. Retrying shows the same error. Instead choose Quit and reset the virtual machine.
  2. Perform steps 1–4 again but this time launch & "$env:userprofile\.codex\packages\standalone\releases\0.142.5-x86_64-pc-windows-msvc\bin\codex" instead of plain codex.
  3. Note that now you correctly get a UAC prompt and the elevated sandbox is set up.

What is the expected behavior?

The elevated sandbox should be set up correctly when running the Codex CLI through the codex binary on the PATH.

Additional information

It seems like the issue is related to the junction at %LOCALAPPDATA%\Programs\OpenAI\Codex\bin (which is on the PATH) and to how codex tries to look up and/or run the codex-windows-sandbox-setup.exe file. Possibly a regression from 9d1bf00 that introduced the junction or 61aae56 that centralized the lookup for executables.

Either way, the helper_materialization.bundled_executable_path_for_exe function seems to assume that the executable can be found as a sibling to the current executable or inside a codex-resources directory next to the current executable or its bin parent. This is not true when the path to codex.exe is %LOCALAPPDATA%\Programs\OpenAI\Codex\bin\codex.exe.

A possible fix would be make the junction point to the whole package instead of just bin, either making Codex the junction (to keep the path the same) or creating a new package junction instead of bin and put ...\package\bin on the PATH instead.

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 19 days ago

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

  • #30047
  • #30732

Powered by Codex Action

msternermxy · 19 days ago
* 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.

JanSafronov · 11 days ago

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.

JanSafronov · 11 days ago

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.

JanSafronov · 11 days ago

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.

smartnuf · 10 days ago

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.

starriet9 · 8 days ago

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.