codex-windows-sandbox-setup.exe not found by CLI setup after clean install due to bin junction
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:
- Open a Terminal window with a PowerShell session
- 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.
- 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
- Choose the first option to run the elevated sandbox setup.
- 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" />
- Retrying shows the same error. Instead choose Quit and reset the virtual machine.
- 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 plaincodex. - 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.
7 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
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.
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:
and sandboxed file edits failed with:
A direct check showed the helper was not present next to the active
codex.exe:But the helper did exist in the real installed/cache location:
Size observed:
8833328bytes.The workaround was to copy the signed helper from the actual package/cache location into the
bindirectory where the activecodex.exeexpects to resolve it.After this, the immediate
program not foundfailure 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-facingPrograms\OpenAI\Codex\bindirectory during install/update.Related diagnostic command that exposed the mismatch:
This seems consistent with the issue title: the helper exists, but the active CLI lookup path is wrong because
codex.exeis reached through thePrograms\OpenAI\Codex\binpath 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.0helpers were present under the standalone package cache: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:
If
CreateProcessWithLogonW failed: 2appears after fixingcodex-windows-sandbox-setup.exe, that may indicate another helper/runner executable is also being resolved from the PATH-facingPrograms\OpenAI\Codex\bindirectory but only exists in the real standalone package cache. Copying all signed*sandbox*/*runner*helper executables fromstandalone\current\bininto the PATH-facingbinfolder is the local workaround.Also, if switching back to
[windows] sandbox = "elevated"after the helper copy produces:then removing/renaming the stale sandbox state can help:
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.
Fix/workaround: copy the matching
codex-windows-sandbox-setup.exefrom the standalone package cache, preferably:into:
The sandbox log may then show:
and commands fail with:
Fix/workaround: also copy the matching
codex-command-runner.exefrom the standalone package cache into both expected locations:A compact local workaround script:
If copying says the
.exeis 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:
Then use:
After this, normal sandboxed reads and
apply_patchedits became workable locally.One remaining expected/acceptable behavior: Git commands that mutate
.gitmetadata can still require escalation, e.g.: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:
0.144.1-aarch64-pc-windows-msvcC:\Users\<user>\AppData\Local\Programs\OpenAI\Codex\bin\codex.exeBoth required helpers are present in the current standalone package:
Their sizes in this installation are:
Nevertheless, when Codex is invoked using the normal installed launcher, sandboxed commands fail with:
The sandbox log contains:
Adding the package's current resources directory to
PATHallows Codex to find the helpers:This confirms that the ARM64 package contains the correct helper executables, but the normal installed launcher does not expose or resolve its matching
codex-resourcesdirectory.The problem therefore appears to persist beyond 0.142.5 and is not x64-specific.
It would also be useful if
codex doctorchecked 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.exeby bare name, while launching through the active package'scurrent\binpath succeeds. That behavior is consistent with helper lookup being anchored to the visible standalonebinJunction 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:
Lookup from the visible
current_exe()path searches around the Junction's visible parent and misses the release's siblingcodex-resourcesdirectory. The candidate preserves the existing literal lookup first, then retries the same lookup fromdunce::canonicalize(exe). Canonicalization resolves the Junction to the real releasebin, allowing../codex-resourcesto find both matching helper binaries without changing the installer layout or relying onPATH.The regression test creates an actual directory Junction with
mklink /Jand verifies both sides of the behavior: literal lookup misses the helpers, while the canonicalized fallback finds both.Current-main validation on Windows:
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_timeoutandlegacy_workspace_write_delete_is_limited_to_writable_roots; both failed identically from unmodifiedmainin the same environment.This candidate is scoped to the standalone Junction layout. It does not claim to fix the distinct Desktop
app\resourcespackaging 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.