Windows standalone auto-upgrade installs a broken AppData CLI launcher without sandbox resources

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

• #37575
• #37049

Powered by Codex Action

Same class of pain here — auto-updates half-breaking the install on Windows. FWIW: the standalone auto-updater is usually the culprit; uninstall the AppData launcher and go back to the plain CLI install (or pin the version you know works) until this is sorted. I got burned by broken auto-updates on Hermes and OpenClaw so many times I built a portable USB rescue copy of my agent — runs off the stick, side by side with the broken install, no registry writes. It helped me, might help you: https://github.com/MilkyWay008/Hermes-OTG (built it myself).

Thanks. The suggested duplicate CLI issues do not match my setup:

• This is Codex Desktop App, not standalone Codex CLI.
• where.exe codex returns no result; Codex CLI is not installed.
• %LOCALAPPDATA%\Programs\OpenAI\Codex does not exist.
• The issue persists after reinstalling the Codex Desktop App.

The failure is reproducible in the Desktop App with any command (Get-Location) before PowerShell starts:
helper_unknown_error: setup refresh had errors.

Could this be the same helper-resource discovery issue in the Desktop App sandbox rather than the standalone CLI launcher?

Здесь та же проблема — автоматические обновления частично ломают установку на Windows. К слову: обычно проблема в автономном автообновлении. Удалите программу запуска из AppData и вернитесь к обычной установке через интерфейс командной строки (или закрепите версию, которая точно работает), пока проблема не будет решена. Я столько раз сталкивался с неработающими автоматическими обновлениями в Hermes и OpenClaw, что создал портативную USB-копию своего агента — она работает с флешки, параллельно с неработающей установкой, и не вносит изменений в реестр. Это помогло мне, возможно, поможет и вам: https://github.com/MilkyWay008/Hermes-OTG (я сам его собрал).

Confirming this on Windows x86_64, so the regression is not ARM64-specific.

Environment

• Windows 11 Pro 25H2, build 10.0.26200.9168, x64
• codex-cli 0.147.0
• Native Windows sandbox configured as:

``toml
[windows]
sandbox = "elevated"
``

• codex.exe resolves to:

``text
%LOCALAPPDATA%\Programs\OpenAI\Codex\bin\codex.exe
``

Same incomplete launcher layout

The public AppData bin directory contains only:

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

It contains neither codex-resources nor the sandbox helpers.

The matching versioned standalone release does contain both required files:

%USERPROFILE%\.codex\packages\standalone\releases\0.147.0-x86_64-pc-windows-msvc\codex-resources\codex-windows-sandbox-setup.exe
%USERPROFILE%\.codex\packages\standalone\releases\0.147.0-x86_64-pc-windows-msvc\codex-resources\codex-command-runner.exe

Its codex-path directory contains only rg.exe.

Running the standalone updater/reinstall reported success but left the public AppData launcher in the same incomplete state.

Repeated failure in the sandbox log

This repeats across repositories and sessions before PowerShell starts:

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

Using a resource-aware executable resolves the helper and succeeds:

setup refresh: spawning %USERPROFILE%\.codex\packages\standalone\current\codex-resources\codex-windows-sandbox-setup.exe
setup refresh: processed 2 write roots (read roots delegated); errors=[]
setup binary completed
helper copy: validating command-runner source=%USERPROFILE%\.codex\packages\standalone\current\codex-resources\codex-command-runner.exe

I also verified the complete desktop bundle can resolve both helpers from its versioned directory. Initializing through that executable restored sandbox operation for a resource-aware CLI invocation, while sessions that launch the public AppData codex.exe continue to fail by bare-name lookup.

codex doctor false-negative

codex doctor --json returns exit code 0 and:

{
  "overallStatus": "ok",
  "installation": {
    "status": "ok",
    "summary": "installation looks consistent"
  },
  "sandbox.helpers": {
    "status": "ok",
    "summary": "sandbox configuration is readable"
  }
}

It would be useful for the installation/doctor check to verify that the active public entrypoint can resolve both Windows sandbox helpers, ideally by running a minimal sandboxed command after install/update.

The failure chain is precise on main @ 1f41cc5d92. The sandbox helper is resolved relative to the running exe — next to it, or in codex-resources/ beside it, or <package>/codex-resources/ when the exe sits under bin/ (windows-sandbox-rs/src/helper_materialization.rs#L194-L212). When none match, find_setup_exe falls back to the bare filename (setup.rs#L846-L853), i.e. a PATH search — which is exactly your error=program not found. The updater's %LOCALAPPDATA%\...\bin\codex.exe layout (two exes, no codex-resources) satisfies none of the three candidates, while the untouched full layout sits under .codex\packages\standalone\releases\....

Fix layers:

1. Updater: either install the complete layout at the launcher location, or make the launcher a thin shim that executes the versioned release directory directly (single source of truth; also fixes future resource additions automatically).
2. Resilience in the resolver: add a fallback candidate at the standalone layout — $CODEX_HOME/packages/standalone/current/codex-resources/<helper> (the current link is already maintained; install-context knows the layout) — so a partially-copied launcher degrades gracefully instead of losing the entire sandbox.
3. Error: report the candidate paths searched instead of program not found — three concrete paths in the message would have made this instantly diagnosable.