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

What version of Codex CLI is running?

codex-cli 0.147.0

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 ARM64

What issue are you seeing?

After the Windows standalone auto-upgrade from 0.146.0 to 0.147.0, codex resolved first to:

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

The updater copied the new codex.exe and codex-code-mode-host.exe there, but did not install the required codex-resources directory beside that executable. As a result, every sandboxed command failed before PowerShell launched:

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

The complete versioned release was present under:

%USERPROFILE%\.codex\packages\standalone\releases\0.147.0-aarch64-pc-windows-msvc

and contained:

codex-resources\codex-windows-sandbox-setup.exe
codex-resources\codex-command-runner.exe

The codex.exe in the AppData launcher directory and the versioned release had identical SHA-256 hashes. The difference was solely their resource-relative installation layout.

This leaves a launcher that passes codex --version but cannot execute any sandboxed tool, making the upgrade appear successful while the CLI is functionally broken.

What steps can reproduce the bug?

1. Install the standalone Codex CLI on Windows ARM64.
2. Allow it to auto-upgrade from 0.146.0 to 0.147.0.
3. Confirm both paths exist:
   • %LOCALAPPDATA%\Programs\OpenAI\Codex\bin\codex.exe
   • %USERPROFILE%\.codex\packages\standalone\releases\0.147.0-aarch64-pc-windows-msvc\bin\codex.exe
4. Put the AppData bin directory first on PATH, or invoke that executable directly.
5. Start Codex with the native Windows sandbox.
6. Ask it to run a trivial shell command such as Get-Location.

What is the expected behavior?

The auto-upgrade should leave the public codex entrypoint able to locate the matching version's sandbox setup and command-runner helpers.

The updater could achieve this by installing a resource-aware launcher/shim, preserving the versioned executable location, or installing the matching codex-resources beside the AppData executable.

It should also validate a sandboxed command after upgrade, not only codex --version.

Workaround verified

A small %USERPROFILE%\.local\bin\codex.cmd launcher that selects the newest versioned release and executes its bin\codex.exe fixes the problem.

After restoring that wrapper and restarting Codex:

• sandbox setup launched from the versioned codex-resources directory;
• writes inside the workspace succeeded;
• writes outside the workspace were denied;
• package formatting, lint, typecheck, and 198 tests passed.

Additional information

The sandbox log clearly distinguishes the broken and working launch paths.

Broken AppData launcher:

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

Working versioned launcher:

setup refresh: spawning %USERPROFILE%\.codex\packages\standalone\releases\0.147.0-aarch64-pc-windows-msvc\codex-resources\codex-windows-sandbox-setup.exe
setup refresh: processed 2 write roots (read roots delegated); errors=[]
setup binary completed

Related: #37049, #32655, #37575. This report focuses specifically on the auto-upgrade completing while leaving the public AppData launcher structurally incomplete.

Start by reproducing the Windows standalone auto-upgrade and compare the AppData bin launcher with the versioned release under .codex\packages\standalone\releases. Trace how the updater handles codex-resources and the sandbox helpers, then verify that a sandboxed Get-Location command works from the public codex entrypoint after upgrading.