›_ Codex Issues
Codex Issues / #26723

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

Resolved 💬 3 comments Opened Jun 6, 2026 by laverya Closed Jun 6, 2026

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

26.602.40724

What subscription do you have?

Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

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.

What steps can reproduce the bug?

This unfortunately happens for all of my sessions and WSL projects, so I am not sure how to reproduce on someone else's machine. Session ID 019e99c5-a2e7-7100-84fc-6e328c685303 was my most recent debug attempt.

What is the expected behavior?

Bash commands like ls or pwd as well as other tools like apply_patch work properly within WSL projects.

Additional information

I believe I first saw this a week ago with the same update that allowed connecting a phone to Codex on windows.

My final debugging summary was as follows:

<details>
<summary>Click to expand</summary>

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.

</details>

I think the most relevant part of that is that I see .bat helper files being created. 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.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