Codex Desktop WSL mode starts Windows app-server and leaves thread in PowerShell

Open 💬 4 comments Opened May 5, 2026 by jka-wfa-wll

What version of the Codex App are you using?

Codex Desktop for Windows 26.429.3425.0 from Microsoft Store path observed in process tree:

C:\Program Files\WindowsApps\OpenAI.Codex_26.429.3425.0_x64__2p2nqsd0c76g0\app\Codex.exe

The app-server reports:

currentVersion=0.125.0-alpha.3

The WSL-installed CLI reports:

codex-cli 0.128.0

Platform

Windows 11 x64 with WSL2 Ubuntu.

What issue are you seeing?

Codex Desktop is configured for WSL, and the persisted app state shows WSL mode enabled:

"runCodexInWindowsSubsystemForLinux": true,
"integratedTerminalShell": "wsl",
"electron-saved-workspace-roots": ["\\\\wsl.localhost\\Ubuntu\\home\\<user>\\<workspace>"],
"active-workspace-roots": ["\\\\wsl.localhost\\Ubuntu\\home\\<user>\\<workspace>"]

However, new threads still start with a Windows runner:

shell=powershell
cwd=C:\home\<user>\<workspace>

That cwd is invalid from Windows, so basic commands fail before any repo work can begin.

The process tree suggests Desktop launches through WSL but then executes the Windows Codex app-server from /mnt/c, which appears to make the agent runtime Windows/PowerShell rather than a true Linux/WSL runner:

wsl.exe -d Ubuntu --cd "/mnt/c/Program Files/WindowsApps/OpenAI.Codex_26.429.3425.0_x64__2p2nqsd0c76g0/app/resources" -- /usr/bin/bash -lc "... exec /mnt/c/Users/<windows-user>/AppData/Local/OpenAI/Codex/bin/codex.exe app-server --analytics-default-enabled"

codex.exe app-server --analytics-default-enabled
powershell.exe child of codex.exe

So the app seems to use WSL as a launch wrapper, but the actual app-server/command execution path remains Windows-side.

WSL itself works

Explicit WSL invocation succeeds and reaches the intended repo:

wsl.exe -d Ubuntu -- bash -lc 'cd /home/<user>/<workspace> && pwd && uname -a && git rev-parse --show-toplevel && command -v codex && codex --version && command -v node && node --version'

/home/<user>/<workspace>
Linux <host> 6.6.87.2-microsoft-standard-WSL2 #1 SMP PREEMPT_DYNAMIC Thu Jun  5 18:30:46 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
/home/<user>/<workspace>
/usr/local/bin/codex
codex-cli 0.128.0
/usr/bin/node
v18.19.1

Attempts already tried

  • Fully quit/restarted Codex Desktop and opened a fresh thread from the WSL workspace.
  • Verified WSL settings persisted in .codex-global-state.json.
  • Removed stale project trust entries for invalid Windows aliases such as c:\home\<user>\<workspace>, /mnt/d/..., and c:\mnt\d\....
  • Reset saved/active workspace roots to the WSL UNC path only.
  • Confirmed Codex Desktop rewrites the invalid Windows project entry on relaunch:
[projects.'c:\home\<user>\<workspace>']
trust_level = "trusted"

Expected behavior

When WSL mode is enabled and a WSL workspace is selected, new local threads should use a Linux/WSL runner:

shell=bash or equivalent Linux shell
cwd=/home/<user>/<workspace>
pwd -> /home/<user>/<workspace>
uname -a -> Linux ...
git rev-parse --show-toplevel -> /home/<user>/<workspace>

Actual behavior

New local threads still use:

shell=powershell
cwd=C:\home\<user>\<workspace>

The cwd is invalid, and the spawned app-server path indicates the Windows codex.exe is being launched from inside WSL rather than a Linux app-server being used.

Related issue

Possibly related but not the same as #20415. That issue reports automation failures/stalls for WSL workspaces. In this case, the repro is a normal interactive fresh local thread, without automations.

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