Windows Desktop + WSL workspace: unified_exec tries to CreateProcess /bin/bash and fails with ENOENT

[MisterRound]

What version of Codex is running?

Codex Desktop / CLI observed in local diagnostics:

• codex-cli 0.130.0-alpha.5
• Windows 11 host
• WSL2 Ubuntu workspace

What subscription do you have?

Pro

Which model were you using?

GPT-5.5

What platform is your computer?

Hybrid Windows Desktop + WSL2 setup:

• WSL distro: Ubuntu
• WSL kernel observed in smoke test: Linux BOOK-*** 6.6.87.2-microsoft-standard-WSL2 #1 SMP PREEMPT_DYNAMIC Thu Jun 5 18:30:46 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

What issue are you seeing?

In Codex Desktop with a WSL-backed workspace, normal shell/tool calls can fail before the command starts when [features].unified_exec = true.

The failing tool call tries to launch a Linux shell path directly through the Windows-backed process creation path:

/bin/bash -lc ...

The observed error from normal Codex tool calls is:

CreateProcess { message: "Rejected(\"Failed to create unified exec process: No such file or directory (os error 2)\")" }

This is misleading because /bin/bash exists and works in WSL. The failure appears to be that the Windows-side unified exec runner is attempting to CreateProcess a WSL/Linux absolute path instead of routing it through WSL.

Steps to reproduce

Local repro conditions:

1. Use Codex Desktop on Windows 11.
2. Open a WSL-backed workspace under /mnt/c/....
3. Configure Codex with:

[features]
unified_exec = true
shell_snapshot = true

4. Start a session where the shell is WSL bash and the workspace path is /mnt/c/....
5. Run a normal shell/tool command such as pwd, uname -a, or ls -l /bin/bash /usr/bin/bash.

Observed in the active thread:

exec_command failed for `/bin/bash -lc pwd`: CreateProcess { message: "Rejected(\"Failed to create unified exec process: No such file or directory (os error 2)\")" }

The same failure occurred for:

/bin/bash -lc 'uname -a'
/bin/bash -lc 'ls -l /bin/bash /usr/bin/bash'

Expected behavior

In a WSL-backed Codex Desktop workspace, if Codex chooses /bin/bash -lc ..., it should launch it in WSL, not as a native Windows executable path.

Alternatively, Codex should detect this unsupported hybrid mode and either:

• automatically avoid unified exec for Windows Desktop + WSL shell/workspace sessions, or
• return a clear diagnostic explaining that unified exec cannot directly launch WSL absolute paths from the Windows process runner.

Actual behavior

Normal shell/tool calls fail before command start with os error 2, even though WSL and /bin/bash are healthy.

Read-only checks from a Windows-backed Node runtime showed:

where wsl.exe
C:\Windows\System32\wsl.exe
C:\Users\**\AppData\Local\Microsoft\WindowsApps\wsl.exe

wsl.exe -e /bin/bash -lc 'printf "shell=%s user=%s cwd=%s\n" "$SHELL" "$(id -un)" "$PWD"; ls -l /bin/bash /usr/bin/bash'

Output:

shell=/bin/bash user=doug cwd=/mnt/c/Users/**/OneDrive/Documents/New project
-rwxr-xr-x 1 root root 1446024 Mar 31  2024 /bin/bash
-rwxr-xr-x 1 root root 1446024 Mar 31  2024 /usr/bin/bash

Direct Windows-side spawn of /bin/bash reproduced the lower-level problem:

spawn /bin/bash ENOENT

codex sandbox windows /bin/bash -lc pwd also reproduced the same class of issue:

windows sandbox failed: CreateProcessAsUserW failed: 2

Workaround

Set:

[features]
unified_exec = false
shell_snapshot = true

Then restart Codex Desktop.

After disabling unified_exec, fresh low-reasoning codex exec smoke tests passed.

Smoke 1:

codex exec -c model_reasoning_effort='low' -C '/mnt/c/Users/**/OneDrive/Documents/New project' 'Run exactly this smoke test: execute pwd with the shell tool, then report the raw command output and whether the shell tool started successfully. Do not edit files.'

Result:

/mnt/c/Users/**/OneDrive/Documents/New project

Smoke 2:

codex exec -c model_reasoning_effort='low' -C '/mnt/c/Users/**/OneDrive/Documents/New project' 'Run exactly this smoke test with the shell tool: ls -l /bin/bash /usr/bin/bash && uname -a. Report the raw command output and whether the shell tool started successfully. Do not edit files.'

Result:

-rwxr-xr-x 1 root root 1446024 Mar 31  2024 /bin/bash
-rwxr-xr-x 1 root root 1446024 Mar 31  2024 /usr/bin/bash
Linux BOOK-8S5UL4MRV3 6.6.87.2-microsoft-standard-WSL2 #1 SMP PREEMPT_DYNAMIC Thu Jun  5 18:30:46 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

Why this looks like a Codex/runtime bug

Source inspection suggests unified_exec changes shell tool selection and routes execution through the unified PTY-backed path. In this hybrid environment, the Windows-side runtime can receive a Linux argv (/bin/bash -lc ...) and attempt to create it as a Windows process.

Relevant source areas inspected:

