›_ Codex Issues
Codex Issues / #28103

[Bug] Codex desktop 26.609.4994.0 (MSIX) missing Linux codex binary in app/resources — breaks "Run agent in WSL"

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

[Bug] Codex desktop app 26.609.4994.0 (MSIX) is missing the Linux codex binary in app/resources, breaking "Run agent in WSL"

Summary

On the Microsoft Store / MSIX build of the Codex desktop app, enabling Run agent in WSL fails immediately with:

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

The root cause is that the app's bundled-executable relocation step tries to stat a Linux codex binary at ...\app\resources\codex, but that file does not exist in the installed package — only the Windows codex.exe is shipped. As a result the relocation to C:\Users\<user>\.codex\bin\wsl\codex never happens and the app server transport fails to connect.

The app works fine in native Windows mode (using codex.exe); only WSL mode is broken.

Environment

  • Codex desktop app version: 26.609.4994.0 (x64, Microsoft Store / SignatureKind: Store)
  • Package: OpenAI.Codex_26.609.4994.0_x64__2p2nqsd0c76g0
  • OS: Windows 11
  • WSL: WSL2, distro Ubuntu-24.04 (default, Running), kernel 6.6.87.2-microsoft-standard-WSL2

Steps to reproduce

  1. Install the Codex desktop app from the Microsoft Store (version 26.609.4994.0).
  2. In settings, enable Run agent in WSL.
  3. Restart the app.

Expected

The app relocates the bundled Linux codex binary into ~/.codex/bin/wsl/codex and starts the app server inside WSL.

Actual

The app fails to connect with "Unable to locate the Codex CLI binary…". The relocation step throws ENOENT because the source file is missing from the package.

Evidence (from app logs)

Log path: %LOCALAPPDATA%\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\...\codex-desktop-*.log

warning bundled_executable_relocation_failed
  destinationPath=C:\Users\<user>\.codex\bin\wsl\codex
  errorCode=ENOENT
  errorMessage="Bundled executable relocation failed during stat_source"
  errorName=BundledExecutableRelocationError
  executableName=codex
  operation=stat_source
  originalError={"errno":-4058,"code":"ENOENT","syscall":"stat",
    "path":"C:\\Program Files\\WindowsApps\\OpenAI.Codex_26.609.4994.0_x64__2p2nqsd0c76g0\\app\\resources\\codex"}
  platform=win32
  sourceKind=windowsapps
  sourcePath="C:\\...\\app\\resources\\codex"

warning [AppServerConnection] app_server_connection.transport_connect_failed
  errorMessage="Unable to locate the Codex CLI binary. Set CODEX_CLI_PATH or ensure the Electron resources include bin/codex."

error [AppServerConnection] fatal_error_broadcasted
  errorMessage="Unable to locate the Codex CLI binary. ..."

Note operation=stat_source: the failure is on the source file, before any copy is attempted.

Confirmation that the source file is genuinely missing

Listing C:\Program Files\WindowsApps\OpenAI.Codex_26.609.4994.0_x64__2p2nqsd0c76g0\app\resources\:

codex-command-runner.exe
codex-notification.wav
codex-windows-sandbox-setup.exe
codex.exe          <-- Windows binary present
                   <-- no extension-less "codex" (Linux ELF) present

So the packaging shipped only the Windows codex.exe and omitted the Linux codex binary that WSL mode requires.

