Codex CLI 0.140.0 standalone Windows launcher cannot resolve sandbox helpers; sandbox fails with helper=codex-windows-sandbox-setup.exe program not found
What version of Codex CLI is running?
0.140
What subscription do you have?
Chatgpt Pro
Which model were you using?
gpt 5.5 xhigh
What platform is your computer?
Microsoft Windows NT 10.0.26200.0 x64
What terminal emulator and version are you using (if applicable)?
Windows Terminal
Codex doctor report
{
"schemaVersion": 1,
"generatedAt": "1781586359s since unix epoch",
"overallStatus": "warning",
"codexVersion": "0.140.0",
"checks": {
"app_server.status": {
"id": "app_server.status",
"category": "app-server",
"status": "ok",
"summary": "background server is not running",
"details": {
"control socket": "C:\\Users\\[REDACTED]\\.codex\\app-server-control\\app-server-control.sock",
"daemon state dir": "C:\\Users\\[REDACTED]\\.codex\\app-server-daemon",
"mode": "ephemeral",
"pid file": "C:\\Users\\[REDACTED]\\.codex\\app-server-daemon\\app-server.pid (missing)",
"settings": "C:\\Users\\[REDACTED]\\.codex\\app-server-daemon\\settings.json (missing)",
"status": "not running",
"update-loop pid file": "C:\\Users\\[REDACTED]\\.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\\[REDACTED]\\.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\\[REDACTED]\\.codex",
"config.toml": "C:\\Users\\[REDACTED]\\.codex\\config.toml",
"config.toml parse": "ok",
"cwd": "C:\\Users\\[REDACTED]",
"enabled feature flags": "<redacted>",
"feature flag overrides": "none",
"feature flags enabled": "29",
"log dir": "C:\\Users\\[REDACTED]\\.codex\\log",
"mcp servers": "1",
"model": "gpt-5.5",
"model provider": "openai",
"sqlite home": "C:\\Users\\[REDACTED]\\.codex"
},
"remediation": null,
"durationMs": 0
},
"git.environment": {
"id": "git.environment",
"category": "git",
"status": "ok",
"summary": "git version 2.54.0.windows.1",
"details": {
"PATH git #1": "C:\\Program Files\\Git\\cmd\\git.exe",
"PATH git entries": "1",
"git build options": "git version 2.54.0.windows.1; cpu: x86_64; built from commit: 2b8a3ab140826ac423c2845ef81d4c6ac4f7bf3c; sizeof-long: 4; sizeof-size_t: 8; shell-path: D:/git-sdk-64-build-installers/usr/bin/sh; rust: disabled; feature: fsmonitor--daemon; gettext: enabled; libcurl: 8.19.0; OpenSSL: OpenSSL 3.5.6 7 Apr 2026; zlib: 1.3.2; SHA-1: SHA1_DC; SHA-256: SHA256_BLK; default-ref-format: files; default-hash: sha1",
"git exec path": "C:/Program Files/Git/mingw64/libexec/git-core",
"git version": "git version 2.54.0.windows.1",
"repo detected": "false",
"selected git": "C:\\Program Files\\Git\\cmd\\git.exe"
},
"remediation": null,
"durationMs": 177
},
"installation": {
"id": "installation",
"category": "install",
"status": "ok",
"summary": "installation looks consistent",
"details": {
"PATH codex #1": "C:\\Users\\[REDACTED]\\AppData\\Local\\Programs\\OpenAI\\Codex\\bin\\codex.exe",
"current executable": "C:\\Users\\[REDACTED]\\AppData\\Local\\Programs\\OpenAI\\Codex\\bin\\codex.exe",
"install context": "standalone (windows, package C:\\Users\\[REDACTED]\\.codex\\packages\\standalone\\releases\\0.140.0-x86_64-pc-windows-msvc, bin C:\\Users\\[REDACTED]\\.codex\\packages\\standalone\\releases\\0.140.0-x86_64-pc-windows-msvc\\bin, resources C:\\Users\\[REDACTED]\\.codex\\packages\\standalone\\releases\\0.140.0-x86_64-pc-windows-msvc\\codex-resources, path C:\\Users\\[REDACTED]\\.codex\\packages\\standalone\\releases\\0.140.0-x86_64-pc-windows-msvc\\codex-path)",
"managed by bun": "false",
"managed by npm": "false",
"managed package root": "not set"
},
"remediation": null,
"durationMs": 102
},
"mcp.config": {
"id": "mcp.config",
"category": "mcp",
"status": "ok",
"summary": "MCP configuration is locally consistent",
"details": {
"configured servers": "1",
"disabled servers": "0",
"streamable_http servers": "1"
},
"remediation": null,
"durationMs": 1444
},
"network.env": {
"id": "network.env",
"category": "network",
"status": "ok",
"summary": "network-related environment looks readable",
"details": {
},
"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": 1106
},
"network.websocket_reachability": {
"id": "network.websocket_reachability",
"category": "websocket",
"status": "ok",
"summary": "Responses WebSocket handshake succeeded",
"details": {
"DNS": "1 IPv4, 0 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",
"reasoning header": "false",
"server model present": "false",
"supports websockets": "true",
"wire API": "responses"
},
"remediation": null,
"durationMs": 1480
},
"runtime.provenance": {
"id": "runtime.provenance",
"category": "runtime",
"status": "ok",
"summary": "running standalone on windows-x86_64",
"details": {
"commit": "unknown",
"current executable": "C:\\Users\\[REDACTED]\\AppData\\Local\\Programs\\OpenAI\\Codex\\bin\\codex.exe",
"install method": "standalone (windows, package C:\\Users\\[REDACTED]\\.codex\\packages\\standalone\\releases\\0.140.0-x86_64-pc-windows-msvc, bin C:\\Users\\[REDACTED]\\.codex\\packages\\standalone\\releases\\0.140.0-x86_64-pc-windows-msvc\\bin, resources C:\\Users\\[REDACTED]\\.codex\\packages\\standalone\\releases\\0.140.0-x86_64-pc-windows-msvc\\codex-resources, path C:\\Users\\[REDACTED]\\.codex\\packages\\standalone\\releases\\0.140.0-x86_64-pc-windows-msvc\\codex-path)",
"platform": "windows-x86_64",
"version": "0.140.0"
},
"remediation": null,
"durationMs": 0
},
"runtime.search": {
"id": "runtime.search",
"category": "search",
"status": "ok",
"summary": "search is OK (bundled)",
"details": {
"search command": "C:\\Users\\[REDACTED]\\.codex\\packages\\standalone\\releases\\0.140.0-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": "enabled"
},
"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\\[REDACTED]\\.codex (dir)",
"active rollout files": "120 files, 133079169 total bytes, 1108993 average bytes",
"archived rollout files": "0 files, 0 total bytes, 0 average bytes",
"goals DB": "C:\\Users\\[REDACTED]\\.codex\\goals_1.sqlite (file)",
"goals DB integrity": "ok",
"log DB": "C:\\Users\\[REDACTED]\\.codex\\logs_2.sqlite (file)",
"log DB integrity": "ok",
"log dir": "C:\\Users\\[REDACTED]\\.codex\\log (dir)",
"memories DB": "C:\\Users\\[REDACTED]\\.codex\\memories_1.sqlite (file)",
"memories DB integrity": "ok",
"sqlite home": "C:\\Users\\[REDACTED]\\.codex (dir)",
"standalone release cache": "1 entries in C:\\Users\\[REDACTED]\\.codex\\packages\\standalone\\releases",
"state DB": "C:\\Users\\[REDACTED]\\.codex\\state_5.sqlite (file)",
"state DB integrity": "ok"
},
"remediation": null,
"durationMs": 266
},
"state.rollout_db_parity": {
"id": "state.rollout_db_parity",
"category": "threads",
"status": "warning",
"summary": "rollout files and state DB thread inventory differ",
"details": {
"default model provider": "openai",
"rollout DB active files": "111",
"rollout DB active rows": "111",
"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": "openai=111",
"rollout DB rows": "111",
"rollout DB scan cap reached": "false",
"rollout DB scan error sample": [
"C:\\Users\\[REDACTED]\\.codex\\sessions\\2025\\09\\15\\rollout-2025-09-15T08-10-13-e46890fc-7393-47a4-8fd6-3bef2904f0c2.jsonl (no parseable rollout items)",
"C:\\Users\\[REDACTED]\\.codex\\sessions\\2025\\09\\12\\rollout-2025-09-12T20-23-02-2901f9b7-f4fc-4782-a0e9-afb7a76fafdc.jsonl (no parseable rollout items)",
"C:\\Users\\[REDACTED]\\.codex\\sessions\\2025\\09\\11\\rollout-2025-09-11T00-09-12-06565b38-6329-4819-b31a-b5c7c8638caa.jsonl (no parseable rollout items)",
"C:\\Users\\[REDACTED]\\.codex\\sessions\\2025\\09\\11\\rollout-2025-09-11T00-30-41-25d5df5c-ccce-4b92-bd40-3d56792b3b1e.jsonl (no parseable rollout items)",
"C:\\Users\\[REDACTED]\\.codex\\sessions\\2025\\09\\03\\rollout-2025-09-03T21-18-44-48b4a5a0-a5ee-4652-93a6-9a6c1a064268.jsonl (no parseable rollout items)"
],
"rollout DB scan errors": "9",
"rollout DB sources": "cli=98, vscode=13",
"rollout DB stale rows": "0"
},
"issues": [
{
"severity": "warning",
"cause": "rollout scan was incomplete or found bad files",
"measured": "9 scan errors, 0 malformed names, scan cap reached: false",
"expected": "rollout directories are fully scannable",
"remedy": "Check file permissions and unexpected files under CODEX_HOME sessions.",
"fields": []
}
],
"remediation": null,
"durationMs": 1227
},
"system.environment": {
"id": "system.environment",
"category": "system",
"status": "ok",
"summary": "OS language zh-CN",
"details": {
"EDITOR": "not set",
"VISUAL": "not set",
"os": "Windows 10.0.26200 (Windows 11 Professional) [64-bit]",
"os language": "zh-CN",
"os type": "Windows",
"os version": "10.0.26200"
},
"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": "65001",
"console output code page": "65001",
"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": 0
},
"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": "[REDACTED]",
"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.140.0",
"check for update on startup": "true",
"dismissed version": "0.139.0",
"last checked at": "2026-06-16T03:16:38.374327500Z",
"latest version": "0.140.0",
"latest version status": "current version is not older",
"update action": "standalone installer",
"version cache": "C:\\Users\\[REDACTED]\\.codex\\version.json"
},
"remediation": null,
"durationMs": 1630
}
}
}
What issue are you seeing?
On Codex CLI 0.140.0 for Windows x86_64 installed via the standalone PowerShell installer, launching Codex through the normal codex command causes the Windows sandbox helper setup path to fail.
The active command resolves to:
C:\Users\<USER>\AppData\Local\Programs\OpenAI\Codex\bin\codex.exe
However, codex doctor --summary --ascii reports the actual standalone runtime package and resources under:
C:\Users\<USER>\.codex\packages\standalone\releases\0.140.0-x86_64-pc-windows-msvc
C:\Users\<USER>\.codex\packages\standalone\releases\0.140.0-x86_64-pc-windows-msvc\codex-resources
The sandbox setup helper exists at:
C:\Users\<USER>\.codex\packages\standalone\current\codex-resources\codex-windows-sandbox-setup.exe
But when using the normal codex entrypoint, the sandbox tries to launch only the bare helper name:
codex-windows-sandbox-setup.exe
and fails with:
windows sandbox failed: orchestrator_helper_launch_failed: setup refresh failed to launch helper: helper=codex-windows-sandbox-setup.exe, cwd=C:\Users\<USER>, log=C:\Users\<USER>\.codex\.sandbox\sandbox.<DATE>.log, error=program not found
The same issue appears inside the TUI when Codex tries to run read-only PowerShell commands:
execution error: Io(Custom { kind: Other, error: "windows sandbox: orchestrator_helper_launch_failed: setup refresh failed to launch helper: helper=codex-windows-sandbox-setup.exe, cwd=<PROJECT_DIR>, log=C:\\Users\\<USER>\\.codex\\.sandbox\\sandbox.<DATE>.log, error=program not found" })
What steps can reproduce the bug?
Environment:
- Windows 11 x86_64
- PowerShell 7.x
- Codex CLI 0.140.0
- Standalone installation via:
powershell -ExecutionPolicy Bypass -c "irm https://chatgpt.com/codex/install.ps1 | iex"
Reproduction commands:
- Confirm version and entrypoint:
codex --version
where.exe codex
Get-Command codex | Format-List Source,Path,CommandType,Version
Observed:
codex-cli 0.140.0
C:\Users\<USER>\AppData\Local\Programs\OpenAI\Codex\bin\codex.exe
- Confirm doctor sees the standalone package/resources:
codex doctor --summary --ascii
Observed relevant output:
runtime standalone (windows, package C:\Users\<USER>\.codex\packages\standalone\releases\0.140.0-x86_64-pc-windows-msvc, bin C:\Users\<USER>\.codex\packages\standalone\releases\0.140.0-x86_64-pc-windows-msvc\bin, resources C:\Users\<USER>\.codex\packages\standalone\releases\0.140.0-x86_64-pc-windows-msvc\codex-resources, path C:\Users\<USER>\.codex\packages\standalone\releases\0.140.0-x86_64-pc-windows-msvc\codex-path)
install consistent
- Confirm the helper exists in the standalone resource directory:
$resources = "$env:USERPROFILE\.codex\packages\standalone\current\codex-resources"
Test-Path "$resources\codex-windows-sandbox-setup.exe"
Observed:
True
- Run the elevated sandbox smoke test through the normal
codexentrypoint:
$cmd = "$env:WINDIR\System32\cmd.exe"
codex -c 'windows.sandbox="elevated"' sandbox windows -- $cmd /c echo CODEX_ELEVATED_OK
Observed:
windows sandbox failed: orchestrator_helper_launch_failed: setup refresh failed to launch helper: helper=codex-windows-sandbox-setup.exe, cwd=C:\Users\<USER>, log=C:\Users\<USER>\.codex\.sandbox\sandbox.<DATE>.log, error=program not found
Thread id: N/A. This is a local CLI/sandbox reproduction.
What is the expected behavior?
The normal codex entrypoint should resolve the bundled Windows sandbox helper executables from the active standalone package resource directory.
Expected behavior:
codex-windows-sandbox-setup.exeshould be located under the active standalone package'scodex-resourcesdirectory.- The sandbox should not fall back to launching a bare
codex-windows-sandbox-setup.exename when the helper exists in the package resources. - Running the elevated sandbox smoke test should either succeed or fail with a different actionable sandbox error, not
helper=codex-windows-sandbox-setup.exe ... error=program not found.
Expected command result:
codex -c 'windows.sandbox="elevated"' sandbox windows -- "$env:WINDIR\System32\cmd.exe" /c echo CODEX_ELEVATED_OK
Expected output:
CODEX_ELEVATED_OK
Additional information
This appears to be specific to the normal standalone launcher entrypoint.
Normal launcher:
C:\Users\<USER>\AppData\Local\Programs\OpenAI\Codex\bin\codex.exe
Actual standalone package binary:
C:\Users\<USER>\.codex\packages\standalone\current\bin\codex.exe
Launching the real package binary directly works better in the TUI:
$pkg = "$env:USERPROFILE\.codex\packages\standalone\current"
& "$pkg\bin\codex.exe"
This suggests the sandbox helper lookup may be anchored to the visible launcher path rather than the actual standalone package path that codex doctor reports.
Additional diagnostic:
If I temporarily prepend the package resource directory to PATH:
$resources = "$env:USERPROFILE\.codex\packages\standalone\current\codex-resources"
$env:PATH = "$resources;$env:PATH"
then codex-windows-sandbox-setup.exe becomes discoverable and the setup helper runs. The sandbox then progresses further but later reports another helper-resolution/runner 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
followed by:
CreateProcessWithLogonW failed: 2
This looks like the same resource-resolution issue may also affect codex-command-runner.exe.
A clean reinstall of the standalone package did not resolve the normal codex launcher behavior. The install still reports as consistent in codex doctor.
9 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I added a focused analysis and candidate fix in #30732:
https://github.com/openai/codex/issues/30732#issuecomment-4895013534
Candidate fix branch:
https://github.com/starriet9/codex/tree/fix/windows-sandbox-helper-junction
The issue I reproduced is the standalone Windows CLI junction layout described here:
%LOCALAPPDATA%\Programs\OpenAI\Codex\binis a junction to the active standalone releasebincodex-resourcescurrent_exe()path misses that realcodex-resourcesdirectoryThe candidate fix keeps the existing literal lookup first, then falls back to lookup from
dunce::canonicalize(exe). That resolves through the junction to the real releasebin, so the existing../codex-resourceslookup finds both helper binaries.The helper-source lookup tests pass locally.
I am not opening a PR yet because
docs/contributing.mdsays external PRs are by invitation only, but the branch is ready if maintainers want a focused PR.Validation update: the proposed fix itself is unchanged, but I have now tested the actual
run_setup_refresh()path rather than only the helper path resolver.Using otherwise identical isolated standalone-style double-junction layouts:
mainfailed withcodex-windows-sandbox-setup.exe ... program not foundIn both runs,
current_exe()returned the visible junction path, helper locations were excluded fromPATH, and the helpers existed only under the real releasecodex-resourcesdirectory.The branch has also been rebased onto the current
main, so the older commit hash previously quoted in #30732 has been superseded.Current branch:
https://github.com/starriet9/codex/tree/fix/windows-sandbox-helper-junction
Current commit:
https://github.com/starriet9/codex/commit/d62bccdee344243b7d708ed3a3982483a0b80d53
After the rebase, the five targeted helper lookup tests still pass. I have not opened a PR because external PRs require a maintainer invitation.
I can reproduce a closely related launcher/resource-resolution failure on Windows 11 ARM64 with Codex CLI 0.145.0 installed using the standalone installer.
Environment:
[windows] sandbox = "elevated"The normal
codexentry point and the actual standalone package binary behave differently when running the same sandbox command.Observed behavior:
codexentry point fails before the requested command executes:CodexSandboxOffline.The sandbox log also shows a helper-resolution difference:
codex-windows-sandbox-setup.exeusing only the bare filename and fails with access denied.codex-resourcesdirectory and succeeds.This looks related to the helper/resource lookup described in this issue, although the observed failure is
Access is denied (os error 5)rather thanprogram not found.The successful
CodexSandboxOfflineresult confirms that the standalone path can launch the setup helper and switch to the restricted sandbox identity. It is not intended as a claim about complete filesystem isolation.I can provide redacted sandbox logs,
codex doctoroutput, the exact launcher paths, executable signatures and hashes, and the complete probe script if useful.I encountered a closely related split-installation state and built a small read-only diagnostic for this class of Windows issue:
https://github.com/Ann-Diana/codex-safety-canary
It checks whether the PATH-resolved codex.exe has the required helper files, searches known local Codex installation roots for complete bundles, and reports the active CLI separately from any alternative bundle selected for disposable testing.
It is a diagnostic only – it does not copy helpers, modify PATH, or repair the installation.
Update: Alpha 11 has now been released. It separates package/resource discovery, helper resolution, runtime/setup failures and actual sandbox-boundary evidence. The independent 0.146.0 reproduction matches this staged behavior.
I can reproduce this on the current standalone Windows CLI release,
codex-cli 0.146.0, on Windows 11 x64 (build 26200).Environment:
0.146.0D:\...codex exec:workspace-writecodex doctor --json: installation/runtime checks reportokReproduction:
Initial failure:
The helpers do exist in the active standalone release:
But
codex-pathcontains only:Temporary PATH workaround in the current PowerShell session:
After this, the original
program not founderror disappears, confirming helper lookup is involved. However, execution still fails at the next stage with:The requested Git command is not executed.
So on
0.146.0:codex-resourcesis manually added to PATH;ERROR_FILE_NOT_FOUND).This appears to confirm that the launcher/helper resolution bug remains present in 0.146.0, while also exposing a second downstream path/process-resolution failure once the helper is manually made discoverable.
Independent confirmation on Codex CLI
0.146.0(Windows 11 x64): in this environment the package is complete, and the failure is consistent with the visiblebinJunction/resource-resolution mismatch described in #30829.Environment
10.0.262007.6.40.146.0[windows] sandbox = "elevated"codex doctor --json:overallStatus: ok; installation and runtime provenance report the active standalone package and resources correctlyObserved layout
The PATH-resolved entrypoint is:
The visible
binis a directory Junction:The active
currentJunction targets the0.146.0-x86_64-pc-windows-msvcrelease. Itscodex-package.jsondeclares:Both Windows helpers exist in the matching active package:
The visible and package
codex.exefiles have identical length, timestamp, and SHA-256. This does not appear to be a partial or version-mismatched package.Runtime mismatch
The process PATH contains the active
codex-pathdirectory and the visiblebin, but notcodex-resources. Before any workaround, neither helper resolves by bare name:Routine sandboxed tool calls can initially succeed, but a later setup refresh fails before the requested command starts:
The sandbox log records a bare-name spawn attempt:
Candidate evaluation from the visible entrypoint cannot find the helper beside
bin, belowbin\codex-resources, or below the visible parent. The same evaluation from the package entrypoint finds it at..\codex-resources\codex-windows-sandbox-setup.exe.Process-local PATH probe
Without changing the user or machine PATH, I prepended the active package resources in a child PowerShell process:
After that, both bare names resolved to the matching active package:
This verifies the name-resolution part only. I did not run an end-to-end elevated sandbox smoke test after changing PATH because that can trigger UAC and machine-level sandbox setup.
This is an independent x64 reproduction that the Junction/resource lookup problem remains present in
0.146.0, even thoughcodex doctorreports the installation as consistent and knows the correct resources directory.I also had few problems when I requested to write AGENTS.md with Codex CLI
Environment
| Item | Value |
|---|---|
| OS | Windows 11 Pro, build
10.0.26200|| Shell | PowerShell 7.6 |
| Codex CLI |
codex-cli 0.146.0|| Installation type | Standalone Windows installer |
| Sandbox mode |
elevated|| Approval policy |
OnRequest|CLI launcher and runtime layout
The normal
codexcommand resolves to:However,
codex doctorreports the actual standalone runtime and resources under:The required helper is present:
codex doctorreports that the installation is consistent, current, authenticated, and otherwise healthy.Actual behavior
Any sandboxed tool call can fail before the requested command begins, including simple read-only commands and file edits.
The same failure affected:
AGENTS.md.This is therefore not specific to
apply_patch, a repository, or a particular project directory.Expected behavior
The normal standalone CLI launcher should resolve the sandbox helper from the active standalone package resource directory, for example:
It should not attempt to launch only the bare filename:
when the helper is already installed and available in the active package resources.
Additional observations
I initially encountered a separate sandbox ACL issue caused by overly broad trusted workspace roots. After reducing the ACL/trust-root scope, the helper lookup failure still remained independently.
Temporarily adding the standalone
codex-resourcesdirectory toPATHallowed the setup process to progress beyond the initial “program not found” failure in at least one session. This strongly suggests that the problem is helper discovery by the normal launcher, not a missing helper binary or a corrupted installation.The failure is especially confusing because:
codex doctorreports a healthy, current installation.This appears to match the standalone launcher/resource-resolution problem described in this issue.
Still present in 0.147.0 standalone. For recent versions the root cause appears to be a
packaging change: 0.145.0 shipped the sandbox helpers in both bin\ and codex-resources\,
0.147.0 ships them only in codex-resources\, while the launcher still resolves the bare
filename via exe dir / PATH. Packaging diff, a verified copy-into-bin workaround, and two
side effects (doctor stays green, exec answers by guessing instead of failing) in
openai/codex#30829 (comment link).