Repository navigation
[Bug] Codex desktop 26.609.4994.0 (MSIX) missing Linux codex binary in app/resources — breaks "Run agent in WSL" #28103
Description
[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), kernel6.6.87.2-microsoft-standard-WSL2
Steps to reproduce
- Install the Codex desktop app from the Microsoft Store (version 26.609.4994.0).
- In settings, enable Run agent in WSL.
- 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/codexin WSL, and havingcodexon PATH in WSL — no effect, because the app does not look upcodexvia the WSLPATH; it relocates its own bundled binary. - Pre-placing a valid Linux
codexELF at the relocation destination (C:\Users\<user>\.codex\bin\wsl\codex) — no effect, because relocation fails atstat_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.
Activity
github-actions commentedon Jun 13, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
qiyueqiu commentedon Jun 13, 2026
Related issues that appear to share the same root cause or area:
codex.exeviaCODEX_CLI_PATH). Same WSL-mode failure, complementary angle.bundled_executable_relocation_failed).26.609.4994.0no longer opens after update.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_sourceon a missing source (app\resources\codexLinux binary absent from the package), which points to a packaging omission rather than a permission/encryption issue.Jafa7 commentedon Jun 13, 2026
I can confirm that this issue also affects Codex Desktop version 26.609.41114.
Environment:
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.
JorgeMantillaHernandez commentedon Jun 14, 2026
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.
shuncleopasfang commentedon Jun 15, 2026
#28212 (comment)
The workaround that worked for me was to point CODEX_CLI_PATH to the Desktop-managed WSL cached Codex binary.
LeventAksakal commentedon Jun 15, 2026
Additional reproduction: WSL mode breaks after switching default distro to
opp_envI hit what appears to be the same Windows Codex Desktop WSL-mode failure.
Environment
codex-cli 0.139.0C:\Users\leven\AppData\Local\Programs\OpenAI\Codex\bin\codex.exeopp_envopp_envWhat happened
opp_env.In one failure mode, the app appeared to invoke bash and try to run a Windows path from inside WSL:
This is wrong in two ways:
C:\Users\leven, notC:\Users\levent.codex.exepath.Diagnostics
Windows CLI works:
Output:
The app only recovered after forcing Windows-native mode in
%USERPROFILE%\.codex\config.tomlby changinginto
Expected behavior
Codex Desktop WSL mode should either:
codexavailable inside that distro,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.
guipmourao commentedon Aug 2, 2026
Confirming this also happens on a newer build and the same workaround fixed it for me.
App failed to start with:
ChatGPT failed to start.
(code=2, signal=null).
Most recent error: /usr/bin/bash: -c: line 1: unexpected EOF while looking for matching `"'
Same fix as above worked: edited %USERPROFILE%.codex\config.toml and set
[desktop]
integratedTerminalShell = "powershell"
runCodexInWindowsSubsystemForLinux = false
then restarted. App now starts fine in native Windows mode. Confirms this is still broken on a build several releases newer than the one originally reported here.