Workarounds attempted (and why they don't help)

  • Installing a system Node + global @openai/codex in WSL, and having codex on PATH in WSL — no effect, because the app does not look up codex via the WSL PATH; it relocates its own bundled binary.
  • Pre-placing a valid Linux codex ELF at the relocation destination (C:\Users\<user>\.codex\bin\wsl\codex) — no effect, because relocation fails at stat_source (the source) before it ever checks the destination.
  • Placing the binary at the source path under C:\Program Files\WindowsApps\...\app\resources\ is not possible (TrustedInstaller-owned, read-only, and would break the package signature).

The only working fallback is to disable WSL mode and run in native Windows mode.

Suggested fix

Include the Linux codex binary in app/resources for the Windows MSIX build (it appears to have been dropped in 26.609.4994.0; an earlier build such as 26.601.x reportedly worked), or make the relocation tolerate a pre-existing valid destination binary instead of hard-failing on a missing source.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 1 month ago

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

  • #28086
  • #28074

Powered by Codex Action

qiyueqiu · 1 month ago

Related issues that appear to share the same root cause or area:

  • #28086 — Windows app WSL agent mode fails to find bundled CLI (and may launch Windows codex.exe via CODEX_CLI_PATH). Same WSL-mode failure, complementary angle.
  • #27566 — Same Windows bundled runtime relocation failure (bundled_executable_relocation_failed).
  • #27979 — Same app version 26.609.4994.0 no longer opens after update.
  • #22423 — Original "Unable to locate the Codex CLI binary" report.

Possibly the same class of WindowsApps relocation/copy problem (different trigger): #25220 (EFS-encrypted files), #28031 (access denied executing bundled codex.exe), #22672 (non-standard drive).

In this issue specifically the failure is operation=stat_source on a missing source (app\resources\codex Linux binary absent from the package), which points to a packaging omission rather than a permission/encryption issue.

Jafa7 · 1 month ago

I can confirm that this issue also affects Codex Desktop version 26.609.41114.

Environment:

  • Codex Desktop: 26.609.41114 (released June 12, 2026)
  • Windows: 10.0.26200.8655
  • WSL: 2.7.8.0
  • WSL kernel: 6.18.33.1-1
  • Distribution: Ubuntu
  • Codex CLI inside WSL: 0.139.0
  • CLI path: /home/user/.local/bin/codex

The CLI works correctly when launched directly inside WSL, including codex app-server --help, but enabling “Run agent in WSL” causes Codex Desktop to fail with:

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

Setting CODEX_CLI_PATH to either the Linux path or the corresponding \\wsl.localhost UNC path does not resolve the issue. Removing the variable allows Codex Desktop to start again in native Windows mode.

This confirms that the issue is not limited to version 26.609.4994.0.

<img width="696" height="207" alt="Image" src="https://github.com/user-attachments/assets/ca174f55-6edc-497d-899b-c99ac0a6ab42" />

JorgeMantillaHernandez · 1 month ago

I’m seeing the same issue.

I installed the Codex Windows app normally from the Microsoft Store. It was working in the default Windows native mode. Then I changed the agent environment to use WSL, restarted Codex, and after that the app failed to start with this error:

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

My app is installed on the C: drive:

OpenAI.Codex_26.609.4994.0_x64__2p2nqsd0c76g0
C:\Program Files\WindowsApps\OpenAI.Codex_26.609.4994.0_x64__2p2nqsd0c76g0

I was able to recover by manually editing:

C:\Users\<user>\.codex\config.toml

and changing:

runCodexInWindowsSubsystemForLinux = false
integratedTerminalShell = "powershell"

So this looks like the WSL mode startup path is broken in this build.

<img width="585" height="188" alt="Image" src="https://github.com/user-attachments/assets/87676adb-fe2a-4c21-8117-175dbd4f28ca" />

shuncleopasfang · 1 month ago

https://github.com/openai/codex/issues/28212#issuecomment-4703996879

The workaround that worked for me was to point CODEX_CLI_PATH to the Desktop-managed WSL cached Codex binary.

LeventAksakal · 1 month ago

Additional reproduction: WSL mode breaks after switching default distro to opp_env

I hit what appears to be the same Windows Codex Desktop WSL-mode failure.

Environment

  • Windows Codex Desktop app from Microsoft Store / MSIX
  • Codex CLI on Windows: codex-cli 0.139.0
  • Windows CLI path:

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

  • WSL2 installed
  • Initially default distro was Ubuntu
  • Target distro for work: opp_env
  • Project type: OMNeT++ project that must run inside opp_env

What happened

  1. Codex Desktop was configured to use WSL mode.
  2. First WSL launch worked while the default WSL distro was Ubuntu.
  3. I shut down WSL.
  4. I changed the default WSL distro to opp_env.
  5. After restarting Codex Desktop, the app failed to start with:
Codex failed to start.
Unable to locate the Codex CLI binary.
Set CODEX_CLI_PATH or ensure the Electron resources include bin/codex.

In one failure mode, the app appeared to invoke bash and try to run a Windows path from inside WSL:

/usr/bin/bash: line 1: /mnt/c/Users/levent/AppData/Local/.../codex.exe: No such file or directory

This is wrong in two ways:

  • The actual Windows user path is C:\Users\leven, not C:\Users\levent.
  • In WSL agent mode, the app should not depend on a Windows codex.exe path.

Diagnostics

Windows CLI works:

where.exe codex
codex --version

Output:

C:\Users\leven\AppData\Local\Programs\OpenAI\Codex\bin\codex.exe
codex-cli 0.139.0

The app only recovered after forcing Windows-native mode in %USERPROFILE%\.codex\config.toml by changing 

integratedTerminalShell = "wsl"
runCodexInWindowsSubsystemForLinux = true

into

runCodexInWindowsSubsystemForLinux = false
integratedTerminalShell = "powershell"

Expected behavior

Codex Desktop WSL mode should either:

  • reliably use the selected/default WSL distro after restart,
  • provide a documented setting for the WSL distro name,
  • use the native Linux codex available inside that distro,
  • or fail with a clear recovery path, fail-back into windows native or other environments when launching one fails.

Actual behavior

Switching to WSL mode can make the desktop app unable to launch at all. Recovery requires manually editing config/state files to force PowerShell/native mode.

Impact

This blocks real Linux-native workflows such as OMNeT++ projects that need a specific WSL distro/environment. Using Windows-native mode is not a valid replacement for these projects.