Codex Windows App fails to start: bundled Codex CLI binary exists but cannot be executed

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

• #40853
• #40843
• #40700
• #40850
• #40804

Powered by Codex Action

$p=Join-Path (Get-AppxPackage OpenAI.Codex).InstallLocation "app\resources\codex.exe";[Environment]::SetEnvironmentVariable("CODEX_CLI_PATH",$p,"User");$env:CODEX_CLI_PATH=$p 使用这个命令，在powershell里执行，然后重启chatGPT就行了

Additional reproduction + confirmed workaround on Windows Store/MSIX build OpenAI.Codex 26.820.7780.0:

Reproduction details

The bundled files are present in the package, including:

app\resources\codex.exe
app\resources\codex
app\resources\codex-code-mode-host.exe
app\resources\codex-command-runner.exe
app\resources\codex-windows-sandbox-setup.exe

Both of these return True with Test-Path:

Test-Path "$pkg\app\resources\codex.exe"
Test-Path "$pkg\app\resources\codex"

However, attempting to execute the bundled Windows CLI directly fails:

& "$pkg\app\resources\codex.exe" --version

with:

程序“codex.exe”无法运行: 拒绝访问。
CategoryInfo          : ResourceUnavailable: (:) [], ApplicationFailedException
FullyQualifiedErrorId : NativeCommandFailed

(Access denied.)

Also, no usable per-user relocated CLI was present under either:

%LOCALAPPDATA%\OpenAI\Codex\bin
%USERPROFILE%\.codex\bin

CODEX_CLI_PATH was initially unset, and no WSL-related runCodexInWindowsSubsystemForLinux setting was found in the user config/state files checked.

Confirmed workaround

I installed the standalone Codex CLI through npm:

npm.cmd install -g @openai/codex@latest

This installed codex-cli 0.149.1.

I then located the native Windows executable inside the npm package (not the codex.cmd wrapper), e.g.:

%APPDATA%\npm\node_modules\@openai\codex\node_modules\@openai\codex-win32-x64\vendor\x86_64-pc-windows-msvc\bin\codex.exe

The native executable runs correctly:

& <native-codex.exe> --version
# codex-cli 0.149.1

Then I set the user environment variable:

[Environment]::SetEnvironmentVariable(
    "CODEX_CLI_PATH",
    "<path-to-native-codex.exe>",
    "User"
)

After restarting Windows, the ChatGPT/Codex desktop app starts normally again.

This suggests the packaged CLI is present but unusable from the Store/MSIX location on this system, while a normal unprotected native codex.exe works immediately when explicitly supplied via CODEX_CLI_PATH.

I did not modify ownership, ACLs, or permissions under C:\Program Files\WindowsApps.

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

This report is close to the local Windows repair layer WinBridge is intended to diagnose, specifically the gap between the protected MSIX/WindowsApps resources and the per-user relocated runtime under %LOCALAPPDATA%\OpenAI\Codex\bin.

In this case, the important signal is not only that app\resources\codex.exe exists, but that it cannot be executed directly from the protected package location and there is no usable relocated per-user CLI. WinBridge can help inspect whether the current install has:

• a missing/partial per-user bin materialization,
• failed .staging-* relocation state,
• version/hash drift between the installed MSIX resources and the active per-user copy,
• Application Protected/EFS-related copy failures during relocation,
• or a destination-path/Junction problem that prevented the local runtime from being materialized.

It does not modify WindowsApps, take ownership of package files, or bypass package protection. It also cannot guarantee a fix: if 26.820.7780.0 is using a relocation/copy path that is intrinsically incompatible with the protected package resources on this Windows configuration, the durable fix needs to be in Codex's Windows relocation logic rather than in local state repair.

Also, setting CODEX_CLI_PATH directly to the protected WindowsApps copy may still fail with Access denied, as this issue already demonstrates. A useful distinction is whether a verified unprotected per-user copy can be materialized from the currently installed official package; that separates local staging failure from a higher-level startup-path bug.

I also have this issue now

I could open it just fine yesterday, but today I can't open it at all, and uninstalling and reinstalling doesn't work either.Unable to locate the Codex CLI binary.Set CODEX_CLI_PATH or ensure the Electron resources include bin/codex.

