I encountered the same issue: Windows Codex Desktop fails to start with "Unable to locate the Codex CLI binary"

Open 💬 2 comments Opened Aug 26, 2026 by xiaoxinquan
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

Windows Codex Desktop fails to start: "Unable to locate the Codex CLI binary" even though codex.exe is installed and accessible

What subscription do you have?

After launching the Codex Desktop application, it immediately fails with: "ChatGPT failed to start. Unable to locate the Codex CLI binary. Set CODEX_CLI_PATH or ensure the Electron resources include bin/codex."

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Title:

I encountered the same issue: Windows Codex Desktop fails to start with "Unable to locate the Codex CLI binary"

Description:

I encountered the same issue on Windows and would like to provide additional diagnostic information and a workaround.

After launching Codex Desktop, the application fails immediately with:

"ChatGPT failed to start.

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

Environment:

  • OS: Windows 11 x64
  • Application package: OpenAI.Codex
  • Version: 26.820.7780.0

Investigation:

I verified that the Codex CLI installation itself is working correctly.

Standalone Codex CLI path:

C:\Users\lenovo\AppData\Local\Programs\OpenAI\Codex\bin\codex.exe

Running:

codex --version

returns:

codex-cli 0.149.1

I configured the environment variable:

CODEX_CLI_PATH

with:

C:\Users\lenovo\AppData\Local\Programs\OpenAI\Codex\bin\codex.exe

The environment variable is correctly stored and the executable can be launched successfully.

Additional findings:

The installed Windows package contains:

app\resources\codex.exe

but does not contain:

app\resources\bin\codex

The application error message suggests it expects:

resources/bin/codex

but the installed package appears to provide:

resources/codex.exe

I also tested the bundled executable:

app\resources\codex.exe

but executing it directly results in:

ResourceUnavailable
NativeCommandFailed
Access denied

Workaround:

The issue can be temporarily bypassed by installing the standalone Codex CLI and setting:

CODEX_CLI_PATH

to the native executable:

C:\Users\lenovo\AppData\Local\Programs\OpenAI\Codex\bin\codex.exe

After restarting the Windows session and launching Codex Desktop again, the application can locate the CLI successfully.

Expected behavior:

Codex Desktop should either:

  1. Correctly locate the bundled CLI binary automatically.

or

  1. Correctly respect CODEX_CLI_PATH during startup.

Possible root cause:

The Windows Electron/MSIX package or startup logic may have a mismatch between the expected CLI location:

resources/bin/codex

and the actual packaged file:

resources/codex.exe

Suggested fixes:

  • Ensure the Windows package includes the expected resources/bin/codex binary.
  • Fix the startup path resolution logic.
  • Ensure CODEX_CLI_PATH is consistently respected on Windows.
  • Provide a clearer error message or repair guidance when the bundled binary cannot be executed.

Thank you for investigating this Windows issue.

What steps can reproduce the bug?

Possible root cause:

The Windows Electron/MSIX package or startup logic may have a mismatch between the expected CLI location:

resources/bin/codex

and the actual packaged file:

resources/codex.exe

Suggested fixes:

  • Ensure the Windows package includes the expected resources/bin/codex binary.
  • Fix the startup path resolution logic.
  • Ensure CODEX_CLI_PATH is consistently respected on Windows.
  • Provide a clearer error message or repair guidance when the bundled binary cannot be executed.

Thank you for investigating this Windows issue.

What is the expected behavior?

Expected behavior:

Codex Desktop should either:

  1. Correctly locate the bundled CLI binary automatically.

or

  1. Correctly respect CODEX_CLI_PATH during startup.

Additional information

_No response_

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 2 days ago

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

  • #40762
  • #40843
  • #40791
  • #40700
  • #40850

Powered by Codex Action

selfrestart · 1 day ago

I hit the exact same issue and want to add a second confirmed data point for the CODEX_CLI_PATH workaround.

Environment:

  • OS: Windows 11 x64 (NT 10.0.26200.0)
  • App: ChatGPT / Codex Desktop (MSIX, 26.820.x)
  • Standalone CLI: codex-cli 0.150.1, installed globally via npm (@openai/codex@0.150.1)

Symptoms:

  • Command line works fine (codex --version → codex-cli 0.150.1).
  • ChatGPT Desktop fails at startup with: "Unable to locate the Codex CLI binary. Set CODEX_CLI_PATH or ensure the Electron resources include bin/codex."
  • The npm-installed binary lives at:

D:\Node.js\node_global\node_modules\@openai\codex\node_modules\@openai\codex-win32-x64\vendor\x86_64-pc-windows-msvc\bin\codex.exe

Workaround confirmed:
Setting the user environment variable:
CODEX_CLI_PATH=D:\Node.js\node_global\node_modules\@openai\codex\node_modules\@openai\codex-win32-x64\vendor\x86_64-pc-windows-msvc\bin\codex.exe
then fully quitting and relaunching ChatGPT Desktop fixed the issue. So this workaround is reproducible by more than one user.

Additional observation (possible release pipeline issue):
While debugging, I also found that @openai/codex@0.150.1 on npm initially declared npm:@openai/codex@0.150.1-win32-x64 in its optionalDependencies, but that version was missing from the registry (404) — the win32-x64 dist-tag only pointed to 0.150.0-win32-x64. It was published shortly after, and reinstalling (npm install -g @openai/codex@latest --include=optional) then installed the native binary correctly. Worth double-checking that platform packages always ship together with the main package.

The bundled-binary relocation bug still needs a proper fix, but this workaround is solid in the meantime. Thanks for the report!