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

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 }.

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.

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

[Windows 26.820] Codex Desktop cannot start: bundled codex.exe relocation from WindowsApps fails #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盘了

问题在于：你这个 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:

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.
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.

Also encountered "Unable to locate the Codex CLI binary. Set CODEX_CLI_PATH or ensure the Electron resources include bin/codex.". The temporary fix

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

worked.

Previously, I was using version 26.818.8289 without any issues. Just now, after installing the new version 26.825.32147, I found it also works normally. After installation, the Codex application didn't launch immediately upon startup, although the Codex process was running in Task Manager. The AI informed me that this is because Codex performs certain file copying operations during its first launch. After waiting about ten minutes, the Codex application window opened automatically and is currently functioning properly.

Disclosure: I maintain WinBridge Recovery, an independent Windows recovery/diagnostic project for Codex Desktop.

The newer diagnostics in this thread make one part of this issue a fairly direct match for WinBridge's local repair scope: the bundled codex/WSL resources exist in the current MSIX, but the per-user relocated copies are missing or incomplete and the WindowsApps -> user-directory copy fails with The specified file could not be encrypted / ERROR_ENCRYPTION_FAILED-type behavior.

WinBridge can help distinguish and recover the local materialization layer here: it checks the currently installed official package against the user-side bin/WSL runtime staging, incomplete or abandoned staging state, version/hash drift, and Windows path/reparse-point conditions, and it can identify when the failure is specifically an Application Protected/EFS source-copy problem rather than a genuinely missing bundled binary. It does not modify WindowsApps, take ownership of package files, or weaken package/security protections.

This would not address every failure discussed in this issue. In particular, spawn EINVAL from pointing CODEX_CLI_PATH at a .cmd wrapper is a separate Desktop spawn-path problem, and a healthy relocated CLI followed by an app-server/state initialization failure is also outside this repair layer. Likewise, if a fresh relocation attempt against the current package consistently fails because Codex's own copy implementation cannot handle Application Protected/EFS sources, the durable fix still has to be upstream. So this is a diagnostic/recovery option for the broken local staging/materialization state, not a guaranteed fix for the whole issue.

Navigation Menu

Repository navigation

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

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

60 remaining items

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

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

Layer 3: `state_5.sqlite` failing to initialize

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

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

Description

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Activity

github-actions commented on Aug 26, 2026

DesignMike commented on Aug 26, 2026

huangkai-boy commented on Aug 26, 2026

EthanChen-CY commented on Aug 26, 2026

Between-The-Worlds commented on Aug 26, 2026

agoudbg commented on Aug 26, 2026

Kaz9487 commented on Aug 26, 2026

shallweiwei commented on Aug 26, 2026

lihongwei1024 commented on Aug 26, 2026

omematch commented on Aug 26, 2026

EthanChen-CY commented on Aug 26, 2026

Between-The-Worlds commented on Aug 26, 2026

60 remaining items

Sakura1314lyc commented on Aug 27, 2026

labulalala commented on Aug 27, 2026

liuruihang1688 commented on Aug 27, 2026

aryamazloomi commented on Aug 27, 2026

1328837476-hug commented on Aug 27, 2026

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

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

Layer 3: state_5.sqlite failing to initialize

2026-l commented on Aug 27, 2026

DrHenry0101 commented on Aug 27, 2026

zengshimao-prog commented on Aug 27, 2026

cre8ivevision commented on Aug 27, 2026

cre8ivevision commented on Aug 27, 2026

atao-henshuai commented on Aug 27, 2026

WilliamQD commented on Aug 27, 2026

MatPuza commented on Aug 29, 2026

lihongwei1024 commented on Aug 29, 2026

zemeng5208 commented on Aug 29, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

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

Layer 3: `state_5.sqlite` failing to initialize