›_ Codex Issues
Codex Issues / #21147

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

Open 💬 4 comments Opened May 5, 2026 by jka-wfa-wll
💡 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?

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 ↗

4 Comments

github-actions[bot] contributor · 3 months ago

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

  • #20415

Powered by Codex Action

jka-wfa-wll · 3 months ago

The duplicate detector suggested #20415. I reviewed it and it looks related but not identical:

  • #20415 is specifically about Desktop automations failing/stalling for WSL workspaces.
  • This issue reproduces in a normal fresh interactive local thread, without automations.
  • The shared underlying symptom may be WSL workspace path/runner selection, but here the process tree shows Desktop launching through wsl.exe and then executing the Windows app-server from /mnt/c/.../codex.exe, after which the thread reports shell=powershell and an invalid Windows cwd.

Happy to close/consolidate if maintainers prefer tracking all WSL Desktop runner dispatch issues in #20415, but I’m leaving this open for now because the interactive-thread repro is narrower and does not require automations.

jka-wfa-wll · 3 months ago

Adding a link back to the proposed root-cause/fix described in #20415 by @m13v:

resolve canonical path once at registration, store both representations, let each layer pick the one matching its context

That seems highly applicable to this interactive-thread repro as well. In this case the persisted workspace root is WSL/UNC, but the launched runtime crosses namespaces:

  • Desktop host process is Windows.
  • It launches through wsl.exe -d Ubuntu.
  • Inside that WSL launch, it executes the Windows app-server from /mnt/c/.../codex.exe.
  • The resulting thread receives/reports shell=powershell and cwd=C:\home\<user>\<workspace> instead of /home/<user>/<workspace>.

So this looks like the same class of bug: different layers are resolving the same workspace through different path namespaces, and the selected shell/runtime follows the Windows app-server rather than the WSL workspace context.

Elpisote · 2 months ago

I can reproduce this exact issue on the current Codex Desktop for Windows release.

Environment:

  • Codex Desktop: 26.609.4994.0
  • Codex CLI/app-server metadata: 0.139.0
  • Windows 11 + Ubuntu WSL2 (Ubuntu is running and is the default distro)
  • Project: /home/eva/projects/patte-plus-v2, opened in Desktop as \\wsl$\Ubuntu\home\eva\projects\patte-plus-v2

Desktop configuration is correct:

[desktop]
runCodexInWindowsSubsystemForLinux = true
integratedTerminalShell = "wsl"

[desktop.open-in-target-preferences]
global = "wsl"

However, a newly created thread gets this session metadata:

shell=powershell
cwd=C:\home\eva\projects\patte-plus-v2

Commands fail immediately because that Windows path does not exist. Explicit execution works correctly:

wsl.exe -d Ubuntu --cd /home/eva/projects/patte-plus-v2 sh -lc 'pwd; echo $WSL_DISTRO_NAME; git rev-parse --show-toplevel'

returns:

/home/eva/projects/patte-plus-v2
Ubuntu
/home/eva/projects/patte-plus-v2

Desktop logs repeatedly say Spawning process inside WSL, but the thread still receives PowerShell and the malformed Windows cwd. The logs also show:

Failed to watch workspace root for git init cwd=C:\home\eva\projects\patte-plus-v2 errorCode=ENOENT

An invalid project entry is generated automatically:

[projects.'c:\home\eva\projects\patte-plus-v2']
trust_level = "trusted"

Removing it does not fix the issue; Desktop recreates it when a new thread is launched.

This makes the Windows Desktop app unreliable for WSL-native projects even though WSL itself and the repository are healthy. The practical workaround is using the Codex CLI directly inside WSL or explicitly wrapping every command with wsl.exe.