[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)

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

• #40791
• #40700
• #40762

Powered by Codex Action

Saw the bundled_executable_relocation_failed with the 0x80071770 (ERROR_ENCRYPTION_FAILED) in your log, that's the MSIX codex.exe carrying the EFS "Application Protected" attribute, a plain CopyFile can't copy it to an unencrypted dir. Byte-stream copy works where CopyFile doesn't, so as a workaround you can extract codex.exe that way and point CODEX_CLI_PATH at the copy, it bypasses the relocation step entirely. oh btw, in case it might help that, I built a portable Hermes OTG repo, check it, imo it may be able to help you diagnose and figure out the fix in no time. https://github.com/MilkyWay008/Hermes-OTG

Confirmed + two missing pieces: the real Win32 error code behind UNKNOWN -4094, and why cipher /d is a dead end on Home edition

Hit the same failure chain on Win11 Home (package 26.820.7780.0, moved to D:\WindowsApps by a third-party app-relocation tool, Get-AppxDefaultVolume → PackageStorePath: D:\WindowsApps). Adding the concrete error codes and a clean fix path in case it helps the team and other users.

1. UNKNOWN -4094 is Win32 6000 ERROR_ENCRYPTION_FAILED

Node doesn't map this error code, which is what made this so hard to pin down. One P/Invoke strips the mystery:

Add-Type -TypeDefinition 'using System.Runtime.InteropServices;
public static class W { [DllImport("kernel32.dll", CharSet=CharSet.Unicode, SetLastError=true)]
public static extern bool CopyFileW(string s, string d, bool f); }'
[W]::CopyFileW('D:\WindowsApps\OpenAI.Codex_...\AppxManifest.xml', "$env:TEMP\t.xml", $false)
[Runtime.InteropServices.Marshal]::GetLastWin32Error()   # → 6000

The package directory itself is Directory, Archive, Encrypted; reading and byte-stream copying work (the owner can transparently decrypt), but CopyFile preserves the encryption attribute onto the destination — and creating an encrypted file fails on Home.

2. Decryption is impossible on Home — reinstall is the only path

• cipher /e on a fresh file → "the request is not supported" (EFS not available on Home)
• cipher /d /s:<pkg> (elevated) → "the specified file could not be decrypted" / "access denied" on every entry, attributes unchanged

So no in-place repair exists on Home editions. The working sequence:

# MUST run first, or the reinstall lands on the encrypted volume again
Set-AppxDefaultVolume -Volume C:\

Get-AppxPackage OpenAI.Codex | Remove-AppxPackage
winget install --id 9plm9xgg6vks --source msstore   # lands on C:, attributes clean, copyfile OK

Verified afterwards: InstallLocation on C:, package dir attributes just Directory, and relocation succeeds.

3. Heads-up: two follow-on failures after this one is fixed

From debugging the same machine to a fully working app, two more layers surfaced that readers of this thread will likely hit next:

1. A stale user-level CODEX_CLI_PATH env var pointing at a .cmd wrapper makes the app throw spawn EINVAL (CVE-2024-27980 mitigation — Node won't spawn .cmd without shell: true). Deleting the var lets the app use its bundled exe. Details in #40752.
2. ~/.codex/state_5.sqlite (migrated by 0.150.0-alpha.8) fails failed to initialize sqlite state runtime with no indication of which DB/step failed, despite integrity_check: ok and all migrations marked success. Deleting it forces a rebuild and fixes startup; sessions/*.jsonl transcripts are unaffected.

Suggestion for the app side

The relocation failure currently surfaces as "Unable to locate the Codex CLI binary", pointing users toward PATH/CODEX_CLI_PATH workarounds that don't address the real problem. If the installer/stager detected the Encrypted attribute on the package directory (or mapped error 6000) it could emit an actionable message — e.g. "package directory is EFS-encrypted; reinstall on a non-encrypted volume (Settings → Apps → Move, or Set-AppxDefaultVolume -Volume C:\ + reinstall)" — which would have saved most of the 70+ comments across the related threads.

Confirmed that this regression still reproduces after updating to the newer Windows AppX package OpenAI.Codex 26.820.9563.0 on Windows x64.

Observed locally:

• CODEX_CLI_PATH was unset at the time of failure.
• Get-AppxPackage OpenAI.Codex reports version 26.820.9563.0, status Ok.
• The package manifest launches app/ChatGPT.exe.
• app\resources\codex.exe exists and is 307,568,432 bytes.
• app\resources\codex-windows-sandbox-setup.exe also exists.
• app\resources\bin\codex.exe is absent.
• Launching the desktop app reports:

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

• Directly invoking the packaged app\resources\codex.exe --version from PowerShell fails with Access is denied / NativeCommandFailed.
• A standalone per-user CLI remains executable and reports codex-cli 0.147.0, so the failure is specific to the updated desktop package/runtime path.
• Read-only inspection of app.asar confirms the packaged startup code still emits the resources include bin/codex lookup error.

No permissions, ownership, ACLs, or files under WindowsApps were modified. This confirms the startup regression persists in 26.820.9563.0, not only 26.820.7780.0.

I maintain WinBridge Recovery: https://github.com/zemeng5208/winbridge-recovery

This report is a strong match for the Windows-local recovery layer WinBridge is intended to inspect: specifically the WindowsApps/Application Protected (EFS) source -> per-user bundled executable/runtime relocation path, including codex.exe, cua_node, partial .staging-* directories, and the resulting version/hash/materialization state under the user-local Codex runtime directories.

For this failure family, WinBridge can help distinguish and recover local fallout such as:

• incomplete or stale per-user relocation staging after ERROR_ENCRYPTION_FAILED / UNKNOWN -4094;
• missing or partially materialized codex.exe / cua_node user-local runtime copies;
• stale version/hash state left behind by a failed update;
• target-path or junction/reparse-point problems that can look similar to a protected-source copy failure.

Important limitation: WinBridge does not modify or take ownership of WindowsApps, does not bypass Application Protected/EFS semantics, and cannot make Node/Win32 CopyFile correctly handle a protected MSIX source if the current Codex build itself is using an incompatible relocation method. If the package source is healthy and every fresh relocation attempt still fails with Win32 6000 / ERROR_ENCRYPTION_FAILED, the durable fix belongs upstream (for example, using a decrypted-destination-capable copy path or buffered read/write fallback).

So I would use WinBridge here mainly to repair/validate the local post-failure state and to confirm whether the remaining blocker is still the upstream protected-file copy path. It may help diagnose or recover the local layer, but I would not expect or claim that it guarantees a fix for the underlying 26.820 relocation implementation.