[Windows][MSIX 26.820.7780.0] App cannot start after auto-update: bundled codex.exe relocation fails with ERROR_ENCRYPTION_FAILED (Unable to locate the Codex CLI binary)

Version

OpenAI.Codex 26.820.7780.0 (Microsoft Store / MSIX, installed via winget id 9PLM9XGG6VKS). Previous 26.818.8289.0 worked normally.

Subscription

ChatGPT Plus

Platform

• Windows 11 Home, build 10.0.26200, x64
• MSIX package: OpenAI.Codex_26.820.7780.0_x64__2p2nqsd0c76g0
• Windows-native mode (no WSL; runCodexInWindowsSubsystemForLinux not set)

What issue are you seeing?

After auto-updating from 26.818.8289.0 to 26.820.7780.0, the app can no longer start. A dialog shows:

ChatGPT failed to start.
Unable to locate the Codex CLI binary. Set CODEX_CLI_PATH or ensure the Electron resources include bin/codex.

The bundled binary is NOT missing — app\resources\codex.exe (307,568,432 bytes) exists and is readable. The real failure happens earlier during the bundled-executable relocation step (copy from WindowsApps into the per-user runtime dir).

Startup log (...\LocalCache\Local\Codex\Logs\...\codex-desktop-*.log):

bundled_executable_relocation_failed
executableName=codex.exe
operation=copy_file
sourceKind=windowsapps
sourcePath=...\WindowsApps\OpenAI.Codex_26.820.7780.0_x64__2p2nqsd0c76g0\app\resources\codex.exe
destinationPath=C:\Users\<user>\AppData\Local\OpenAI\Codex\bin\.staging-...\codex.exe
originalError: errno=-4094, code=UNKNOWN, syscall=copyfile

followed by app_server_connection.transport_connect_failed → Unable to locate the Codex CLI binary → Desktop bootstrap failed to start the main app phase=bootstrap-import-main.

The same startup also fails to relocate the bundled cua_node runtime (copy_directory, node.exe / node_repl.exe / corepack). %LOCALAPPDATA%\OpenAI\Codex\bin ends up with only the old rg.exe; codex.exe never appears.

Steps to reproduce

1. Install/auto-update to OpenAI.Codex 26.820.7780.0 via Microsoft Store.
2. Launch the app (Windows-native mode, CODEX_CLI_PATH unset).
3. Observe the fatal "Unable to locate the Codex CLI binary" dialog.

Independent reproduction of the copy failure

The packaged executables carry the EFS Encrypted / "Application Protected" attribute:

cipher /c <pkg>\app\resources\codex.exe
E codex.exe
  Compatibility Level:
    Application Protected

A plain copy of the packaged file to a normal user directory fails:

Copy-Item -LiteralPath "$($pkg.InstallLocation)\app\resources\codex.exe" `
  -Destination "$env:TEMP\codex-copytest.exe" -Force
# The specified file could not be encrypted.  (= ERROR_ENCRYPTION_FAILED, HRESULT 0x80071770)

Reading the file via a byte-stream (File.OpenRead) and writing with File.Create succeeds and produces an ordinary unencrypted file — the data is fine; only the copy path breaks on the EFS/Application Protected source.

What I have tried (and results)

• Fully killed all stale ChatGPT.exe processes. No change.
• Remove-AppxPackage + fresh reinstall from msstore (winget). No change — reinstalled package files are still Encrypted/Application Protected; log is byte-for-byte identical.
• Disk space fine, only Windows Defender, no EFS policy / FIPS enabled.
• On this machine creating a NEW encrypted file also fails (cipher /e → "The request is not supported"), but this bug reproduces on machines where EFS works normally too, so the primary defect appears to be the app's relocation copy mechanism, not the machine.

Expected behavior

• The app should start using its bundled CLI.
• When relocating EFS/Application Protected package resources to an unencrypted user directory, the copy should succeed (e.g. a COPY_FILE_ALLOW_DECRYPTED_DESTINATION-equivalent path, or fallback to a buffered read/write stream), and it should surface the underlying Win32 error instead of reporting the CLI as missing.
• cua_node runtime should be relocated the same way.

Additional context

• Regression introduced by 26.820.7780.0; 26.818.8289.0 works.
• Related issues: #40700, #40752, #38696, #34764, #32732, #25571, #25220.
• The empty/partial per-user runtime cache under %LOCALAPPDATA%\OpenAI\Codex is a symptom; the fix belongs in the relocation implementation.

Start by tracing the bundled-executable relocation path that emits bundled_executable_relocation_failed during bootstrap, then inspect the copy handling for codex.exe and the cua_node directory. Reproduce with the MSIX package and an Application Protected file, and verify that the bundled CLI and cua_node reach the per-user runtime directory without the misleading missing-binary error.