• codex-rs/features/src/lib.rs
  • unified_exec is stable, and defaults to !cfg!(windows).
  • This suggests native Windows normally avoids unified exec unless explicitly enabled.
• codex-rs/tools/src/tool_config.rs
  • When Feature::UnifiedExec is enabled and ConPTY is supported, tool config can select ConfigShellToolType::UnifiedExec.
  • When disabled, it falls back away from unified exec.
• codex-rs/core/src/tools/handlers/unified_exec/exec_command.rs
  • exec_command builds the command using the session shell and delegates through UnifiedExecProcessManager.
• codex-rs/core/src/tools/runtimes/unified_exec.rs
  • Unified exec builds sandbox/process execution metadata and delegates process startup.
• codex-rs/core/src/unified_exec/process_manager.rs
  • The Windows path can ultimately spawn via Windows sandbox/process/PTY machinery, which cannot directly resolve /bin/bash.

Related issues

This looks related but not identical to:

• Unified exec caches stale ~/.codex/tmp/arg0 session path and fails with ENOENT until app restart #16970: Windows + WSL2 unified exec ENOENT involving stale ~/.codex/tmp/arg0/.../codex-linux-sandbox paths.
• Codex tool runtime intermittently loses apply_patch path and fails with No such file or directory #17240: unified exec/tool path instability causing Failed to create unified exec process: No such file or directory (os error 2).
• Windows: unified_exec PTY path bypasses Windows sandbox and can run unsandboxed despite workspace-write + network_access = false #14367: Windows unified exec sandbox behavior; not the same root cause, but related to unified exec edge cases on Windows.

Suggested fixes

One of:

1. Detect Windows Desktop + WSL-backed shell/workspace sessions and route unified exec process startup through wsl.exe when the argv is a WSL/Linux path.
2. Automatically disable/refuse unified exec for this hybrid mode until WSL path routing is supported.
3. Improve diagnostics when Windows unified exec receives a Linux absolute path such as /bin/bash, so users see a clear message instead of generic os error 2.

Additional notes

This setup is Windows Desktop, but the agent workspace and shell are WSL2 Ubuntu. Treating it as purely native Windows is misleading: the intended command environment is Linux, but the process creation boundary appears to be Windows-side when unified exec is enabled.

[github-actions]

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

• Codex Desktop WSL mode starts Windows app-server and leaves thread in PowerShell #21147
• exec_command tool consistently fails with "Failed to create unified exec process: No such file or directory (os error 2)" #20770

Powered by Codex Action

[MisterRound]

Additional sanitized finding from local debugging: in Windows Desktop + WSL mode, the desktop app and the WSL app-server can read different config homes. In this case the visible Windows config had , but the WSL app-server was still reading the WSL user's , where , which reactivated this failure mode. Filed separately as #22759 because it appears to be a distinct config-home / app-server bug that can cause #22185 to reappear unexpectedly.

[MisterRound]

Additional sanitized finding from local debugging: in Windows Desktop + WSL mode, the desktop app and the WSL app-server can read different config homes. In this case the visible Windows config had unified_exec = false, but the WSL app-server was still reading the WSL user's ~/.codex/config.toml, where unified_exec = true, which reactivated this failure mode.

Filed separately as #22759 because it appears to be a distinct config-home / app-server bug that can cause #22185 to reappear unexpectedly.

[MisterRound]

Follow-up RCA from the same Windows Desktop + WSL environment. unified_exec=false is still the necessary mitigation, but I also hit a related stale arg0 helper failure that can look like the same shell-runner problem.

Environment:

• Codex Desktop package: OpenAI.Codex_26.506.3741.0_x64__2p2nqsd0c76g0
• WSL: 2.7.3.0, kernel 6.6.114.1-1, Windows 10.0.26200.8457
• WSL app-server binary: /mnt/c/Users/<user>/.codex/bin/wsl/codex
• Codex CLI: codex-cli 0.130.0-alpha.5
• Both Windows and WSL configs now have [features] unified_exec = false.

Failure signature before reboot:

execution error: Io(Os { code: 2, kind: NotFound, message: "No such file or directory" })

Important detail: the workspace path was not missing. The failing thread's PATH contained a stale helper directory:

/mnt/c/Users/<user>/.codex/tmp/arg0/codex-arg0i3QOLP

That directory had existed earlier with Linux helpers:

apply_patch
applypatch
codex-execve-wrapper
codex-linux-sandbox

Later it was gone, while newer helper dirs existed under the same tmp/arg0 root but contained only Windows .bat shims:

apply_patch.bat
applypatch.bat

A full Windows/Codex reboot cleared it. After reboot, the live PATH helper dir existed again and contained Linux symlinks to the WSL app-server binary:

apply_patch -> /mnt/c/Users/<user>/.codex/bin/wsl/codex
applypatch -> /mnt/c/Users/<user>/.codex/bin/wsl/codex
codex-execve-wrapper -> /mnt/c/Users/<user>/.codex/bin/wsl/codex
codex-linux-sandbox -> /mnt/c/Users/<user>/.codex/bin/wsl/codex

This connects the unified_exec WSL launch issue with the stale arg0 helper class tracked in #16970. Practical local recovery is full Desktop/app-server restart; recreating the deleted helper directory is the wrong fix because it hides a runtime mismatch.