Codex Windows App failed to start after switching to WSL mode

Open 💬 2 comments Opened Aug 13, 2026 by bizuki

What version of the Codex App are you using (From “About Codex” dialog)?

26.803.10989.0

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Codex Desktop fails to start when WSL is selected as the execution environment.
<img width="344" height="135" alt="Image" src="https://github.com/user-attachments/assets/63e78903-2fd3-4e93-b8b3-69d4c4fc25fb" />

The WSL codex app-server process is successfully started by the Desktop application and remains running, but the initialization handshake times out.

Running the same app-server binary manually inside WSL works correctly.

The handshake also works when the app-server is launched manually from Windows through wsl.exe:

'{"method":"initialize","id":1,"params":{"clientInfo":{"name":"test","version":"1"}}}' |
wsl.exe -d Ubuntu -- <codex-binary> -c features.code_mode_host=true app-server --analytics-default-enabled

This successfully returns an initialization response.

So the problem only occurs when Codex Desktop launches and communicates with the app-server in WSL.

What steps can reproduce the bug?

Install Codex Desktop on Windows.
Select WSL/Ubuntu as the execution environment.
Restart/start Codex Desktop.
Wait for initialization.

What is the expected behavior?

It starts

Additional information

_No response_

View original on GitHub ↗

2 Comments

JoshuaSBrown · 14 days ago

I'm seeing this same behavior.

GH-LS2023 · 9 days ago

Additional diagnostics from a Windows 11 reproduction (posting sanitized data; no raw logs, usernames, keys, or absolute user paths):

Symptom and A/B result

In Codex Desktop WSL mode, the user-visible failure is code-mode host exited during handshake; the corresponding desktop log records Codex app-server initialize handshake timed out.
Repro flow: start with the WSL agent/runtime enabled, create a new task (or restart Codex), and make the first shell request. The initialization remains pending for about 30 seconds and then fails; no shell command is executed.
Rebooting Windows and creating a new task do not change the result.
Switching the same project/task to the PowerShell runtime makes shell execution work immediately.
The same WSL installation can execute Codex natively: wsl.exe -d Ubuntu-24.04 -- bash -lc 'codex exec --sandbox read-only "Run pwd using the shell tool and report only the exact output."' completed successfully and the code-mode shell returned the expected working directory.

Environment

Windows 11 build 26200.9168
Codex Desktop: 26.803.10989.0 in the captured failing log; current installed Desktop is 26.814.5167.0
WSL: 2.6.3.0; WSLg 1.0.71; WSL 2
Default distro: Ubuntu-24.04 (not docker-desktop)
WSL Codex CLI: 0.146.0

Environment-variable/config check

Windows process, user, and machine scopes: CODEX_HOME, CODEX_CLI_PATH, WSLENV, and WSL_DISTRO_NAME are unset.
Ubuntu-24.04 shell: CODEX_HOME, CODEX_CLI_PATH, and WSLENV are unset.
config.toml contains CODEX_HOME and CODEX_CLI_PATH only inside [mcp_servers.node_repl.env]; they are not global Windows environment variables. The configured CODEX_CLI_PATH points to the Windows Codex CLI, so it may be worth checking whether this MCP-scoped value is accidentally inherited by the WSL bridge.
The working fallback configuration is runCodexInWindowsSubsystemForLinux = false and integratedTerminalShell = "powershell"; the failing A/B changes the agent/runtime to WSL.
The captured log also warns that approvals_reviewer = User is disallowed by the installed requirements and falls back to AutoReview. This is a configuration-compatibility warning, but I cannot establish it as the root cause of the WSL handshake failure.

Relevant log excerpt (sanitized)

From the failing Desktop session on 26.803.10989.0:

stdio_transport_spawned ... codex.exe ...
selected app-server transport hostId=remote-ssh-discovered:wsl-codex
Initialize handshake still pending ... durationMs=30008
configured approvals_reviewer value User disallowed; fallback required AutoReview
Codex app-server initialize handshake timed out

The desktop logs therefore show that the local stdio process was spawned, then the WSL-discovered SSH app-server transport was selected, but initialization did not complete within 30 seconds. In the PowerShell A/B, local app-server initialization succeeds.

Additional isolation

Ubuntu contains an executable Linux-native codex-code-mode-host, and the native WSL codex exec shell test succeeds.
The WSL PATH exposes both the Linux-native Codex installation and a Windows/npm Codex entry. The Windows App resources also contain Windows and Linux variants of the code-mode-host basename. Please log the fully resolved executable path and platform for the code-mode host selected by the Desktop WSL bridge.

Related reports

This appears related to, but is not identical to, #39169 (WSL app-server initialize handshake timeout), #18506 (Windows/WSL bridge, CODEX_HOME and terminal boundary), #14461 (Windows WSL mode fails while PowerShell works), and #16815 (WSL path-boundary failure).

Expected behavior: the Desktop WSL agent should complete initialization and run the same shell request that succeeds in native WSL CLI and in the PowerShell A/B. Could the WSL bridge log (1) the selected transport, (2) the resolved codex and codex-code-mode-host paths/platforms, (3) the inherited environment after filtering, and (4) the first initialize response/error from the remote app-server instead of only reporting a generic handshake timeout?