[Windows][Desktop 26.901.6511.0] Startup fails with spawn EPERM when spawning relocated LocalAppData codex.exe; in-package resources\codex.exe works

What version of the Codex App are you using (From “About Codex” dialog)?

Codex / ChatGPT Desktop: 26.901.6511.0 (Microsoft Store / MSIX, x64)

Also reproduced on this machine with no workaround on:

• 26.901.4073.0
• 26.901.5280.0

Relocated / bundled CLI: codex-cli 0.153.4

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Windows x64, Microsoft Store / MSIX

What issue are you seeing?

Cold start shows this dialog:

ChatGPT failed to start.
spawn EPERM

Buttons: Check for Updates | Quit

Desktop logs show the Electron shell starts, then child_process.spawn of the local app-server fails before stdio_transport_spawned:

[AppServerConnection] Starting app-server connection hostId=local transport=stdio
[AppServerConnection] app_server_connection.transport_connect_failed errorCode=EPERM errorMessage="spawn EPERM"
[AppServerConnection] fatal_error_broadcasted errorMessage="spawn EPERM" transportKind=stdio
Desktop bootstrap failed to start the main app phase=bootstrap-import-main

Stack (packaged asar):

Error: spawn EPERM
    at ChildProcess.spawn (node:internal/child_process:458:11)
    at spawn (node:child_process:827:9)
    at lU.spawnProcess (...\app.asar\.vite\build\src-VqXTPopo.js:704:17410)
    at new lU (...)
    at uU.connect (...)
    at async EJ.connectAndWaitForOpen (...)
    at async EJ.startAppServerProcess (...)

This is not “CLI missing”. Desktop successfully relocates codex.exe into:

%LOCALAPPDATA%\OpenAI\Codex\bin\<hash>\codex.exe

That relocated file exists, is Archive only (not Encrypted), Authenticode-valid, and runs from an unpackaged PowerShell/Node process as codex-cli 0.153.4. The packaged Desktop process still cannot spawn it.

runCodexInWindowsSubsystemForLinux was not set. The failing spawn never reaches stdio_transport_spawned, so this is not the WSL wsl.exe spawn path.

Control tests

1. Unpackaged spawn of the relocated CLI works

& "$env:LOCALAPPDATA\OpenAI\Codex\bin\<hash>\codex.exe" --version
# codex-cli 0.153.4

2. Restoring ALL APPLICATION PACKAGES (S-1-15-2-1 / S-1-15-2-2) on %USERPROFILE%\AppData and %LOCALAPPDATA%\OpenAI, and switching [windows] sandbox from elevated to unelevated, did not change the failure. Desktop still logged spawn EPERM against the relocated CLI.

3. Setting user CODEX_CLI_PATH to the in-package sibling binary makes Desktop start immediately:

CODEX_CLI_PATH=%ProgramFiles%\WindowsApps\OpenAI.Codex_26.901.6511.0_x64__2p2nqsd0c76g0\app\resources\codex.exe

Successful log:

[StdioConnection] stdio_transport_spawned
  executablePath="...\WindowsApps\OpenAI.Codex_26.901.6511.0_x64__2p2nqsd0c76g0\app\resources\codex.exe"
  spawnCommand="...\WindowsApps\OpenAI.Codex_26.901.6511.0_x64__2p2nqsd0c76g0\app\resources\codex.exe"
[AppServerConnection] Transport start success transport=stdio
[AppServerConnection] initialize_handshake_result outcome=success
window ready-to-show

Direct PowerShell execution of that same WindowsApps path still returns Access denied, as expected for an unpackaged caller. The packaged ChatGPT.exe can spawn it because it is in the same MSIX package.

4. AppLocker EXE/DLL log has no Event 8004 around these launches. This is not the spawn UNKNOWN / AppLocker case in #41958.

5. Store updates do not fix it. The package version in the log path changes (4073.0 → 5280.0 → 6511.0); the failure string does not.

What steps can reproduce the bug?

1. Install/update Microsoft Store package OpenAI.Codex to 26.901.6511.0 (also seen on 26.901.4073.0 and 26.901.5280.0).
2. Ensure CODEX_CLI_PATH is unset.
3. Launch ChatGPT from the Start menu / AppX activation.
4. Observe the dialog ChatGPT failed to start. / spawn EPERM, and logs Desktop bootstrap failed ... phase=bootstrap-import-main.
5. Confirm %LOCALAPPDATA%\OpenAI\Codex\bin\<hash>\codex.exe exists and runs from PowerShell.
6. Set CODEX_CLI_PATH to app\resources\codex.exe inside the current WindowsApps\OpenAI.Codex_* package and relaunch.
7. Desktop starts; logs show stdio_transport_spawned with the in-package path.

What is the expected behavior?

Desktop should spawn the relocated per-user CLI, or fall back to the in-package app\resources\codex.exe, and start.

If CreateProcess of the relocated copy is denied, the app should fall back to the packaged sibling executable instead of failing bootstrap with spawn EPERM. It should also log the resolved executablePath / spawnCommand on the failed spawn, not only after a successful spawn.

CODEX_CLI_PATH pointing at a versioned WindowsApps\OpenAI.Codex_<version>_... path is not durable; the next Store update changes the folder name.

Additional information

• MSIX is FullTrust (runFullTrust, Windows.FullTrustApplication).
• Manifest excludes $(KnownFolder:LocalAppData)\OpenAI from FS virtualization, so the relocated CLI is the real %LOCALAPPDATA%\OpenAI\... path.
• spawnProcess resolves spawnCommand ?? executablePath and calls Node child_process.spawn. Full paths containing \ are not rewritten via PATH. The relocated hash directory is created during failed launches, so relocation succeeds; only the subsequent spawn fails.
• Related but not the same:
  • #40700 / #40843 / #42645 — relocation / “Unable to locate the Codex CLI binary” / Access denied on the WindowsApps file from PowerShell
  • #41958 — spawn UNKNOWN + AppLocker Event 8004
  • #35872 — spawn EPERM on a packaged WindowsApps\...\codex.exe from an unpackaged Node worker
  • #15777 — elevated sandbox ACL rewrite on AppData (family, but restoring S-1-15-2-1 did not unblock this Desktop spawn)
  • #42711 — same 26.901.4073.0 train, but 0xC0000005, not spawn EPERM

Please avoid requesting a destructive reinstall/reset unless necessary; the A/B above already isolates the failing CreateProcess target.

Start at the app-server stdio connection and the spawnProcess entry point shown in the packaged asar stack, then trace how the relocated and in-package codex.exe paths are selected. Reproduce with the listed MSIX versions and CODEX_CLI_PATH control, and consider the issue complete when the relocated CLI starts or the packaged sibling is used as a fallback, with the failed executable path logged.