WSL agent mode fails when creating a new chat with AbsolutePathBuf deserialized without a base path

What version of Codex CLI is running?

Environment: - Windows desktop app version: 26.820.7780.0 - Windows: 11, build 26200.9168 - WSL version: 2.7.12.0 - Default distro: Ubuntu-24.04 - Default WSL version: 2 - Codex CLI: 0.149.1 - Installation: Microsoft Store package

What subscription do you have?

chatgpt plus

Which model were you using?

_No response_

What platform is your computer?

_No response_

What terminal emulator and version are you using (if applicable)?

_No response_

Codex doctor report

What issue are you seeing?

Description

Environment:

• Windows desktop app version: 26.820.7780.0
• Windows: 11, build 26200.9168
• WSL version: 2.7.12.0
• Default distro: Ubuntu-24.04
• Default WSL version: 2
• Codex CLI: 0.149.1
• Installation: Microsoft Store package

WSL works correctly outside Codex:

• wsl --status succeeds
• wsl -l -v shows Ubuntu-24.04 as Running

Codex configuration:
[desktop]
runCodexInWindowsSubsystemForLinux = true
integratedTerminalShell = "wsl"

Reproduction:

1. Enable WSL as the Codex agent environment.
2. Restart the ChatGPT/Codex desktop app.
3. Create a new chat.

Actual behavior:
The desktop app starts and launches Ubuntu-24.04, but creating a new chat fails with:

"Invalid request: AbsolutePathBuf deserialized without a base path"

Earlier, when CODEX_CLI_PATH was not configured, the app also showed:

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

After setting CODEX_CLI_PATH to the Windows native codex.exe, the app can start, but WSL agent mode still fails when creating a chat.

The process command line shows mixed Windows and WSL paths. The WSL app-server is launched through Ubuntu-24.04, but uses a Windows codex.exe under /mnt/c/..., while the working directory is mapped under /mnt/d/....

Expected behavior:
The Codex desktop app should create a new chat successfully with the agent running inside Ubuntu-24.04/WSL2.

Workaround:
Using Windows-native agent mode works:
runCodexInWindowsSubsystemForLinux = false
integratedTerminalShell = "powershell"

What steps can reproduce the bug?

Uploaded thread: 01a03c28-7a0c-7ee1-9a7f-960dd53303ac

What is the expected behavior?

_No response_

Additional information

_No response_