I can reproduce this on a newer build: 26.820.9563.0.

One additional detail: the standalone CLI workaround does NOT fully resolve the issue on my machine.

I installed the official standalone Codex CLI successfully:

codex-cli 0.150.1

Path:

C:\Users\<USER>\AppData\Local\Programs\OpenAI\Codex\bin\codex.exe

I then set the user-level CODEX_CLI_PATH to this native codex.exe and rebooted Windows.

After that, the original "Unable to locate the Codex CLI binary" dialog disappeared, but the desktop app still does not create a GUI window.

Multiple ChatGPT.exe processes remain running in the background, but all have:

MainWindowHandle = 0
MainWindowTitle = empty

No codex.exe child process is launched.

The desktop log stops after only:

Launching app
Appshot hotkey inactive

I also performed a complete uninstall, verified that both the AppX package and LocalAppData package directory were removed, rebooted, and reinstalled from Microsoft Store.

The newly installed version is still 26.820.9563.0, and the bundled app\resources\codex.exe is again marked:

Archive, Encrypted

Attempting to copy that bundled executable fails with:

"The specified file could not be encrypted."

So in my case there appear to be two stages:

1. Bundled CLI relocation/execution failure.
2. Even with a valid external CLI supplied via CODEX_CLI_PATH, the desktop app remains headless and never creates a window.

the same issue

Update: the issue is still reproducible after updating to Codex App 26.820.9563.0.

CODEX_CLI_PATH is unset.

The bundled CLI exists:
Test-Path $cli
=> True

But executing:
& $cli --version

still fails with:
Access denied
FullyQualifiedErrorId: NativeCommandFailed

So the issue persists in 26.820.9563.0.

Follow-up after updating the Windows desktop app to 26.820.9563.0:

The original bundled-CLI problem was already worked around by keeping CODEX_CLI_PATH pointed to a working standalone native Codex CLI installed via npm (codex-cli 0.149.1). After the desktop app updated to 26.820.9563.0, a second failure mode appeared.

New symptom on 26.820.9563.0

Launching the app created multiple ChatGPT.exe processes, but no GUI window appeared. Diagnostics showed:

MainWindowHandle = 0

for every ChatGPT.exe process. One process reached roughly 400+ MB working set and ~58 threads, so the process tree itself was alive rather than immediately crashing. No codex.exe child process was present during the headless period.

Thread inspection did not show WaitReason=Suspended, so NtResumeProcess was not the relevant workaround here.

I also tested disabling the updater path:

CODEX_SPARKLE_ENABLED=false

and launched the app inside the MSIX package context with Invoke-CommandInDesktopPackage. The variable was confirmed active; the startup log showed:

Launching app ... enableSparkle=false enableUpdater=false ...
Appshot hotkey inactive ...

and then no additional log lines for a prolonged period. The app remained headless with all MainWindowHandle=0.

Recovery behavior observed

After leaving the headless process tree running instead of killing/relaunching it repeatedly, the GUI eventually appeared on its own after a long initial wait.

Crucially, after the first successful launch completed, I exited the app normally and launched it again. The second launch completed in under 6 seconds.

So on this system the practical sequence was:

1. 26.820.7780.0: bundled codex.exe exists but is not executable from WindowsApps (Access denied).
2. Workaround: install standalone Codex CLI and set CODEX_CLI_PATH to the native npm codex.exe; desktop app becomes usable.
3. Update to 26.820.9563.0: app initially becomes headless (ChatGPT.exe processes alive, every MainWindowHandle=0, no GUI).
4. CODEX_SPARKLE_ENABLED=false is active, but the first post-update startup still stalls for a long time.
5. Eventually the GUI appears without reinstalling/resetting the package.
6. After that first successful initialization, a full exit/relaunch takes <6 seconds.

This looks consistent with the reports where 26.820.9563.0 experiences an abnormally long first-start/bootstrap stall after update, after which subsequent launches become normal again.

Current workaround state retained on this machine:

CODEX_CLI_PATH=<working standalone native codex.exe>
CODEX_SPARKLE_ENABLED=false

No ownership/ACL changes were made under C:\Program Files\WindowsApps.