Windows Codex cannot start when WSL mode is enabled (terminalShell=wsl)

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

• #13565
• #13588
• #13658
• #13699
• #13693

Powered by Codex Action

The error suggests that /usr/bin/bash is missing in your current environment. You can easily verify if it exists by running ls -l /usr/bin/bash or which bash inside your WSL terminal. Are you currently using Ubuntu as your default WSL distribution, or a minimal one like Alpine?

The error suggests that /usr/bin/bash is missing in your current environment. You can easily verify if it exists by running ls -l /usr/bin/bash or which bash inside your WSL terminal. Are you currently using Ubuntu as your default WSL distribution, or a minimal one like Alpine?

Thanks for the reply.

My WSL environment itself is working normally. Before Codex for Windows was released, WSL was actually my main development environment, and I used Codex CLI there regularly without any issues.

The problem only appears with the Codex Windows desktop app when both of these settings are enabled:

runCodexInWindowsSubsystemForLinux = true
integratedTerminalShell = "wsl"

My normal WSL development workflow (Node, pnpm, etc.) works fine outside of Codex.

I had that problem and found out my default wsl was docker desktop. I changed it to Ubuntu and was able to run Codex.

I had that problem and found out my default wsl was docker desktop. I changed it to Ubuntu and was able to run Codex.

Thanks for the suggestion — that was exactly the issue.

My default WSL distro was docker-desktop. After switching the default distro to my actual development environment (aimuo, which is Ubuntu), Codex now starts correctly with WSL mode enabled.

So it seems Codex currently relies on the default WSL distro when launching.

➜ ~ wsl -l -v
  NAME              STATE           VERSION
* docker-desktop    Stopped         2
  aimuo             Running         2
➜ ~ wsl --set-default aimuo
操作成功完成。
➜ ~ wsl -l -v
  NAME              STATE           VERSION
* aimuo             Running         2
  docker-desktop    Stopped         2

<img width="770" height="840" alt="Image" src="https://github.com/user-attachments/assets/df2fe68c-0bca-4219-9ba2-2dd30c31ba20" />

I'm also getting this issue but the issue for me is not WSL defaulting to Docker Desktop, it's that my WSL distro (NixOS) actually doesn't have bash at the system level, only zsh.

It would be great if Codex on Windows through WSL could work with any bash-compatible shell.

Same bug: there is only one WSL system, and setting it as default still fails to start.
Currently, as long as "runCodexInWindowsSubsystemForLinux": true, the Codex app cannot be launched at all. Since the app won’t start, I can only access it by modifying the JSON file.

The fundamental bug is that the Codex Windows app cannot be configured to run the agent in WSL2.

same

Another confirmed reproduction on the Windows desktop app with a newer Store build.

Environment:

• Codex app package path observed from the running process:

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

• OS:

Windows 10 Pro 25H2, build 26200.8246, x64

User-visible error popup:

• An error has occurred
• Codex crashed with the following error:
• (code=4294967295, signal=null)
• Most recent error: None

What makes this look like the same root cause as #14461:

1. The persisted desktop state still has WSL enabled:

• ~/.codex/.codex-global-state.json
• "runCodexInWindowsSubsystemForLinux": true
• "integratedTerminalShell": "wsl"

1. The desktop app log shows the app-server being launched via WSL, not a native Windows transport:

• package-local log path:

C:\Users\agust\AppData\Local\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\2026\04\16\...

• representative lines:
• stdio_transport_spawned argsCount=2 executablePath=C:\Users\agust\.codex\bin\wsl\codex pid=25392 spawnCommand=wsl.exe
• then repeated parse failures because the app receives non-JSON UTF-16 WSL error text on stdio

1. The actual text being parsed is a WSL error, not MCP JSON. Log excerpts:

• Failed to parse MCP message ... Unexpected token 'N' ... is not valid JSON
• line preview begins with UTF-16 Spanish text:

N\^@o\^@ \^@s\^@e\^@ \^@p\^@u\^@d\^@o\^@ ...

• another line preview contains:

Error code: Wsl/Service/CreateInstance/MountVhd/HCS/ERROR_PATH_NOT_FOUND

1. After that, the app-server closes with the same generic crash signature shown in the popup:

• app_server_connection.closed code=4294967295 ... signal=null
• Codex CLI process exited classifiedAsExpected=false code=4294967295 ... signal=null

This strongly suggests the desktop app is still entering the WSL startup path and then failing before the initialize handshake, with the UI surfacing only the generic 4294967295 / signal=null wrapper error.

In this repro, changing ~/.codex/config.toml sandbox settings did not change the crash behavior, which further points to persisted desktop WSL mode as the real trigger.

If useful, I can provide a larger sanitized excerpt from the package-local desktop log, but the key evidence above seems enough to tie this to the same WSL-enabled startup path discussed in this issue.

Edit:
Workaround confirmed

• App build (26.415.1938.0)
• Changed persisted flags:
• runCodexInWindowsSubsystemForLinux=false
• integratedTerminalShell="powershell"
• Result: app starts normally after full restart
• Note: workaround only; root cause still appears to be WSL startup path

Same issue here on Windows. Since WSL is the main reason I want to use the desktop app, this makes the app pretty hard to use reliably. Would really appreciate a fix.