Codex on Windows with WSL: "Failed to create unified exec process: No such file or directory", how to fix it

You turn on the "WSL agent" in the Codex app for Windows and, from then on, no command runs. Not pwd, not git status. Every one of them fails before the shell even starts, with this message:

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

It is not your Bash, your project or WSL. It is a conflict between two Codex processes that share the same temp folder on the Windows drive. As of 10/07/2026, issue #49731 is still open with no official fix, but there is a way out that several users confirmed: move that folder off the Windows drive with a mount --bind.

What causes "Failed to create unified exec process: No such file or directory"?

The missing file is codex-linux-sandbox, the executable Codex uses to run each command inside the Linux sandbox. It disappears because a Codex process on the Windows side deletes the folder where the Linux-side process stored that executable.

The mechanism lives in the Codex source code, in codex-rs/arg0/src/lib.rs, and was described in the issue by someone who reproduced the bug without the app:

• Every Codex process creates its own folder under $CODEX_HOME/tmp/arg0/codex-arg0XXXXXX, with a .lock file held while the process is alive.
• On startup, every process runs a cleanup (janitor_cleanup) over that folder: it tries to lock each subfolder's .lock and, if it succeeds, assumes the folder was abandoned and deletes it.
• In WSL mode, the Linux agent and the Windows codex.exe share the same CODEX_HOME, at C:\Users\<you>\.codex, which Linux sees as /mnt/c/Users/<you>/.codex.
• A file lock taken inside WSL on a file under /mnt/c is invisible to Windows. codex.exe gets the lock, decides the Linux agent's folder is abandoned and deletes it, codex-linux-sandbox included.

The app starts that codex.exe a few seconds after launch. That is why restarting does not help: the agent's new folder gets deleted again right away.

How do I confirm it is this bug?

Look at the contents of the arg0 folder from the Windows Command Prompt:

dir /s %USERPROFILE%\.codex\tmp\arg0

If you only see .lock, apply_patch.bat and applypatch.bat, with no codex-linux-sandbox anywhere, this is your case. The .bat files belong to the Windows process's folder; the Linux agent's folder is already gone.

Another sign: with tty on, the same command fails with a more specific error that shows the missing path:

Unable to spawn /mnt/c/Users/<you>/.codex/tmp/arg0/codex-arg0<id>/codex-linux-sandbox because it doesn't exist on the filesystem (ENOENT: No such file or directory)

Which Codex versions have the problem?

Reports in issue #49731 span from package 26.928.2636.0 to 26.1002.6548.0, released on 10/06/2026, which one user confirmed still had the bug on 10/07. The Linux agent bundled with those builds ranges from codex-cli 0.159 to 0.160.1.

App version (Windows)	Status reported in #49731
26.917.9434.0	Worked (one user's report, Windows 10 + Debian)
26.928.2636.0 to 26.928.3736.0	Affected
26.930.x (including 26.930.41038)	Affected
26.1002.6548.0	Affected on 10/07/2026

How do I fix it with mount --bind?

The idea is to make the tmp/arg0 path point to a folder on the Linux drive. There, file locks work between Linux processes, and the Windows codex.exe no longer deletes the agent's helper. The rest of CODEX_HOME (config, sessions, rules) stays where it is.

1. Create the folder on Linux, inside WSL, as your own user:

mkdir -p /home/<linux-user>/codex-arg0-local

2. Make the mount survive restarts. Edit /etc/wsl.conf (sudo nano /etc/wsl.conf) and add:

[boot]
command = mount --bind /home/<linux-user>/codex-arg0-local /mnt/c/Users/<windows-user>/.codex/tmp/arg0

Use absolute paths, no ~: the boot command runs as root. If your wsl.conf already has a [boot] section with systemd=true, just add the command line to it.

3. Close the Codex app and restart WSL, in PowerShell:

wsl --shutdown

Open Codex again. To check the mount is active, run this in WSL:

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

Users who applied it report that commands run again and the sandbox still applies (writes outside the project stay blocked). To undo it, remove the line from wsl.conf and run sudo umount /mnt/c/Users/<windows-user>/.codex/tmp/arg0.

I mounted it and it still fails. Now what?

Most likely the agent was already running when you mounted, and it keeps looking for the old folder. One user reported exactly that after mounting with the app open. That is why step 3 matters: with the mount at boot and wsl --shutdown, the mount exists before Codex starts the agent, and the new folder is born on the Linux side.

What does not fix it?

All of this was tried by people who reported the bug in the issue, with no effect:

• Restarting Windows or the app, and opening a new chat.
• Reinstalling Codex, or removing and reinstalling Ubuntu.
• Installing bubblewrap and turning off unified_exec under [features] in config.toml.
• Recreating the deleted folder from WSL: Windows leaves the folder pending deletion while the .lock is open, and mkdir on Linux returns File exists.

Approving each command to run outside the sandbox works, but it is the wrong way out: you lose exactly the protection the sandbox exists to give you.

I have no sudo in WSL. Is there another way?

Yes: switch the agent to native mode. In Settings, in the agent selector, change from WSL to Windows native and restart the app, since the change only takes effect after a restart, according to the official Windows app documentation.

In native mode, the same documentation recommends keeping the project on the Windows drive and reaching it from WSL through /mnt/<drive>/. One user reported that opening a project under \\wsl.localhost with the native agent fails with helper_unknown_error, so moving the project is part of the switch. Once OpenAI fixes #49731, you can go back to the WSL agent.

Does this affect the Codex CLI inside WSL?

It can. The official documentation suggests export CODEX_HOME=/mnt/c/Users/<windows-user>/.codex in WSL so the CLI and the app share configuration. That is exactly the bug's condition: the app-free reproduction in the issue uses the Linux CLI with that CODEX_HOME and shows that a plain codex.exe --version on Windows already deletes the running Linux process's folder. If your CLI in WSL started failing with the same error, the same mount --bind fixes it.