Regression: Codex desktop shell cannot attach to WSL2 distros while normal PowerShell can

Open 💬 2 comments Opened Apr 30, 2026 by initiatione
💡 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 (From “About Codex” dialog)?

26.426.12240

What subscription do you have?

ChatGPT Plus / Codex desktop app user

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

Codex desktop on Windows can run wsl.exe --list --verbose, but any attempt to execute a command inside a WSL2 distribution fails with Wsl/Service/0x8007072c. The exact same command succeeds from a normal PowerShell session outside Codex.

This prevents Codex from directly working inside a project-specific WSL2 Ubuntu environment.

This appears to be a regression: several earlier Codex desktop versions on the same machine were able to run WSL commands successfully from the Codex shell tool.

Environment:

  • OS: Windows 11
  • WSL version: 2.6.3.0
  • WSL kernel: 6.6.87.2-1
  • WSLg: 1.0.71
  • Windows version reported by wsl --version: 10.0.26200.8246
  • Shell used by Codex tool process: PowerShell 7 (pwsh.exe)
  • Codex process integrity level after retest: Medium Mandatory Level
  • Target distro: BlueROV2-ROS2
  • Target distro OS: Ubuntu 24.04.4 LTS
  • Target distro state: Running

Inside Codex shell tool, wsl.exe --list --verbose works and shows the distros, but executing commands inside any distro fails:

C:\Windows\System32\wsl.exe -d BlueROV2-ROS2 -- echo ok

returns:

Wsl/Service/0x8007072c

The same failure also occurs for other distros:

C:\Windows\System32\wsl.exe -d Ubuntu-OpenClaw -- echo ok
C:\Windows\System32\wsl.exe -d agents-wsl -- echo ok

Outside Codex, in normal PowerShell, the same command succeeds:

C:\Windows\System32\wsl.exe -d BlueROV2-ROS2 -- echo ok

Output:

ok

The target distro is also usable interactively through Windows Terminal. Inside WSL:

whoami
cat /etc/os-release | head
node --version
npm --version
which node
which npm

Output includes:

liuchf
PRETTY_NAME="Ubuntu 24.04.4 LTS"
v25.9.0
11.12.1
/home/liuchf/.nvm/versions/node/v25.9.0/bin/node
/home/liuchf/.nvm/versions/node/v25.9.0/bin/npm

What steps can reproduce the bug?

  1. On Windows, have a working WSL2 distro. In my case: BlueROV2-ROS2 running Ubuntu 24.04.4 LTS.
  2. Verify the command works outside Codex in normal PowerShell:
C:\Windows\System32\wsl.exe -d BlueROV2-ROS2 -- echo ok

Expected and observed outside Codex:

ok
  1. In Codex desktop shell tool, run:
C:\Windows\System32\wsl.exe --list --verbose

This works and lists the distros.

  1. In Codex desktop shell tool, run:
C:\Windows\System32\wsl.exe -d BlueROV2-ROS2 -- echo ok

Observed inside Codex:

Wsl/Service/0x8007072c

Troubleshooting already performed:

  • Confirmed wsl.exe resolves to C:\Windows\System32\wsl.exe.
  • Confirmed the same command works outside Codex.
  • Retested Codex running at normal user integrity level, not administrator:
Mandatory Label\Medium Mandatory Level
  • Tried full path to wsl.exe.
  • Tried cmd /c.
  • Tried a clean environment with PATH limited to Windows system directories.
  • Tried --cd ~.
  • Tried target user and root user.
  • Tried multiple distros, not just BlueROV2-ROS2.
  • Terminated the target distro and retried cold start.
  • Restarted WSL service from an administrator shell.
  • Restarted Codex / switched Codex from elevated to normal run mode.

The issue persists only from the Codex shell tool process.

What is the expected behavior?

Codex should be able to run WSL commands the same way normal PowerShell can. For example:

C:\Windows\System32\wsl.exe -d BlueROV2-ROS2 -- echo ok

should return:

ok

This worked in previous Codex desktop versions on the same machine.

Additional information

_No response_

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 3 months ago

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

  • #20472

Powered by Codex Action

Cragsworth · 3 months ago

I’m seeing what looks like the same regression on Codex Desktop for Windows.

Environment:

  • Codex app version: 26.429.3425.0
  • Windows package: OpenAI.Codex_26.429.3425.0_x64__2p2nqsd0c76g0
  • Windows: 10.0.26200
  • WSL distro: Ubuntu, WSL2, default distro
  • WSL kernel observed from inside distro: 6.6.87.2-microsoft-standard-WSL2
  • Repo tested in native WSL filesystem: /home/craig/code/Trustek.SitePak2

Manual WSL invocation from Windows succeeds:

C:\Windows\System32\wsl.exe -d Ubuntu --cd /home/craig/code/Trustek.SitePak2 --exec git rev-parse --show-toplevel

Output:

/home/craig/code/Trustek.SitePak2

The same repo is valid from inside WSL:

git -C /home/craig/code/Trustek.SitePak2 rev-parse --show-toplevel

Output:

/home/craig/code/Trustek.SitePak2

But Codex Desktop with WSL mode enabled cannot load local environment settings / resolve the git root. The user-facing UI says:

Local environments unavailable
We could not load local environment settings for this project.

Relevant Codex Desktop logs show repeated failures like:

[spawn-async] Spawning process inside WSL
[git] git.command.complete command="git rev-parse --show-toplevel" cwd=/home/craig/code/Trustek.SitePak2 failureReason=spawnFailed
[electron-message-handler] worker_rpc_response_error errorMessage="Failed to resolve git root: WSL mode is enabled but no eligible distro is available" method=stable-metadata workerId=git

This also happened when opening via both UNC styles:

\\wsl.localhost\Ubuntu\home\craig\code\Trustek.SitePak2
\\wsl$\Ubuntu\home\craig\code\Trustek.SitePak2

The error appears misleading here because an eligible distro exists and direct Windows -> WSL -> git execution works. The failure seems isolated to Codex Desktop’s WSL spawn path / git worker.