[Bug] Windows Desktop app fails to start after update to v26.820.60940 ("Unable to locate Codex CLI" & spawn EINVAL on .cmd wrapper)

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

• #40700

Powered by Codex Action

Mine is loading but I cannot reply to any chats (new or existing). I can only start a chat, but cannot reply after the first message

I am experiencing the same issue on Windows.

Environment:

• Windows 11 x64
• Codex Desktop: 26.820.7780.0
• Previous working version: 26.818.8289.0

The issue started immediately after updating from 26.818.8289.0 to 26.820.7780.0.

Codex Desktop fails to start and reports:

"Unable to locate the Codex CLI binary......................."

I verified that the bundled Codex CLI exists:

C:\Program Files\WindowsApps\OpenAI.Codex_26.820.7780.0_x64__2p2nqsd0c76g0\app\resources\codex.exe

The executable has a valid Authenticode signature.

However, executing the bundled CLI directly:

.\resources\codex.exe --version

results in:

"Access is denied."

Windows AppModel Runtime logs show that the Codex AppX process is successfully created (Event ID 201/211), but the AppX container is subsequently destroyed (Event ID 217).

The previous version 26.818.8289.0 worked correctly before the update.

This appears to be a Windows Desktop regression introduced by the 26.820.x update.

I have not modified WindowsApps ACLs or permissions.

Please let me know if there is a recommended workaround or a fixed/test build available.

metoo

艹，我也是

Same issue on Windows. Set environment variable CODEX_CLI_PATH bypasses the issue for me.

Same issue on Windows.

how to fix this？

Supplement / Solution Update:

Previously, setting the CODEX_CLI_PATH environment variable to point to an external native codex.exe allowed bypassing startup errors and launching the application, but this caused session lists and historical conversations to fail to load or open properly (due to IPC communication protocol or version incompatibility between the new desktop UI and the external CLI).

My current solution is to roll back (downgrade) directly to the previous desktop version (v26.818.8289.0).

Rollback Steps (PowerShell):

Download package: https://github.com/Wangnov/codex-app-mirror

Obtain the official MSIX installer for the previous version (e.g., ChatGPT-26.818.8289.0-x64.msix).

Remove any previously manually added CODEX_CLI_PATH environment variable to avoid conflicts with the older version:

PowerShell
[Environment]::SetEnvironmentVariable("CODEX_CLI_PATH", $null, "User")
Run PowerShell as administrator and execute the forced downgrade overwrite installation:

PowerShell installation command:
Add-AppxPackage -Path "installation package path\ChatGPT-26.818.8289.0-x64.msix" -ForceUpdateFromAnyVersion

For anyone facing the same issue: did you also install Codex on a non-C drive?

给遇到同样问题的人：你是在非C盘上安装Codex的吗？

不是，要不等更新，要不老老实实回滚吧

确实不是在C盘，我装到D盘了

装c盘就可以正常使用了

确实，在设置-应用系统里移动到C盘后就可正常运行了。

确实，在设置-应用系统里移动到C盘后就可正常运行了。确实，在设置-应用系统里移动到C盘后就可正常运行了。

有用！

Here's how I fixed it:

1. I reinstalled the standalone version of Codex CLI, generating a new file: C:\Users\32193\.codex\packages\standalone\releases\0.149.1...\bin\codex.exe

1. I set CODEX_CLI_PATH so that the desktop application explicitly calls this new file.

Wait for an update.

Can confirm the same issue on Windows after the update.

The native Codex CLI is installed correctly and works normally:

```text id="sh0vbb"
PS> codex --version
codex-cli 0.149.1

PS> where.exe codex
C:\Users\<user>\AppData\Local\Programs\OpenAI\Codex\bin\codex.exe

ChatGPT still fails to start with:

```text id="xwfs9d"
Unable to locate the Codex CLI binary. Set CODEX_CLI_PATH or ensure the Electron resources include bin/codex.

As a workaround, explicitly setting CODEX_CLI_PATH to the native executable fixes the startup issue for me:

