Repository navigation
Windows Desktop + WSL workspace: unified_exec tries to CreateProcess /bin/bash and fails with ENOENT #22185
Description
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:
- Use Codex Desktop on Windows 11.
- Open a WSL-backed workspace under
/mnt/c/.... - Configure Codex with:
[features]
unified_exec = true
shell_snapshot = true- Start a session where the shell is WSL bash and the workspace path is
/mnt/c/.... - Run a normal shell/tool command such as
pwd,uname -a, orls -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 = trueThen 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.rsunified_execis 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::UnifiedExecis enabled and ConPTY is supported, tool config can selectConfigShellToolType::UnifiedExec. - When disabled, it falls back away from unified exec.
- When
codex-rs/core/src/tools/handlers/unified_exec/exec_command.rsexec_commandbuilds the command using the session shell and delegates throughUnifiedExecProcessManager.
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.
- The Windows path can ultimately spawn via Windows sandbox/process/PTY machinery, which cannot directly resolve
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-sandboxpaths. - Codex tool runtime intermittently loses
apply_patchpath and fails withNo such file or directory#17240: unified exec/tool path instability causingFailed 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:
- Detect Windows Desktop + WSL-backed shell/workspace sessions and route unified exec process startup through
wsl.exewhen the argv is a WSL/Linux path. - Automatically disable/refuse unified exec for this hybrid mode until WSL path routing is supported.
- Improve diagnostics when Windows unified exec receives a Linux absolute path such as
/bin/bash, so users see a clear message instead of genericos 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.
Activity
github-actions commentedon May 11, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
MisterRound commentedon May 15, 2026
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 commentedon May 15, 2026
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, whereunified_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 commentedon May 15, 2026
Follow-up RCA from the same Windows Desktop + WSL environment.
unified_exec=falseis still the necessary mitigation, but I also hit a related stalearg0helper failure that can look like the same shell-runner problem.Environment:
OpenAI.Codex_26.506.3741.0_x64__2p2nqsd0c76g02.7.3.0, kernel6.6.114.1-1, Windows10.0.26200.8457/mnt/c/Users/<user>/.codex/bin/wsl/codexcodex-cli 0.130.0-alpha.5[features] unified_exec = false.Failure signature before reboot:
Important detail: the workspace path was not missing. The failing thread's
PATHcontained a stale helper directory:That directory had existed earlier with Linux helpers:
Later it was gone, while newer helper dirs existed under the same
tmp/arg0root but contained only Windows.batshims:A full Windows/Codex reboot cleared it. After reboot, the live
PATHhelper dir existed again and contained Linux symlinks to the WSL app-server binary:This connects the
unified_execWSL launch issue with the stalearg0helper 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.MisterRound commentedon May 30, 2026
Follow-up from the same Windows Desktop + WSL environment: this failure has regressed into a worse state than the original
unified_exec=truereport here.The current repro is not
unified_exec=true:unified_exec=falseis set in both%USERPROFILE%\.codex\config.tomland<wsl-home>/.codex/config.toml.OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0, with WSL app-servercodex-cli 0.135.0-alpha.1.The current evidence points at the
tmp/arg0helper lifecycle rather than the oldCreateProcess(/bin/bash)path:So the active WSL app-server can still hold a lock fd to a helper dir that is gone from the filesystem, and the active thread remains pinned to that deleted helper path. New helper dirs may be created later, but they do not repair the already-poisoned thread/app-server state.
I opened a focused follow-up issue for the regression here: #25317
Relationship to this issue:
unified_exec=true/ WindowsCreateProcess(/bin/bash)failure.unified_exec=falseand reboot are no longer enough because the sharedCODEX_HOME/tmp/arg0helper state can still poison shell execution.chisong1 commentedon Jun 3, 2026
I’m hitting this same class of failure on Windows Desktop + WSL.
Environment:
/home/user/project/usr/bin/bashcodex-cli 0.132.0bubblewrap 0.9.0is installedObserved:
exec_commandcalls fail before command execution with:CreateProcess { message: "Rejected(\"Failed to create unified exec process: No such file or directory (os error 2)\")" }/mnt/c/Users/user/.codex/bin/wsl/.../codex app-server --analytics-default-enabledThis makes the Desktop WSL agent mode unreliable for normal coding work even though the WSL environment itself is healthy.
ChenWenBrian commentedon Jun 5, 2026
same issue, codex desktop version
26.602.30954it can't work with wsl now.
hyman-ren commentedon Jun 5, 2026
Codex Desktop 26.602.3474.0 on Windows + WSL cannot start any shell command.
Even a shell builtin test like
type -a codexfails before execution with:execution error: Io(Os { code: 2, kind: NotFound, message: "No such file or directory" })
My WSL Ubuntu24 is healthy and /bin/bash, /bin/sh exist. This indicates the Desktop WSL Agent / unified_exec layer is failing before command execution.
afonseca08 commentedon Jun 7, 2026
I’m seeing the same failure signature in Codex Desktop with a WSL-backed workspace.
Environment:
bashworkspace-writeObserved behavior:
A basic shell command fails before the command starts:
JaimeLanders commentedon Jun 8, 2026
I'm also hitting this issue as well, codex said my evidence might be helpful so pasting it below:
Your evidence is useful because you reproduce it on newer build
26.602.40724, while the identical VS Code WSL test passes.I’d add this comment rather than open a duplicate:
WSL environment:
<SNIPPED>, uid 1000/home/...Codex Desktop result:
Representative error:
Changing
integratedTerminalShellfromwsltopowershell, fullyrestarting Codex Desktop, and starting a new thread did not help.
The same smoke test passes completely in the Codex VS Code extension
running in a
WSL: Archremote window. Bash, Git, pipes, pipefail,parallel commands, repository detection, and WSL identity all work there.
This isolates the failure to the Windows Desktop-to-WSL command launcher,
rather than Bash,
.bashrc, Git, or the WSL installation.jgilfoil commentedon Jun 8, 2026
I’m seeing this same issue on current Codex Desktop, and the documented workaround did not resolve it.
Environment:
OpenAI.Codex_26.602.4764.0_x64__2p2nqsd0c76g0Windows Subsystem for LinuxWSLUbuntu/home/jason/repos/projects/trading-harness-v2Linux Prometheus 5.15.167.4-microsoft-standard-WSL2/mnt/c/Users/jason/.codex/bin/wsl/codex->codex-cli 0.130.0-alpha.5/mnt/c/Users/jason/.codex/bin/wsl/81645c5d269e0fb2/codex->codex-cli 0.137.0-alpha.4Repro in a fresh Codex Desktop session:
Sandboxed result:
Running the exact same command with escalation/full access succeeds:
Things I tried that did not fix it:
wsl --shutdownC:\Users\jason\.codex\config.toml/home/jason/.codex/config.toml.codex/config.tomloverride existsC:\Users\jason\.codex\tmp/home/jason/.codex/tmpexistedC:\Users\jason\.codex\bin\wslto force Codex Desktop to rebuild the WSL bin cacheAfter all of that, the behavior is unchanged: sandboxed WSL exec fails before launching
/bin/bash, while escalated/full-access exec works inside WSL.This looks like the sandboxed WSL exec bridge is still trying to create
/bin/bashfrom the wrong side of the Windows/WSL boundary, or otherwise not entering WSL before process creation.hoklims commentedon Jul 5, 2026
Adding a Desktop-free repro and separating the three failures now stacked on this thread, so each one gets its own fix. Thanks @MisterRound; your source inspection matches what I traced.
Repro without Desktop. The Windows sandbox spawn reproduces straight from the CLI:
/bin/bashis a valid WSL path but not a Windows executable, so the Windows-side process create fails with error 2. The Desktop tool-call failures reported above (Failed to create unified exec process: No such file or directory (os error 2)) are the same class from the sibling pipe/PTY path. Both hit the same wall; the source trace below covers both.Three distinct causes are stacked here. They want three homes:
/bin/bashnativelyunified_exec = true(orcodex sandbox windows)unified_exec=falseclears it in-sessionCODEX_HOME/tmp/arg0helper + live lock fdunified_exec=falseand rebootIo(Os code:2); PATH points at a deleted arg0 dir held by an app-server lock~/.codex, app-server reads WSL~/.codexunified_execCommenters split across these: cause 1 for chisong1 and afonseca08; cause 2 for jgilfoil, who exhausted the workarounds and still fails; a cause 3 signal from JaimeLanders. Scoping #22185 to cause 1 and moving the post-workaround
Io(Os code:2)reports to #25317 unblocks a clean fix for each.Cause 1, where it spawns (
main@be33f80bc65159c094ecd06bf155afa3061ce23d).open_session_with_prepared_exec_envincodex-rs/core/src/unified_exec/process_manager.rs:955has two Windows spawn paths, and neither routes through WSL:request.command.split_first()at l.1075 handsprogram/argstocodex_utils_pty::pipe::spawn_process_no_stdin_with_inherited_fdsat l.1091 (orpty::spawn_process_with_inherited_fdsat l.1080 for tty), which reachestokio::process::Command::new(program).spawn()incodex-rs/utils/pty/src/pipe.rs./bin/bashresolves as a native Windows exe, returnsos error 2, and gets wrapped intoUnifiedExecError::create_processat l.1102.codex sandbox windowsrepro above):SandboxType::WindowsRestrictedTokenat l.966 goes toCreateProcessAsUserWincodex-rs/windows-sandbox-rs/src/process.rs, wrapped at l.1045/1062, which is theCreateProcessAsUserW failed: 2variant.The file has no
wslanywhere, andwsl.exehas zero matches repo-wide. The oneForeignPathguard (errors.rs) covers the cwd at l.972 and l.1071, never the program argv.Fix for cause 1: at the split (l.1078), detect a WSL-backed session (a Linux-absolute
program, or an explicit WSL flag) and spawnwsl.exe -e <program> <args>instead of the raw argv; put the same guard ahead of the sandbox branch at l.966. Smaller version: extend the cwd-onlyForeignPathcheck to coverprogram, so the failure is a clear diagnostic instead ofos error 2.I can put up a repro-backed patch for cause 1 in a fork if that helps.
20000419 commentedon Aug 18, 2026
Ran into the same
/bin/bashCreateProcess wall on Windows. What worked for me: stop trying to hand the agent a real bash and give it one that isn't bash at all — fauxnix, a local MCPbashtool that deterministically translates bash syntax to native PowerShell and returns GNU-style output and bash-style errors. Zero bash dependency: no WSL, no MSYS2, no Git Bash, nothing to probe or mis-detect.Two things from their docs that made it credible to me: they actually measured Codex's Windows built-in shell being PowerShell 5.1 and what that costs non-OpenAI models (comparison, benchmarks — e.g. kimi-k2-thinking: 3.1× slower with 24 error events in raw PS vs zero errors through fauxnix), and it's honestly scoped: heredocs/control-flow rejected loudly, and if you need real bash tooling (git scripts, devcontainers) WSL is still the right answer — this just removes the dependency for agent shell work. One codex-specific caveat from their docs: exec mode needs
--dangerously-bypass-approvals-and-sandboxfor MCP tools.LB-Yamazaki commentedon Sep 30, 2026
I am experiencing a similar issue with the Codex desktop app on Windows 10 when using a project stored in WSL2.
Environment
/home/<user>/dockerworkspace/hbs20_space/hbs20_serverSymptoms
When I ask Codex to execute simple commands such as
pwdorgit branch --show-current, it fails with the following error:The same error occurs even when Codex explicitly retries using
/bin/bash.Troubleshooting performed
sh -lcstarts successfully when executed directly inside WSL.The project files can be listed through Codex, but shell commands fail to start. A separate project stored on the local Windows drive was also able to create a test file successfully.
This suggests that the issue may be related to process execution in the Codex desktop app when working with a WSL project, rather than Git or WSL itself.
I have attached a screenshot showing the exact error.
Please let me know if any additional logs or diagnostic information would help investigate this issue.
20000419 commentedon Oct 5, 2026
Thanks for the detailed repro — the WSL2-project case is a distinct flavor of this bug: the desktop is trying to spawn a Windows-side
/bin/bashfor a Linux-side path, which can't resolve either way. Two honest options from where I sit:/bin/bashto fail. Not for everyone: it implements a fail-loud subset of bash (~110 commands, verified by a 250-case differential corpus against real GNU coreutils). On models weaker at PowerShell we measured ~2.5× fewer failed tool calls, and zero overhead on strong ones.LB-Yamazaki commentedon Oct 6, 2026
@20000419 Thanks for the suggestion and clarification.
I understand that running Codex directly inside the WSL2 distro would avoid the Windows/WSL process boundary and should work around this issue.
However, in my case I'd like to continue using the Codex Desktop GUI workflow rather than switching to the CLI-based workflow inside WSL2.
So for now, I'll keep the current setup and wait for a fix for the Windows Desktop + WSL integration.
Thanks again for taking the time to look into this.
LB-Yamazaki commentedon Oct 19, 2026
Update (October 19, 2026): WSL2 execution still fails intermittently on Windows 10, while Windows 11 works
I would like to share additional test results following my previous report.
Test environments
Windows 11 + WSL2
26.1013.40934Windows 10 Pro + WSL2
26.1013.40934Both machines are running the same Codex Desktop version.
Test procedure
I opened an existing WSL2 project, started a new thread, and asked Codex to execute the following read-only commands without modifying any files:
pwd git branch --show-current git status --shortResults on Windows 11
All three commands completed successfully. The working directory and current Git branch were reported correctly, and the working tree was clean.
No execution errors occurred during this test.
Results on Windows 10
Test 1 — Successful after retry
-1.Test 2 — Failed in a new thread
wsl.exeinvocation.None of the three commands could be executed in this second test.
Current status
The basic WSL2 command execution tests succeeded on Windows 11, but Windows 10 continues to experience intermittent execution environment initialization failures with the same Codex Desktop version.
Although one Windows 10 test succeeded after a retry, the issue is not reliably resolved.
I cannot yet determine whether this is a remaining Windows sandbox initialization issue or a separate WSL process-launch problem.
Attached screenshots
setup refresh had errorsresultSensitive local filesystem paths have been redacted.
I hope these additional results help narrow down the remaining issue.
Thank you to the Codex team and everyone investigating this problem.
20000419 commentedon Oct 21, 2026
Thanks for the follow-up and the clean A/B — same Codex build, Windows 11 clean vs Windows 10 intermittent (
-1launch, thensetup refresh had errorsacross retry strategies including a directwsl.execall) is genuinely useful triangulation for the maintainers: it narrows the remaining failure to the Windows 10 + WSL2 launch path rather than the desktop↔WSL contract itself. Worth attaching to any open Win10-specific reports if one exists. Glad the Windows 11 side is behaving now.