Codex Desktop on Windows/WSL2 cannot run sandboxed commands in WSL projects #26723

Summary

Codex Desktop on Windows + WSL2 cannot run ordinary sandboxed/default shell commands in WSL projects. Simple commands like pwd and ls fail before executing with ENOENT, while approved-prefix commands such as git status and explicitly escalated commands work.

This continues after setting unified_exec = false in both Codex config homes, restarting Codex, starting a new chat, and rebooting the system.

Related issues: #16970, #25317.

Environment

• Codex CLI: codex-cli 0.137.0-alpha.4
• Codex Desktop app-server process:
  /mnt/c/Users/laver/.codex/bin/wsl/81645c5d269e0fb2/codex app-server --analytics-default-enabled
• WSL version: 2.7.3.0
• WSL kernel: 6.6.114.1-microsoft-standard-WSL2
• WSLg: 1.0.73
• Windows version: 10.0.26200.8457
• Linux distro: Ubuntu 26.04 LTS
• Workspace path:
  /home/laverya/go/src/github.com/laverya/laverya.com
• Desktop Codex home:
  /mnt/c/Users/laver/.codex
• WSL Codex home:
  /home/laverya/.codex
• /mnt/c mount:
  9p rw,noatime,aname=drvfs;path=C:\;uid=1000;gid=1000;symlinkroot=/mnt/,cache=5,...
• /home/laverya is on ext4.

Config

Both config files now contain unified_exec = false.

/mnt/c/Users/laver/.codex/config.toml relevant values:

approval_policy = "on-request"
approvals_reviewer = "auto_review"
sandbox_mode = "workspace-write"

[desktop]
integratedTerminalShell = "wsl"
runCodexInWindowsSubsystemForLinux = true

[features]
unified_exec = false

/home/laverya/.codex/config.toml relevant values:

approvals_reviewer = "guardian_subagent"

[features]
unified_exec = false

codex features list reports unified_exec stable false for both CODEX_HOME=/mnt/c/Users/laver/.codex and the WSL home.

Actual Behavior

Plain/default shell commands fail:

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

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

Previously, before/while debugging, the error also appeared as:

Failed to create unified exec process: No such file or directory (os error 2)

and with TTY/unified exec diagnostics:

Unable to spawn /mnt/c/Users/laver/.codex/tmp/arg0/codex-arg0.../codex-linux-sandbox because it doesn't exist on the filesystem

Approved-prefix commands still work, e.g.:

git status --short --branch

Explicitly escalated commands also work, proving the repo path and binaries are accessible outside the broken default/sandbox path.

Expected Behavior

Default shell commands like pwd, ls, rg --files, and sed should run normally in the configured WSL workspace under the selected sandbox policy.

Diagnostics

codex doctor --summary --ascii reports healthy for both Codex homes:

17 ok | 1 idle | 0 warn | 0 fail ok

This happens even while default shell commands fail.

codex-linux-sandbox is not a missing standalone binary. It appears to be an argv0 alias of the main Codex binary. This works:

exec -a codex-linux-sandbox /mnt/c/Users/laver/.codex/bin/wsl/81645c5d269e0fb2/codex --help

and prints the Linux sandbox helper CLI help.

arg0 Helper Observations

After clearing tmp/arg0 and starting Codex, a healthy Linux helper dir appears briefly:

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

These are symlinks to:

/mnt/c/Users/laver/.codex/bin/wsl/81645c5d269e0fb2/codex

After opening a chat, another helper dir appeared containing only Windows wrappers:

apply_patch.bat
applypatch.bat

After failed default commands, /mnt/c/Users/laver/.codex/tmp/arg0 was observed empty again.

Workarounds Tried

• Restarted Codex Desktop.
• Rebooted the system.
• Renamed/recreated:
  • /mnt/c/Users/laver/.codex/tmp/arg0
  • /home/laverya/.codex/tmp/arg0
• Renamed/quarantined process/shell state:
  • /home/laverya/.codex/process_manager
  • /home/laverya/.codex/shell_snapshots
  • corresponding Desktop-home paths where present
• Set unified_exec = false in the Windows/Desktop Codex config.
• Set unified_exec = false in the WSL Codex config.
• Started a new chat/thread after those changes.

The issue still reproduces.

Additional Note

The Node REPL tool also has WSL path trouble in this environment: it sees the cwd as a \\wsl.localhost\... UNC path and gets EPERM when trying to stat WSL paths. That may be separate, but it suggests a broader Desktop/WSL path-boundary issue.