```powershell id="0rtxq3"
[Environment]::SetEnvironmentVariable(
"CODEX_CLI_PATH",
"$env:LOCALAPPDATA\Programs\OpenAI\Codex\bin\codex.exe",
"User"
)

Then fully terminating and restarting ChatGPT allows the app to start normally.

This is essentially the same workaround as the OP, but confirming that the issue also occurs with a clean native Codex CLI installation where `codex.exe` is already available on PATH.

Same issue happened just now on my Windows 11.

怎么解决这个问题，家人们

Me too

[Bug] ChatGPT Windows app v26.820.7780.0 cannot locate bundled Codex CLI after update

Microsoft Store package ID:9PLM9XGG6VKS

Package name:OpenAI.Codex

STOP DOING YOUR SHITTY APP WITH IA.

MORRONS

me too

Confirmed workaround on my Windows 11 machine

I had the same startup error:

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

My standalone CLI is on D:. The key was to point CODEX_CLI_PATH to the native codex.exe, not to codex.cmd.

$codexExe = 'D:\Codex\bin\codex.exe'

if (-not (Test-Path -LiteralPath $codexExe -PathType Leaf)) {
    throw "Native codex.exe not found: $codexExe"
}

& $codexExe --version
if ($LASTEXITCODE -ne 0) {
    throw "codex.exe did not start successfully"
}

[Environment]::SetEnvironmentVariable('CODEX_CLI_PATH', $codexExe, 'User')
$env:CODEX_CLI_PATH = $codexExe

After running this, I launched the ChatGPT desktop app immediately. It opened successfully; I did not need to reboot Windows.

This is only a workaround confirmed on my own PC. My standalone CLI is located at D:\Codex\bin\codex.exe; I cannot determine from one machine whether the drive location is the root cause.

References / credit

The workaround idea came from:

• The [original report in this issue](https://github.com/openai/codex/issues/40752)
• A [standalone CLI workaround](https://github.com/openai/codex/issues/40752#issuecomment-5420377714)
• A native codex.exe confirmation
• [OpenAI's Codex environment-variable documentation](https://learn.chatgpt.com/docs/config-file/environment-variables)

The result and the D:\Codex\bin\codex.exe path above are from my own successful test.

same

I’m seeing the same Windows startup failure on a newer Codex build:

Codex App: 26.820.7780.0
OS: Windows 11 x64
Environment: WSL enabled

Both bundled binaries are present:

...\app\resources\codex
...\app\resources\codex.exe

Both have:

Attributes: Archive, Encrypted

However, the relocated/staged binaries are missing:

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

Manually copying the bundled codex binary also fails with:

The specified file could not be encrypted.
System.IO.IOException

The app then fails at startup with:

Unable to locate the Codex CLI binary.

A full Windows reboot did not resolve the issue.

This looks like a failure in the CLI relocation/staging step rather than a missing binary in the MSIX package. Importantly, it is still reproducible on 26.820.7780.0.

解决办法：卸载当前codex，改回默认的系统目录：C:\Program Files\WindowsApps\，重新在微软应用商店安装

如果是Electron 安装包没有把 codex.exe 放进 resources/bin/ 目录，
可以参考我这个方法：https://github.com/88lin/codex-desktop-windows-fix

I fixed this by moving ChatGPT app from D: to C: simply in setting>application>installed application, not sure work for everyone. win11

Before the update, it was installed on the C drive, but after the update, it moved to the D drive. You just need to move ChatGPT back to the C drive in the settings to fix it.

如果还打不开：有一个目前比较有效的临时解决办法

原理很简单：

现在 ChatGPT 在找：

codex.exe

但自己的安装包里没找到。

那我们自己装一份官方 Codex CLI，然后告诉 ChatGPT：

“Codex 在这里。”

OpenAI 现在有官方 Windows 安装脚本。

打开 PowerShell，运行：

powershell -ExecutionPolicy ByPass -c "irm https://chatgpt.com/codex/install.ps1 | iex"

正常情况下 Codex 会安装到：

C:\Users\你的用户名\AppData\Local\Programs\OpenAI\Codex\bin\codex.exe

官方安装脚本本身也是把这个目录作为 Windows 默认安装位置。

安装完成之后，在 PowerShell 再运行：

[Environment]::SetEnvironmentVariable(
"CODEX_CLI_PATH",
"$env:LOCALAPPDATA\Programs\OpenAI\Codex\bin\codex.exe",
"User"
)

然后：

彻底退出 ChatGPT → 再重新打开。

注意一个很关键的小坑：一定要指向 codex.exe，不要指向 codex.cmd。

因为今天这个 Windows Bug 里，有人把 CODEX_CLI_PATH 指向 codex.cmd 后又碰到了 spawn EINVAL；直接指向真正的 codex.exe 则可以正常启动。

I encountered this issue on Codex Desktop “26.820.7780.0” after an update on Windows.

In my local case, the bundled CLI itself was not missing. “codex.exe” was present under the installed package path “app\resources”.

The actual failure occurred during bundled executable relocation. Codex Desktop attempted to copy the bundled CLI from the WindowsApps package into its local runtime directory:

C:\Program Files\WindowsApps\OpenAI.Codex_<version>\app\resources\codex.exe
    ->
%LOCALAPPDATA%\OpenAI\Codex\bin\.staging-...\codex.exe

The relocation failed with:

operation=copy_file
syscall=copyfile
errno=-4094
code=UNKNOWN
sourceKind=windowsapps

Similar relocation failures also occurred for bundled runtime files such as “cua_node”, so at least in my case, the final error message:

“Unable to locate the Codex CLI binary”

was a consequence of the relocation failure rather than the CLI binary actually being absent.

The important conflict I found locally was a mixed-drive MSIX/WindowsApps state: the Codex application was being loaded from “D:\WindowsApps”, while bundled resources were being resolved from “C:\Program Files\WindowsApps”.

After changing the Windows setting for the default location of new apps to the system drive “C:”, uninstalling Codex, and reinstalling it so the package was installed entirely on “C:”, Codex started normally again.

So, for my local case, the issue appears to have been related to WindowsApps/MSIX bundled executable relocation across mixed installation drives.

Confirmed solution for my environment:

1. Set the Windows default location for new apps to “C:”.
2. Uninstall Codex Desktop.
3. Reinstall Codex Desktop.
4. Verify that the Codex package is installed under “C:\Program Files\WindowsApps”.
5. Start Codex normally.

No “CODEX_CLI_PATH” override was required.

This may not explain every occurrence of the same error, but it was the confirmed cause and fix on my machine.

I fixed this by moving ChatGPT app from D: to C: simply in setting>application>installed application, not sure work for everyone. win11

Thanks! This worked for me on Windows 11. Moving the ChatGPT app from D: to C: fixed the issue immediately.

Confirmed a working workaround on Windows after hitting the same ChatGPT startup error (Unable to locate the Codex CLI binary).

In my case there were two layers to the problem:

1. Codex CLI was initially missing from PATH (where.exe codex returned nothing).
2. After npm install -g @openai/codex, the wrapper was installed but running it failed with:

Missing optional dependency @openai/codex-win32-x64.

What worked:

npm.cmd uninstall -g @openai/codex
npm.cmd install -g --include=optional @openai/codex@latest

After that:

codex.cmd --version
# codex-cli 0.149.1

where.exe codex
# ...\AppData\Roaming\npm\codex
# ...\AppData\Roaming\npm\codex.cmd

The native Windows package was also present:

@openai/codex-win32-x64@npm:@openai/codex@0.149.1-win32-x64

However, the ChatGPT Windows app still did not start by merely having codex.cmd available. The final workaround was to locate the actual native codex.exe and set CODEX_CLI_PATH to that executable (not the .cmd wrapper):

$codexExe = Get-ChildItem "$env:APPDATA\npm\node_modules\@openai\codex\node_modules\@openai\codex-win32-x64" -Recurse -Filter codex.exe | Select-Object -First 1 -ExpandProperty FullName
[Environment]::SetEnvironmentVariable("CODEX_CLI_PATH", $codexExe, "User")

After fully quitting and restarting ChatGPT, the Windows app launched successfully.

So for this environment, pointing CODEX_CLI_PATH directly to the native codex.exe was the key fix. Hopefully this helps confirm the issue/workaround for others.

<img width="801" height="216" alt="Image" src="https://github.com/user-attachments/assets/76044677-8f74-4d66-8bc5-cccfc97c67c2" />
移动到C盘，正常启动了

2026年8月26日15：40，在windows11的设置里面，将codex从D盘移动到C盘，解决了同样的问题
At 15:40 on August 26, 2026, in the settings of Windows 11, moving Codex from drive D to drive C solved the same problem

<img width="1170" height="366" alt="Image" src="https://github.com/user-attachments/assets/39896452-29d6-4842-a8a7-848e0899a0ee" />

回滚到旧版本侧边栏聊天会话还在吗

我不太清楚，我没有使用回滚的办法，因为我的Cotex本身就是在d盘装的，我移动到c盘就好了，但是我估计回滚的话，只是把版本退回去，里边的数据应该都在的吧....

---Original---
From: @.*&gt;
Date: Wed, Aug 26, 2026 16:09 PM
To: @.*&gt;;
Cc: @.****@.**&gt;;
Subject: Re: [openai/codex] [Bug] Windows Desktop app fails to start after update to v26.820.60940 ("Unable to locate Codex CLI" &amp; spawn EINVAL on .cmd wrapper) (Issue #40752)

xufeng123-henan left a comment (openai/codex#40752)

回滚到旧版本侧边栏聊天会话还在吗

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you commented.Message ID: @.***&gt;

Me too. What the hell!

那你的移动到C盘然后侧边栏会话记录还一样有保存吧

Additional evidence from the same Windows app release suggests that the initial “Unable to locate the Codex CLI” failure is separate from the later .cmd / spawn EINVAL behavior described here.

On app version 26.820.60940 (MSIX package 26.820.7780.0), the bundled native app\resources\codex.exe exists and has a valid OpenAI signature. The first recorded failure occurs while relocating that executable from WindowsApps on a secondary Appx volume to %LOCALAPPDATA%\OpenAI\Codex\bin\.staging-*:

• operation=copy_file
• syscall=copyfile
• errno=-4094
• code=UNKNOWN
• sourceKind=windowsapps

Only after this relocation failure does the locator return no executable and surface the missing-CLI startup error.

Pointing CODEX_CLI_PATH directly to the native Codex 0.149.1 codex.exe bypasses the bundled relocation path and allows the app to start. This is a workaround, not a repair of the underlying relocation failure.

Full redacted diagnostic evidence: https://github.com/openai/codex/issues/38696#issuecomment-5422486768

我的已经在C盘了 现在咋办呢

I'm not working today until this gets fixed. Otherwise, I'll switch to Claude.
I don't want a bunch of hacky workarounds.

{ [Environment]::SetEnvironmentVariable(
"CODEX_CLI_PATH",
"D:\WindowsApps\OpenAI.Codex_26.820.7780.0_x64__2p2nqsd0c76g0\app\resources\codex.exe",
"User")
}
[Environment]::GetEnvironmentVariable("CODEX_CLI_PATH", "User")

我也可以稳定复现，并且我的安装位置在非系统盘 F:。

难道一定要让我放到已经爆满的c盘吗！😭

Windows Desktop fails to locate Codex CLI after update when installed on non-system drive

Environment

• OS: Windows 11 x64
• ChatGPT / Codex Desktop installed on: F:\OpenAI
• Subscription: ChatGPT Plus
• Codex session directory: C:\Users\Administrator\.codex\sessions

Issue

After a ChatGPT/Codex Desktop update, the application failed to start with:

ChatGPT failed to start.

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

However, the Codex CLI binary was present and executable at:

F:\OpenAI\Codex\bin\codex.exe

Running:

& "F:\OpenAI\Codex\bin\codex.exe" --version

worked correctly.

Manually setting:

CODEX_CLI_PATH=F:\OpenAI\Codex\bin\codex.exe

allowed the Desktop app to start.

Secondary issue

The bundled CLI at that location was an old version:

codex-cli 0.130.0-alpha.5

After the app started, recent conversations could not be restored and showed:

failed to read thread
rollout ... does not start with session metadata

The affected sessions had been created by newer CLI versions:

0.148.0-alpha.15
0.149.0-alpha.4.3

I inspected the affected .jsonl files and confirmed:

UTF8_BOM  = False
JSONValid = True
FirstType = session_meta

So the session files themselves were valid.

Workaround

Installing the latest standalone Codex CLI and setting:

CODEX_CLI_PATH=C:\Users\Administrator\.codex\packages\standalone\current\bin\codex.exe

resolved both the application startup problem and the thread restore problem.

Suspected cause

The Windows Desktop updater appears to lose or incorrectly resolve the Codex CLI path when the application is installed on a non-system drive.

The fallback CLI located under the custom installation directory may also remain outdated, causing compatibility problems with sessions created by newer Desktop versions.

Expected behavior

After updating:

1. Desktop should correctly locate its bundled/current Codex CLI regardless of installation drive.
2. The updater should keep the bundled CLI version synchronized with the Desktop version.
3. Users should not need to manually configure CODEX_CLI_PATH.
4. Desktop should avoid selecting an outdated fallback CLI when newer compatible CLI installations are available.

那你的移动到C盘然后侧边栏会话记录还一样有保存吧

有的

给遇到同样问题的人：你是在非C盘上安装Codex的吗？

是的

Additional confirmed Windows workaround from another affected user:

• After a Codex Desktop update, the app failed at startup with: Unable to locate the Codex CLI binary.
• Windows App Repair did not help.
• A native CLI executable was already present at %USERPROFILE%\.codex\.sandbox-bin\codex.exe.
• Running that binary directly with --version succeeded and reported codex-cli 0.148.0-alpha.9, confirming the CLI itself was healthy.
• Setting the user environment variable CODEX_CLI_PATH to %USERPROFILE%\.codex\.sandbox-bin\codex.exe restored Codex Desktop startup successfully.

This further supports a desktop startup/path-resolution regression rather than a corrupt CLI. The .sandbox-bin\codex.exe path can also serve as a temporary recovery path when present.

For installations located on a drive other than the C: drive, find the path to codex-code-mode-host.exe. In the same directory, there should also be a codex.exe file.

Set the path to codex.exe as the value of the CODEX_CLI_PATH environment variable, and the issue should be resolved.

<img width="836" height="208" alt="Image" src="https://github.com/user-attachments/assets/961f134d-275a-4d1a-a132-398c340749c0" />

Confirmed workaround on my Windows 11 x64 machine.

Environment:

• Node.js: v24.19.0
• npm: 12.0.2
• Codex CLI: 0.149.1

I installed the CLI with:

npm install -g @openai/codex@latest

The native executable was located at:

C:\Users\OMEN\AppData\Roaming\npm\node_modules\@openai\codex\node_modules\@openai\codex-win32-x64\vendor\x86_64-pc-windows-msvc\bin\codex.exe

Equivalent generalized location:

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

Then I set CODEX_CLI_PATH to that native codex.exe (not codex.cmd):

$codexExe = Get-ChildItem "$(npm root -g)\@openai\codex" -Recurse -Filter codex.exe |
    Select-Object -First 1 -ExpandProperty FullName

[Environment]::SetEnvironmentVariable("CODEX_CLI_PATH", $codexExe, "User")

After fully restarting the Codex/ChatGPT desktop app (and Windows if necessary), the app started successfully for me.

I have only confirmed that this fixes the startup failure; I have not yet verified whether using the external CLI causes any session/history compatibility issues.

I can reproduce this on Windows: ChatGPT still fails to start with Unable to locate the Codex CLI binary even after a full uninstall and clean reinstall. Could the OpenAI team please confirm whether a fixed Windows build is being prepared, and if possible provide an ETA (for example, whether the fix is expected within days)? Thanks.

最终解决方案涉是啥

艹，我也是

解决了?

最终解决方案涉是啥

A verified workaround without rolling back, modifying WindowsApps ACLs/ownership, or setting CODEX_CLI_PATH.
And stated the root cause
https://github.com/openai/codex/issues/40700#issuecomment-5419391502

对，基本可以确认这是 Codex Desktop 升级后的 Windows 回归 Bug，不是你机器配置错了，也不是你“装了两个 Codex”导致的。

我刚查了今天的官方 Codex GitHub issue，和你的情况几乎一模一样：

• Codex Desktop 升级到 26.820.60940
• Windows
• 启动时报 “Unable to locate the Codex CLI binary”
• 把 CODEX_CLI_PATH 指到 codex.cmd 又会报 spawn EINVAL
• 最终 workaround 正是把 CODEX_CLI_PATH 指向 npm 包里面真正的 codex.exe。([GitHub][1])

所以你的故障链是：

Codex Desktop 更新
        ↓
新版 Desktop 没正确找到/使用 bundled codex.exe
        ↓
Unable to locate the Codex CLI binary
        ↓
你本机 npm CLI 其实正常
        ↓
手动设置 CODEX_CLI_PATH
        ↓
指向真正的 native codex.exe
        ↓
重启 Desktop
        ↓
正常

为什么偏偏你会遇到？

你机器上的 CLI 是：

@openai/codex 0.148.0

它是通过 npm 安装的。

npm 给你提供：

codex
codex.cmd
codex.ps1

同时 package 内部又带了：

codex-win32-x64
    └── codex.exe

而新版 Desktop 在 Windows 上这一块的自动发现/打包路径出了问题。官方 issue 的 workaround 和我们给你设置的路径完全一致。([GitHub][1])

而且这不是孤立的 Windows 问题。最近 Codex Windows 的升级/打包路径确实连续出现过问题，例如 0.147.0 的 standalone auto-upgrade 就曾出现 launcher 和 codex-resources 不匹配的问题。([GitHub][2])

所以现在建议你什么都别折腾

保留现在的 CODEX_CLI_PATH。

它相当于给 Desktop 加了一个明确的 fallback：

CODEX_CLI_PATH
      ↓
真正的 codex.exe

等后面 Desktop 修复了这个 bug，正常情况下也不会妨碍使用。

唯一需要注意的是：以后 npm 升级 Codex CLI 后，这个路径里面的 native binary 位置通常仍然在 package 内，但如果包结构发生变化，可能需要重新检查一次。

如果你想升级 Codex：

npm update -g @openai/codex

升级后检查：

codex --version

**一句话：这次锅主要在新版 Codex Desktop 的 Windows CLI 自动发现/打包逻辑，不在你的 CLI 安装

<img width="1665" height="3057" alt="Image" src="https://github.com/user-attachments/assets/f5cacd85-367b-49d8-9408-74b017695716" />

绷不住了，没想到最后是这样解决的

Additional Windows workaround pitfall that may help others:

After the Desktop startup failure, setting CODEX_CLI_PATH to a native codex.exe did make the app start, but I initially pointed it at an older cached binary under %LOCALAPPDATA%\OpenAI\Codex\bin\<hash>\codex.exe.

That binary was codex-cli 0.146.0-alpha.9.2. Desktop launched, but some existing paginated/reverted conversations then failed to resume with:

invalid paginated history lineage for <thread-id>: cycle detected

The affected thread data itself was valid: the current reverted rollout had a distinct immutable rollout ID and a history_base pointing to the original rollout. The failure disappeared immediately after changing CODEX_CLI_PATH to a current native CLI (0.149.1).

This is consistent with the later fix in #38244 (Resolve paginated thread history by rollout ID), which distinguishes the stable logical thread ID from the immutable rollout ID after thread/revert.

So for anyone using the CODEX_CLI_PATH workaround on Windows, I would strongly recommend verifying the binary version first:

& $env:CODEX_CLI_PATH --version

and avoiding stale cached binaries under %LOCALAPPDATA%\OpenAI\Codex\bin\... unless their version is known to be current. A safer workaround is to point CODEX_CLI_PATH directly to the native codex.exe from a current CLI installation, not to codex.cmd and not to an old cache.

This may be worth mentioning in the startup error guidance, because an old native binary can appear to fix startup while silently introducing history-compatibility failures on newer paginated/reverted threads.

For installations located on a drive other than the C: drive, find the path to codex-code-mode-host.exe. In the same directory, there should also be a codex.exe file.对于安装在 C 盘以外的驱动器上的安装，找到 codex-code-mode-host.exe 的路径。在同一目录下，也应该有一个 codex.exe 文件。 Set the path to codex.exe as the value of the CODEX_CLI_PATH environment variable, and the issue should be resolved.将 codex.exe 的路径设置为 CODEX_CLI_PATH 环境变量的值，问题应该就能解决了。 <img alt="Image" width="835.9932861328125" height="207.99386596679688" src="https://private-user-images.githubusercontent.com/99320209/641500132-961f134d-275a-4d1a-a132-398c340749c0.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODc3NDY5NzcsIm5iZiI6MTc4Nzc0NjY3NywicGF0aCI6Ii85OTMyMDIwOS82NDE1MDAxMzItOTYxZjEzNGQtMjc1YS00ZDFhLWExMzItMzk4YzM0MDc0OWMwLnBuZz9YLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFWQ09EWUxTQTUzUFFLNFpBJTJGMjAyNjA4MjYlMkZ1cy1lYXN0LTElMkZzMyUyRmF3czRfcmVxdWVzdCZYLUFtei1EYXRlPTIwMjYwODI2VDEyMTc1N1omWC1BbXotRXhwaXJlcz0zMDAmWC1BbXotU2lnbmF0dXJlPWRiZDk5NDVmMmE3NTc1ZTRiNTFjNDk0ZWU3YTdkOWI4MDgxNjU4MDU4YjIxOWE5Mjg0OWZjZGNlNWU4YzVlNjImWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JnJlc3BvbnNlLWNvbnRlbnQtdHlwZT1pbWFnZSUyRnBuZyJ9.8uvjHjAD7eGSuuLy9kXCl3ExJ_a3pcUsGfjvxSCd-q0">

useful! Thanks

Same for me

I hit the same issue on Windows after updating Codex Desktop to 26.820.7780.0.
In my case, the root cause appears to be that Windows Store/AppX apps were installed on a non-system drive (D:).
Get-AppxDefaultVolume showed:

PackageStorePath : D:\WindowsApps
IsSystemVolume   : False

The bundled codex.exe was actually present, but the Codex logs showed that copying it from WindowsApps to LocalAppData failed:

bundled_executable_relocation_failed
operation=copy_file
executableName=codex.exe
errorCode=UNKNOWN
errno=-4094
syscall=copyfile
sourceKind=windowsapps

Immediately after that, Codex reported:

Unable to locate the Codex CLI binary.

What fixed it for me:
Windows Settings → Apps → Installed apps → Codex → Move → C:
After moving Codex from D: to the system drive, it started normally again.
I did not need to install a separate Codex CLI, set CODEX_CLI_PATH, modify WindowsApps permissions, or manually copy any files.
So if anyone encounters this issue and Get-AppxDefaultVolume points to a non-system drive, moving Codex back to C: may be worth trying first.

Being lazy, I had codex cli fix it:

• Paste this into Codex CLI on the affected Windows machine:

Fix the Windows Codex desktop-app startup failure described in:
https://github.com/openai/codex/issues/40752

Symptoms may include:

• “Unable to locate the Codex CLI binary”
• spawn EINVAL
• The Store app being installed on a non-C: drive

Please diagnose and fix it safely:

1. Confirm Windows, run codex --version, locate all codex launchers, inspect npm root --global, and check the current user-level CODEX_CLI_PATH.
2. Locate the native codex.exe inside the globally installed @openai/codex npm package. Search dynamically—do not hard-code my username, npm prefix,

architecture, or drive.

1. Do not point CODEX_CLI_PATH at codex.cmd, codex.ps1, or another script wrapper. It must point directly to a real native codex.exe.
2. Validate the selected executable by running it with --version.
3. Preserve and report any previous CODEX_CLI_PATH, then persist the validated path at user scope using:

[Environment]::SetEnvironmentVariable('CODEX_CLI_PATH', $nativeCodexPath, 'User')

1. Set the same value in the current PowerShell process so it can be tested immediately.
2. Run codex app and verify that the desktop app starts. Check the newest Codex desktop log for the previous missing-CLI or spawn EINVAL errors and confirm

normal startup activity.

1. Do not move the Store app between drives, change CODEX_HOME, change npm’s prefix/cache, delete files, reinstall software, or terminate a working Codex/

ChatGPT process unless necessary and explicitly approved.

1. If no suitable native executable exists, stop and explain what is missing before proposing an installation.
2. Finish with a concise summary of the old value, new value, executable version, and verification result.

This accommodates apps and repositories stored on D: or another native Windows drive, which the official Windows app documentation
(https://learn.chatgpt.com/docs/windows/windows-app) supports.

<img width="555" height="166" alt="Image" src="https://github.com/user-attachments/assets/1cf62ea7-76f4-451e-b044-3e81625f6843" />

Same here

For anyone still blocked on Windows after the 26.820.x update: I hit a very similar failure chain and got the Desktop working again without changing ACLs under C:\Program Files\WindowsApps.

What worked on the affected machine:

1. Install/update the standalone CLI:

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

1. Do not point CODEX_CLI_PATH at codex.cmd. Locate the native Windows binary inside the npm package and verify it first:

Get-ChildItem "$env:APPDATA\npm\node_modules\@openai" -Recurse -Filter codex.exe -ErrorAction SilentlyContinue | Select-Object -ExpandProperty FullName

Then run the newest candidate with --version. On the recovered machine the working binary was codex-cli 0.149.1 under a path ending in:

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

1. Set CODEX_CLI_PATH to that native exe, then fully restart Desktop/Windows:

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

Two extra gotchas I saw on the same machine:

• An older CLI could launch Desktop but then fail to read newer sessions, so make sure the CLI version is current before diagnosing thread corruption.
• If codex mcp list fails before listing anything, check the active config. One machine had service_tier = "priority", while the current parser expected fast or flex; backing up the config and changing that value to fast fixed config loading.

Also check whether a normal PowerShell startup is throwing Conda/Python profile errors while powershell -NoProfile works — that can break Desktop initialization independently of the CLI issue.

This is a workaround/diagnostic path, not an official fix. If anyone is still stuck after the native-CLI step, reply with just: Windows build, Desktop version, where codex, codex --version, and the exact error text. Please redact tokens/API keys.

Thanks for the bug report. We understand the problem and are working on expediting a fix.

I hit the same issue on Windows after updating Codex Desktop to 26.820.7780.0. In my case, the root cause appears to be that Windows Store/AppX apps were installed on a non-system drive (D:). showed:Get-AppxDefaultVolume PackageStorePath : D:\WindowsApps IsSystemVolume : False The bundled was actually present, but the Codex logs showed that copying it from WindowsApps to LocalAppData failed:codex.exe `` bundled_executable_relocation_failed operation=copy_file executableName=codex.exe errorCode=UNKNOWN errno=-4094 syscall=copyfile sourceKind=windowsapps ` Immediately after that, Codex reported: ` Unable to locate the Codex CLI binary. ` **What fixed it for me:** Windows Settings → Apps → Installed apps → Codex → **Move** → **C:** After moving Codex from D: to the system drive, it started normally again. I did **not** need to install a separate Codex CLI, set , modify WindowsApps permissions, or manually copy any files. So if anyone encounters this issue and points to a non-system drive, moving Codex back to C: may be worth trying first.CODEX_CLI_PATH`Get-AppxDefaultVolume

### Qual versão do aplicativo Codex você está usando (do diálogo "Sobre o Codex")? 26.820.60940 ### Qual assinatura você tem? ChatGPT Plus ### Qual é a sua plataforma? Windows 11 (x64) ### Qual problema você está vendo? Após atualizar o aplicativo Codex para a versão 26.820.60940, o aplicativo não inicia ao inicializar, reportando dois erros sequenciais: Falha inicial no lançamento: Não consegui localizar o binário do Codex CLI. Defina CODEX_CLI_PATH ou garanta que os recursos Electron incluam bin/codex. O cliente desktop não consegue localizar seu binário interno incluído no diretório de recursos/bin do Electron. Falha secundária ao especificar o script do wrapper: Ao definir CODEX_CLI_PATH para o comando global npm padrão (codex.cmd), o app falha imediatamente com: spawn EINVAL Isso ocorre porque o child_process.spawn() do Electron tenta executar o wrapper .cmd diretamente sem { shell: true }. <img alt="Imagem" width="417" height="124" src="https://private-user-images.githubusercontent.com/157190784/641254611-b3fda2ea-4241-4f12-bcd2-ff053eb17f10.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODc3OTE5ODYsIm5iZiI6MTc4Nzc5MTY4NiwicGF0aCI6Ii8xNTcxOTA3ODQvNjQxMjU0NjExLWIzZmRhMmVhLTQyNDEtNGYxMi1iY2QyLWZmMDUzZWIxN2YxMC5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwODI3JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDgyN1QwMDQ4MDZaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT0yNjdhZDA1ZmIxNjZiZjE4M2IyNTlhMmQ0YjhmZjI4NDg0NjJiMWYxNTM4OGQ2ZTE1ODU5MTBjMDMwNDNjOGI2JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZyZXNwb25zZS1jb250ZW50LXR5cGU9aW1hZ2UlMkZwbmcifQ.e2UKsoO-InLa_VZ0YmnikkzwZ5joj2SeUXzRrdcGL_c"> <img alt="Imagem" width="264" height="112" src="https://private-user-images.githubusercontent.com/157190784/641255283-2e5614e1-4cf3-405a-a949-36d9cd299d97.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODc3OTE5ODYsIm5iZiI6MTc4Nzc5MTY4NiwicGF0aCI6Ii8xNTcxOTA3ODQvNjQxMjU1MjgzLTJlNTYxNGUxLTRjZjMtNDA1YS1hOTQ5LTM2ZDljZDI5OWQ5Ny5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwODI3JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDgyN1QwMDQ4MDZaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT03ZjlmZDQxZmE0YjI3NWMwMWFmMjYzM2ZjMzlmYmJjMDAyNGVhMWYwNGRhMjFiM2E0NzUxOWM2YzgyMzZmNmI5JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZyZXNwb25zZS1jb250ZW50LXR5cGU9aW1hZ2UlMkZwbmcifQ.F56aMNlVAPVvnpylQudGuILmoQd2-GQOxyYot2k9Mks"> ### Quais passos podem reproduzir o bug? Atualize o Codex desktop para a versão 26.820.60940 no Windows 11. Abra o aplicativo. Observe o erro inicial: Não foi possível localizar o binário do Codex CLI. Defina a variável de ambiente do usuário CODEX_CLI_PATH para ...\nodejs\codex.cmd. Reinicie o aplicativo. Observe o erro secundário: gerar EINVAL. Solução alternativa: Apontar manualmente CODEX_CLI_PATH diretamente para o binário executável nativo subjacente, contorna ambos os erros e inicia o aplicativo com sucesso: ### Qual é o comportamento esperado? _Sem resposta_ ### Informações adicionais CODEX_CLI_PATH = <npm_root>\node_modules@openai\codex\node_modules@openai\codex-win32-x64\vendor\x86_64-pc-windows-msvc\bin\codex.exe Sugestões de Correções Garanta que o instalador/atualizador do Electron agrupe e extraia o binário nativo codex.exe em resources/bin/ por padrão. Se recorrer ao system PATH ou CODEX_CLI_PATH no Windows, resolva os wrappers de .cmd/.bat adequadamente ou use { shell: true } ao gerar arquivos batch para evitar o spawn EINVAL.

### What version of the Codex App are you using (From “About Codex” dialog)? 26.820.60940 ### What subscription do you have? ChatGPT Plus ### What platform is your computer? Windows 11 (x64) ### What issue are you seeing? After updating the Codex desktop app to version 26.820.60940, the application fails to launch on startup, reporting two sequential errors: Initial launch failure: Unable to locate the Codex CLI binary. Set CODEX_CLI_PATH or ensure the Electron resources include bin/codex. The desktop client fails to locate its bundled internal binary in the Electron resources/bin directory. Secondary failure when specifying wrapper script: When setting CODEX_CLI_PATH to the standard global npm command (codex.cmd), the app fails immediately with: spawn EINVAL This occurs because Electron's child_process.spawn() attempts to execute the .cmd wrapper directly without { shell: true }. <img alt="Image" width="417" height="124" src="https://private-user-images.githubusercontent.com/157190784/641254611-b3fda2ea-4241-4f12-bcd2-ff053eb17f10.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODc3OTIwMzUsIm5iZiI6MTc4Nzc5MTczNSwicGF0aCI6Ii8xNTcxOTA3ODQvNjQxMjU0NjExLWIzZmRhMmVhLTQyNDEtNGYxMi1iY2QyLWZmMDUzZWIxN2YxMC5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwODI3JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDgyN1QwMDQ4NTVaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT0zNGUzM2VmYzdmYzU0ODI1MmY1ZmM2ZTdlYTA4NjcxYjI4MGNjNDAyMWUyNTUxYTM1NmU2YmNhNmNlMzVjODk5JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZyZXNwb25zZS1jb250ZW50LXR5cGU9aW1hZ2UlMkZwbmcifQ.xlKM0lY2AKL8c8uGgiavpvs67tI8D8Z358GX8LmpmMI"> <img alt="Image" width="264" height="112" src="https://private-user-images.githubusercontent.com/157190784/641255283-2e5614e1-4cf3-405a-a949-36d9cd299d97.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODc3OTIwMzUsIm5iZiI6MTc4Nzc5MTczNSwicGF0aCI6Ii8xNTcxOTA3ODQvNjQxMjU1MjgzLTJlNTYxNGUxLTRjZjMtNDA1YS1hOTQ5LTM2ZDljZDI5OWQ5Ny5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwODI3JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDgyN1QwMDQ4NTVaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1kYzgzNDJjMjI4MGQ4ZGU3ZjJiYzg1MzNlNGVjZjQ3MTc5ZTk2OGRiNTgyM2VhYzdkMWNjNzZjMDIyZmI2Mjk2JlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZyZXNwb25zZS1jb250ZW50LXR5cGU9aW1hZ2UlMkZwbmcifQ.rP1HC_Ht6z-iWGQVbxEIoE_APze7nfMTRoICn3Kes9c"> ### What steps can reproduce the bug? Update Codex desktop to version 26.820.60940 on Windows 11. Launch the application. Observe the initial error: Unable to locate the Codex CLI binary. Set the user environment variable CODEX_CLI_PATH to ...\nodejs\codex.cmd. Relaunch the application. Observe the secondary error: spawn EINVAL. Workaround Manually pointing CODEX_CLI_PATH directly to the underlying native executable binary bypasses both errors and successfully launches the application: ### What is the expected behavior? _No response_ ### Additional information CODEX_CLI_PATH = <npm_root>\node_modules@openai\codex\node_modules@openai\codex-win32-x64\vendor\x86_64-pc-windows-msvc\bin\codex.exe Suggested Fixes Ensure the Electron installer/updater bundles and extracts the native codex.exe binary into resources/bin/ by default. If falling back to system PATH or CODEX_CLI_PATH on Windows, resolve .cmd/.bat wrappers appropriately or use { shell: true } when spawning batch files to prevent spawn EINVAL.

This solved my problem:
Windows Settings → Apps → Installed apps → Codex → ​​Move → C (or D, depending on your directory):
After moving Codex from D: to the system drive, it started working normally again.

问题在于：你这个 Windows 桌面版当前有一个已知 bug，它不认 npm 生成的 codex.cmd 包装器，而是想直接拿到真正的 codex.exe。 昨天就有人报告了和你几乎一模一样的问题：Windows 11、桌面端启动提示 Unable to locate the Codex CLI binary；把 CODEX_CLI_PATH 指向 .cmd 还会触发 spawn EINVAL。目前的 workaround 是直接把它指向 npm 包内部真正的 codex.exe。

你直接在 PowerShell 执行下面这个，先找到真正的 exe：

Get-ChildItem "$env:APPDATA\npm\node_modules\@openai\codex" -Recurse -Filter codex.exe | Select-Object -ExpandProperty FullName

正常应该出来一个类似：

C:\Users\<用户名>\AppData\Roaming\npm\node_modules\@openai\codex\node_modules\@openai\codex-win32-x64\vendor\x86_64-pc-windows-msvc\bin\codex.exe

这正是目前报告里有效的 native binary 路径。

然后把它保存成环境变量。最省事可以直接：

$codexExe = Get-ChildItem "$env:APPDATA\npm\node_modules\@openai\codex" -Recurse -Filter codex.exe |
Select-Object -First 1 -ExpandProperty FullName

[Environment]::SetEnvironmentVariable(
"CODEX_CLI_PATH",
$codexExe,
"User"
)

$codexExe

最后一行应该打印那个完整的 ...\codex.exe 路径。

再验证：

[Environment]::GetEnvironmentVariable("CODEX_CLI_PATH", "User")

然后完全退出桌面版 ChatGPT/Codex，注意不是只关窗口，最好任务管理器里确认 ChatGPT / Codex 进程都没了，再重新启动。

回滚已解决这个版本的问题：
仓库：https://github.com/Wangnov/codex-app-mirror/releases/tag/codex-app-26.818.61809
参考回滚命令：Add-AppxPackage -Path "F:\Downloads\OpenAI.Codex_26.818.8289.0_x64__2p2nqsd0c76g0.Msix" -ForceUpdateFromAnyVersion

Confirmed workaround on Windows 11: rolling the Codex desktop app back to the previous 26.818.61809 release resolves the startup failure introduced by 26.820.60940.

Third-party mirror used for the rollback package:
https://github.com/Wangnov/codex-app-mirror/releases/tag/codex-app-26.818.61809

Example PowerShell rollback command:

Add-AppxPackage -Path "F:\Downloads\OpenAI.Codex_26.818.8289.0_x64__2p2nqsd0c76g0.Msix" -ForceUpdateFromAnyVersion

After installing the older MSIX with -ForceUpdateFromAnyVersion, the desktop app starts normally again. This suggests the regression is specific to the newer Windows desktop build/update rather than the local npm Codex installation.

Note: the linked mirror is an unofficial third-party repository, so users should verify the package/source before installing.

问题在于：你这个 Windows 桌面版当前有一个已知 bug，它不认 npm 生成的 codex.cmd 包装器，而是想直接拿到真正的 codex.exe。 昨天就有人报告了和你几乎一模一样的问题：Windows 11、桌面端启动提示 Unable to locate the Codex CLI binary；把 CODEX_CLI_PATH 指向 .cmd 还会触发 spawn EINVAL。目前的 workaround 是直接把它指向 npm 包内部真正的 codex.exe。 你直接在 PowerShell 执行下面这个，先找到真正的 exe： Get-ChildItem "$env:APPDATA\npm\node_modules\@openai\codex" -Recurse -Filter codex.exe | Select-Object -ExpandProperty FullName 正常应该出来一个类似： C:\Users\<用户名>\AppData\Roaming\npm\node_modules\@openai\codex\node_modules\@openai\codex-win32-x64\vendor\x86_64-pc-windows-msvc\bin\codex.exe 这正是目前报告里有效的 native binary 路径。 然后把它保存成环境变量。最省事可以直接： $codexExe = Get-ChildItem "$env:APPDATA\npm\node_modules\@openai\codex" -Recurse -Filter codex.exe | Select-Object -First 1 -ExpandProperty FullName [Environment]::SetEnvironmentVariable( "CODEX_CLI_PATH", $codexExe, "User" ) $codexExe 最后一行应该打印那个完整的 ...\codex.exe 路径。 再验证： [Environment]::GetEnvironmentVariable("CODEX_CLI_PATH", "User") 然后完全退出桌面版 ChatGPT/Codex，注意不是只关窗口，最好任务管理器里确认 ChatGPT / Codex 进程都没了，再重新启动。

请问这个是否会影响下一步更新

<img alt="图片" width="555" height="166" src="https://private-user-images.githubusercontent.com/182114311/641698758-1cf62ea7-76f4-451e-b044-3e81625f6843.png?jwt=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3ODc3OTc0NzUsIm5iZiI6MTc4Nzc5NzE3NSwicGF0aCI6Ii8xODIxMTQzMTEvNjQxNjk4NzU4LTFjZjYyZWE3LTc2ZjQtNDUxZS1iMDQ0LTNlODE2MjVmNjg0My5wbmc_WC1BbXotQWxnb3JpdGhtPUFXUzQtSE1BQy1TSEEyNTYmWC1BbXotQ3JlZGVudGlhbD1BS0lBVkNPRFlMU0E1M1BRSzRaQSUyRjIwMjYwODI3JTJGdXMtZWFzdC0xJTJGczMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDI2MDgyN1QwMjE5MzVaJlgtQW16LUV4cGlyZXM9MzAwJlgtQW16LVNpZ25hdHVyZT1lNGRiNjg1NDM4OTEyMTQ2MjA3OTZjMzFlNjNlNjIwMmU5MWFhOTlkZjdjZTI4YjUyMzUzY2I5MTM1OWEzNmYzJlgtQW16LVNpZ25lZEhlYWRlcnM9aG9zdCZyZXNwb25zZS1jb250ZW50LXR5cGU9aW1hZ2UlMkZwbmcifQ.1YGYnqeNaYa9BNh5vi5iZ_5WvA-u89Uwonrt68Pd1Gk"> 我也是

how did you fix it?

Windows 11 上已确认的变通方法：将 Codex 桌面应用回滚到之前的 26.818.61809 版本，可以解决 26.820.60940 引入的启动失败。 用于回滚包的第三方镜像：https://github.com/Wangnov/codex-app-mirror/releases/tag/codex-app-26.818.61809 PowerShell 回滚命令示例： Add-AppxPackage -Path "F:\Downloads\OpenAI.Codex_26.818.8289.0_x64__2p2nqsd0c76g0.Msix" -ForceUpdateFromAnyVersion 安装旧版MSIX后，桌面应用又正常启动了。这表明回归是针对较新的Windows桌面版本/更新，而不是本地的npm Codex安装。-ForceUpdateFromAnyVersion 注意：链接的镜像是非官方第三方仓库，用户应在安装前核实包/源代码。

and it can update the newest version in the future?

> 问题在于：你这个 Windows 桌面版当前有一个已知 bug，它不认 npm 生成的 codex.cmd 包装器，而是想直接拿到真正的 codex.exe。 昨天就有人报告了和你几乎一模一样的问题：Windows 11、桌面端启动提示 Unable to locate the Codex CLI binary；把 CODEX_CLI_PATH 指向 .cmd 还会触发 spawn EINVAL。目前的 workaround 是直接把它指向 npm 包内部真正的 codex.exe。 > 你直接在 PowerShell 执行下面这个，先找到真正的 exe： > Get-ChildItem "$env:APPDATA\npm\node_modules@openai\codex" -Recurse -Filter codex.exe | Select-Object -ExpandProperty FullName > 正常应该出来一个类似： > C:\Users<用户名>\AppData\Roaming\npm\node_modules@openai\codex\node_modules@openai\codex-win32-x64\vendor\x86_64-pc-windows-msvc\bin\codex.exe > 这正是目前报告里有效的 native binary 路径。 > 然后把它保存成环境变量。最省事可以直接： > $codexExe = Get-ChildItem "$env:APPDATA\npm\node_modules@openai\codex" -Recurse -Filter codex.exe | > Select-Object -First 1 -ExpandProperty FullName > "CODEX_CLI_PATH", > $codexExe, > "User" > ) > $codexExe > 最后一行应该打印那个完整的 ...\codex.exe 路径。 > 再验证： > Environment::GetEnvironmentVariable("CODEX_CLI_PATH", "User") > 然后完全退出桌面版 ChatGPT/Codex，注意不是只关窗口，最好任务管理器里确认 ChatGPT / Codex 进程都没了，再重新启动。 请问这个是否会影响下一步更新

不影响桌面端正常更新。这个方法只是额外设置 CODEX_CLI_PATH，不会修改或替换 ChatGPT/Codex 桌面端文件。不过这个环境变量会在更新后继续存在；如果后续官方修复了该问题，可以删除它。若 Codex CLI 更新后内部 exe 路径发生变化，则需要重新设置一次。

Settings → Apps → Installed apps → ChatGPT → Move → C:

Why hasn't the official update this bug yet? I don't want to manually point it.

Settings → Apps → Installed apps → ChatGPT → Move → C:

This worked. Thanks!

Complete diagnostic write-up: spawn EINVAL on .cmd was layer 2 of 3 stacked root causes — with a runtime forensics method to see exactly what the app spawns

After fixing my machine (Win11 Home, package OpenAI.Codex_26.820.7780.0, installed on D: by a third-party "app relocation" tool), I found the failure was three stacked causes, each one hiding the next. Posting here since layers 1 & 3 are what people hit right after applying the CODEX_CLI_PATH workaround.

Layer 2 (this issue): why CODEX_CLI_PATH → codex.cmd throws synchronously

Node ≥ 18.20 / 20.12 / 22 refuses to spawn() a .cmd/.bat without shell: true — this is the CVE-2024-27980 (BatBadBut) mitigation, and it throws synchronously from ChildProcess.spawn before ever reaching CreateProcess (which matches the stack trace in the logs). Minimal repro:

const { spawn } = require('child_process');
spawn('D:\\node_js\\codex.cmd', ['--version'], { stdio: ['pipe','pipe','pipe'] });
// → throws Error: spawn EINVAL (synchronous)

How to see exactly what the app is spawning (beats static analysis of the asar): launch the exe directly with a --require hook — MSIX apps launched via shell:AppsFolder are spawned by the system and don't inherit your session env, but launching the exe path directly does:

$env:NODE_OPTIONS = '--require C:\hooks\spawn-hook.js'
Start-Process 'C:\Program Files\WindowsApps\OpenAI.Codex_..._x64__2p2nqsd0c76g0\app\ChatGPT.exe'

The hook wraps child_process.spawn and logs cmd/args/opts. It captured:

spawn cmd="D:\\node_js\\codex.cmd" args=["app-server", ...] opts={"stdio":["pipe","pipe","pipe"]}
spawn THROW EINVAL

Fix that worked here: delete the env var entirely instead of pointing it at an .exe:

[Environment]::SetEnvironmentVariable('CODEX_CLI_PATH', $null, 'User')

The desktop app then falls back to its bundled staged exe under %LOCALAPPDATA%\OpenAI\Codex\bin\<hash>\codex.exe, which spawns cleanly (same major version as the app — avoids the version-mismatch symptom reported above where pointing at an external/older CLI breaks session history).

Two caveats from my debugging session:

1. After deleting the variable, relaunching from the same terminal session still failed — the session env block is a snapshot from process start. Verify with a fresh Remove-Item Env:\CODEX_CLI_PATH in the launching command.
2. If EINVAL disappears but the app still shows an error, you're likely on to layer 3 ↓

Layer 1 (covered by #40843 / #38696): EFS-encrypted package directory

If %LOCALAPPDATA%\OpenAI\Codex\bin\<hash>\ contains 0-byte or missing files and the logs show copyfile ... UNKNOWN -4094: the package directory carries the EFS Encrypted attribute (relocation tool wrote it encrypted), and Win11 Home can neither encrypt new files nor decrypt existing ones (cipher /e and /d both fail with "not supported"), so relocation can never succeed. UNKNOWN -4094 is Node's unmapped representation of Win32 error 6000 ERROR_ENCRYPTION_FAILED — P/Invoke CopyFileW + GetLastWin32Error shows the real code immediately.

Reinstall is the only fix on Home, and Set-AppxDefaultVolume -Volume C:\ must be run first, or the fresh package lands on the encrypted volume again.

Layer 3: state_5.sqlite failing to initialize

After layers 1–2 were fixed, app-server spawned fine but exited immediately with:

Error: failed to initialize sqlite state runtime under C:\Users\<user>\.codex

Bisection (move all six *.sqlite out of ~/.codex, put them back one at a time) isolated it to state_5.sqlite: integrity_check = ok, all 50 _sqlx_migrations rows success=1, opens read-only fine — but both 0.150.0-alpha.8 (bundled) and 0.149.1 (npm) fail to initialize the state runtime on it. Deleting it and letting the app rebuild fixed startup; session transcripts in ~/.codex/sessions/*.jsonl are unaffected (lost 30 rows of thread metadata).

This error message currently gives no hint of which DB or which step failed — that turned a 5-minute check into a multi-hour hunt (see also #30105 / #39015 for the same pain on other DBs). Improving this on the Rust side would be a very welcome fix.

I encountered the same issue on Windows 11.

In my case, the Codex CLI itself was installed and working, but the ChatGPT Windows app could not locate the native codex.exe binary.

What worked for me was setting CODEX_CLI_PATH directly to the native executable inside the globally installed @openai/codex package, rather than pointing it to the npm wrapper (codex.cmd).

I documented the troubleshooting process and the workaround here:

https://github.com/2026-l/chatgpt-windows-codex-cli-fix

This is only a community workaround based on my own environment, not an official fix. Hopefully this information can help with diagnosing the underlying issue.

I’m seeing the same issue on Windows.

The Codex desktop app fails to start with:

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

I confirmed that codex.exe does exist inside the installed app package, but when I try to execute it manually, Windows returns:

Access is denied.

So in my case, this does not appear to be simply a missing CLI binary — the binary is present, but the app / Windows is unable to execute it from the WindowsApps package location.

What I have tried so far:

• Checked for app updates
• Confirmed codex.exe exists in the package
• Tried running the bundled codex.exe manually
• Manual execution returns Access is denied
• Restarting the app / Windows does not resolve the issue

Environment:

• OS: Windows 11
• Codex / ChatGPT Desktop version: 26.820.7780.0
• Installation source: Microsoft Store / Windows App package
• Error: Unable to locate the Codex CLI binary
• Bundled CLI execution result: Access is denied

This appears to match the behavior described in this issue.

If useful, I can provide additional logs, package paths, or diagnostics.

Adding another reproducible Windows report:

• ChatGPT Plus user on Windows 11 x64.
• The desktop app was working normally on Aug 25, 2026.
• On Aug 26 it began failing at startup with: Unable to locate the Codex CLI binary. Set CODEX_CLI_PATH or ensure the Electron resources include bin/codex.
• Check for Updates reports that ChatGPT is already up to date.
• Windows Security / Defender protection history shows no recent quarantine or blocking event related to ChatGPT/Codex.
• The app was fully uninstalled and reinstalled from the official distribution channel, followed by a reboot; the exact same startup error persists.
• No manual CODEX_CLI_PATH workaround has been applied.

This appears to be a regression affecting a clean/reinstalled Windows setup as well, not just a damaged local installation. The app is currently unusable on this machine until a fixed build is released.

I encountered the same issue on Windows 10 today. The app was working fine before the last shutdown, and I didn't initiate any updates.

OS Version: Win 10 PRO 22H2
ChatGPT Desktop App Version: 26.820.7780.0

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

Here is the log:

codex-desktop-b810af78-b248-4eb3-9218-3c7bbec26a98-10676-t0-i1-073711-0.log

I encountered the same issue on Windows 11. In my case, the Codex CLI itself was installed and working, but the ChatGPT Windows app could not locate the native codex.exe binary. What worked for me was setting CODEX_CLI_PATH directly to the native executable inside the globally installed @openai/codex package, rather than pointing it to the npm wrapper (codex.cmd). I documented the troubleshooting process and the workaround here: https://github.com/2026-l/chatgpt-windows-codex-cli-fix This is only a community workaround based on my own environment, not an official fix. Hopefully this information can help with diagnosing the underlying issue.

It worked for me on Windows 10 by simply following the steps. I didn’t have Codex CLI installed, so I installed it, set the environment variables, and the application started working when I launched it.

Thank you for your help.

给遇到同样问题的人：你是在非C盘上安装Codex的吗？

我在微软商店下载的，他自动默认安装到c盘，我不会改

Checking for update and installing the newest update fixed this for me.