Codex Desktop fails to run any command in WSL workspace despite Agent Environment set to WSL

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

Codex Desktop on Windows fails to execute any command in a WSL workspace, even though the app settings are configured to use Windows Subsystem for Linux as the agent environment and WSL as the integrated terminal shell. The failure occurs before any command can run, with: No such file or directory (os error 2) This appears to be a runtime/workspace mapping issue where the workspace is opened through a WSL UNC path such as: \\wsl.localhost\Ubuntu-22.04\home\... but the Codex execution layer attempts to invoke Linux shells such as /bin/bash or /bin/sh. As a result, no shell command can be executed.

What subscription do you have?

gpt plus

What platform is your computer?

OS: Windows [10/11], version [fill in] Codex Desktop version: [fill in] WSL version: [fill in from wsl --version] WSL distro: Ubuntu-22.04 Project location: /home/kim-yj/... inside WSL Codex setting: Agent Environment: Windows Subsystem for Linux Integrated Terminal Shell: WSL The same issue occurs even in a fresh test directory inside WSL.

What issue are you seeing?

Codex Desktop fails to execute any command in a WSL workspace even though the Agent Environment is set to Windows Subsystem for Linux and the integrated terminal shell is set to WSL.

When opening a WSL project, the workspace appears to be mapped as a Windows UNC path such as \\wsl.localhost\Ubuntu-22.04\home\..., but the execution layer tries to invoke Linux shells like /bin/bash or /bin/sh. The command fails before anything can run with:

No such file or directory (os error 2)

This happens even in a fresh minimal WSL test directory, so it does not appear to be project-specific.

What steps can reproduce the bug?

Open Codex Desktop on Windows.
Set:
Agent Environment = Windows Subsystem for Linux
Integrated Terminal Shell = WSL
Create a fresh test directory in WSL:
mkdir -p ~/codex_test_wsl
cd ~/codex_test_wsl
echo "# Codex WSL test" > README.md
Open this folder in Codex Desktop via the WSL path, for example:
\\wsl$\Ubuntu-22.04\home\kim-yj\codex_test_wsl
Start a new Codex session and ask it to run a minimal environment check:
Run one environment check only. Do not modify files.

pwd
uname -a
which bash
echo "$SHELL"

What is the expected behavior?

Codex should start the agent inside WSL and execute commands normally.

Expected output should show a Linux path such as:

/home/kim-yj/codex_test_wsl
Linux ...
/usr/bin/bash
/bin/bash

------------------------
<Actual Behavior>

The environment check fails before any command can run:

The single environment check failed before any command could run:

No such file or directory (os error 2)

Codex then reports that the runtime/workspace mapping appears broken.

This happens even with a fresh WSL test directory, so it does not appear to be caused by the original project files.

Additional information

Additional Observations

The issue looks like Codex Desktop is displaying WSL as the selected agent environment in the UI, but the actual workspace/runtime binding still appears to be inconsistent.

The problematic state seems to be:

UI setting: WSL
Workspace path: \\wsl.localhost\Ubuntu-22.04\home\...
Execution shell attempted: /bin/bash or /bin/sh
Result: No such file or directory (os error 2)

If the Codex agent were truly running inside WSL, the working directory should likely appear as:

/home/kim-yj/...

rather than a Windows UNC path.

Troubleshooting Already Tried
Confirmed that Agent Environment is set to Windows Subsystem for Linux.
Confirmed that Integrated Terminal Shell is set to WSL.
Tried a fresh minimal WSL test folder.
Asked Codex to run only one minimal environment check.
The failure still occurs before any command can run.
Repeated shell retries with /bin/bash, /bin/sh, PowerShell, or wsl.exe do not help, because the failure appears to happen at the runtime/workspace mapping layer.
Impact

This makes Codex Desktop unusable for projects stored inside WSL, even when the app is configured to use WSL. The only current workaround is to either:

Run Codex CLI directly inside WSL, or
Move/copy the project to a Windows-native path and use the Windows-native agent.

However, this breaks the intended WSL workflow for Linux-native development environments.