Windows app WSL agent mode fails to find bundled CLI and may launch Windows codex.exe via CODEX_CLI_PATH

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

Component

Codex Desktop for Windows / WSL agent startup / app-server CLI resolution

Version / environment

  • Codex Desktop: 26.609.4994.0
  • CLI observed in WSL: codex-cli 0.139.0
  • Windows OS build: 10.0.26200
  • WSL: Ubuntu, WSL2, running
  • WSL has a native Linux Codex CLI available at /home/<wsl-user>/.local/bin/codex

Summary

Switching the Windows Codex app agent environment from Windows native to WSL should start the agent/app-server inside WSL without requiring a user-defined CODEX_CLI_PATH. Instead, I am seeing two failure modes:

  1. With CODEX_CLI_PATH unset, Codex Desktop fails to start in WSL agent mode.
  2. With CODEX_CLI_PATH set to a Windows codex.exe, Codex Desktop starts but appears to launch that Windows executable through WSL interop, producing a hybrid Windows session rather than a real WSL agent session.

This seems inconsistent with the Windows app docs, which say the agent can be switched from Windows native to WSL in Settings and then restarted: https://developers.openai.com/codex/windows

Expected behavior

After setting the agent environment to WSL and restarting the Windows app, Codex should start the WSL/Linux agent using either:

  • a Linux Codex CLI already available inside WSL, or
  • a correctly bundled/relocated Linux binary for WSL mode.

A normal user should not need to set CODEX_CLI_PATH for this mode switch.

Actual behavior

With the WSL agent setting enabled and CODEX_CLI_PATH removed, the app shows:

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

The desktop log contains this key line:

bundled_executable_relocation_failed destinationPath=C:\Users\<user>\.codex\bin\wsl\codex ... operation=stat_source ... sourcePath="C:\Program Files\WindowsApps\OpenAI.Codex_26.609.4994.0_x64__2p2nqsd0c76g0\app\resources\codex" ... ENOENT

On disk, the installed Windows app resources contain codex.exe, but not codex:

Test-Path ...\app\resources\codex      -> False
Test-Path ...\app\resources\codex.exe  -> True

When CODEX_CLI_PATH is restored and points to a Windows executable, WSL mode starts but the WSL process list shows the Windows CLI being launched through interop:

/init /mnt/c/Users/<user>/AppData/Local/Programs/OpenAI/Codex/bin/codex.exe ... app-server --analytics-default-enabled

The resulting session behaves like Windows native rather than WSL:

shell: powershell.exe
$PSVersionTable.PSEdition: Desktop
WSL_DISTRO_NAME: empty
Get-Location: C:\
workspace paths resemble C:\mnt\c\... rather than /mnt/c/...

Reproduction steps

  1. On Windows, ensure WSL2 Ubuntu is installed/running and has a native Linux codex available.
  2. Remove any user/global CODEX_CLI_PATH environment variable.
  3. In Codex Desktop settings, set the agent environment to WSL. This writes/uses the WSL agent mode setting (runCodexInWindowsSubsystemForLinux = true).
  4. Restart Codex Desktop.
  5. Observe the startup error above.
  6. Optionally set CODEX_CLI_PATH to a Windows codex.exe and restart.
  7. Observe that the app starts, but the app-server appears to be the Windows executable launched from WSL interop, producing a Windows-native/hybrid session.

Suspected cause

The WSL startup path on Windows appears to assume that the Electron/MSIX resources contain a Linux-style app/resources/codex binary and tries to relocate it to %USERPROFILE%\.codex\bin\wsl\codex. In this install, the resource present is app/resources/codex.exe only. Separately, when CODEX_CLI_PATH points at a Windows executable, WSL mode appears to use it without validating that it is a Linux executable, so WSL interop launches the Windows CLI instead of using the native WSL CLI.

Notes

View original on GitHub ↗

10 Comments

github-actions[bot] contributor · 1 month ago

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

  • #28074
  • #28031

Powered by Codex Action

AnhLead · 1 month ago

same issue started today

mamolli · 1 month ago

any fixes?

seanrichards · 1 month ago

Me too, same issue

AnhLead · 1 month ago

Downgrade codex to 3 lower version I used version from June 3rd . The new updates broke environment agent: wsl

ventayol · 1 month ago

Same here, OpenAI has a clear problem with Windows releases as they are not tested properly. In the last weeks the app broke multiple times.

william-kerr · 1 month ago
Same here, OpenAI has a clear problem with Windows releases as they are not tested properly. In the last weeks the app broke multiple times.

It's disappointing. If the makers of AI are shipping broken releases, then how can the rest of us non AI companies expect to rely on AI agents to ship working releases of our own...

cirino · 1 month ago

me too

<img width="581" height="183" alt="Image" src="https://github.com/user-attachments/assets/ed66a0d2-47e4-4678-8f93-4e50940475b7" />

deminden · 1 month ago

I am having the same issue

kangmingxuan · 22 days ago

Update from 26.623.5546.0 / codex-cli 0.142.3:

The original missing Linux app/resources/codex part appears partially fixed on my machine. WSL agent mode now starts with a Linux ELF codex, and CODEX_CLI_PATH is unset.

However, WSL agent mode still has separate follow-up problems around cwd/path translation and bundled Windows integration plugins (chrome, computer-use). I opened a more focused follow-up issue here: #30435