Unified exec caches stale ~/.codex/tmp/arg0 session path and fails with ENOENT until app restart

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

• #16102
• #16791
• #16097

Powered by Codex Action

Uploaded diagnostics via /feedback.

Thread ID: 019d655f-d19c-75e0-9fea-dc5638991fd9
Time: 2026/04/07 - 2:05pm
Repro summary: unified exec failed with ENOENT for missing ~/.codex/tmp/arg0/.../codex-linux-sandbox; restart recreated a new codex-arg0* folder and resolved it.

Related issue for overlap context: #16791

Same here. I have to quit the Codex app and delete the .codex/tmp directory every time I switch project folders. Otherwise apply_patch and other basic tooling is broken. (also, fwiw, Codex did not feel this issue was a clear match to any of the potential dupes noted above.)

Here's Codex's own report:
Confirmed on Codex Desktop + Windows 11 + WSL2.

Repro pattern:

work in one WSL-backed repo
switch to another repo/workspace in the app without quitting Codex
after one or more switches, apply_patch starts failing with No such file or directory
some ordinary non-escalated exec_command calls also fail with Failed to create unified exec process: No such file or directory (os error 2)
Key evidence:

the active session environment had PATH starting with %USERPROFILE%\\.codex\\tmp\\arg0\\codex-arg0...
that exact codex-arg0... directory no longer existed
after restart, PATH pointed at a fresh existing codex-arg0... dir and both apply_patch and sandboxed exec/write worked again
This does not look like patch grammar parsing. It looks like stale temp/session wrapper state after workspace switching.

Recovery that worked:

quit Codex Desktop
delete .codex/tmp in both Windows-side and WSL-side homes
restart Codex
In my case that restored:

sandboxed shell write
apply_patch
normal non-escalated exec
This seems very close to the root cause described here: the live session retains a dead arg0 temp-wrapper path until restart.

Additional confirmation from Windows Desktop + WSL mode on Codex Desktop OpenAI.Codex_26.506.3741.0_x64__2p2nqsd0c76g0, WSL 2.7.3.0, Codex WSL binary reporting codex-cli 0.130.0-alpha.5.

I hit the stale helper-dir failure exactly as described here:

• Live PATH contained /mnt/c/Users/<user>/.codex/tmp/arg0/codex-arg0i3QOLP.
• That directory no longer existed.
• Earlier in the session it had contained Linux helpers: apply_patch, applypatch, codex-execve-wrapper, codex-linux-sandbox.
• Later helper dirs under the same tmp/arg0 root existed but contained only Windows .bat apply-patch shims.
• Normal shell/tool calls failed before command execution with No such file or directory.
• The workspace path itself existed; the failure was the cached helper path, not cwd.

A full reboot/Desktop restart regenerated a healthy helper dir with Linux symlinks to /mnt/c/Users/<user>/.codex/bin/wsl/codex and shell calls started working again.

This supports the fix direction in #17570: active helper dirs need to be protected from cleanup/rotation, especially when the WSL runtime uses a Windows-mounted CODEX_HOME under /mnt/c.

Additional current data point from Windows Desktop + WSL: this stale tmp/arg0 helper class is still reproducible in OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0, and the recovery behavior appears worse than before.

Important difference from the original report:

• unified_exec=false is already set in both Windows and WSL Codex configs.
• The machine was fully rebooted more than once.
• Reboot/relaunch is no longer a reliable recovery; a fresh Desktop + WSL app-server session can still reach the stale-helper state.

Live evidence from the affected session:

PATH contains:
/mnt/c/Users/<user>/.codex/tmp/arg0/codex-arg0UXHjoV

stat:
No such file or directory

/proc/<app-server-pid>/fd/3:
/mnt/c/Users/<user>/.codex/tmp/arg0/codex-arg0UXHjoV/.lock

fdinfo:
POSIX ADVISORY WRITE lock owned by the live app-server pid

So the WSL app-server still has an fd/lock for the old .lock inode, but the helper directory path is gone. Later/newer codex-arg0* directories can be created with valid Linux symlinks, but the active thread remains pinned to the deleted path and shell/tool calls still fail before command execution.

I opened a focused regression issue here: https://github.com/openai/codex/issues/25317

This strengthens the root-cause direction in #17570, but also suggests the fix may need to cover the mixed Windows/WSL shared-home case, not only Linux-side lock unreliability.

Still reproducible on a newer Windows Desktop build.

Environment

• Codex Desktop package: OpenAI.Codex_26.707.8479.0_x64__2p2nqsd0c76g0
• WSL app-server: codex-cli 0.144.2
• Windows 11 build 26200
• WSL 2.7.10, Ubuntu
• Repository stored on the WSL filesystem under /root/test_cpp

Observed behavior

• Shell execution initially works.
• After the Desktop app has been running for some time, every normal exec_command fails before the requested command starts.
• The same failure occurs with zsh, bash, and sh:

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

• Direct wsl.exe shell commands remain healthy.
• Restarting Codex Desktop restores shell execution.
• After restart, Desktop creates a fresh helper directory such as:

C:\Users\<user>\.codex\tmp\arg0\codex-arg04kNAGN

containing Linux symlinks for apply_patch, applypatch, codex-execve-wrapper, and codex-linux-sandbox.

Desktop startup logs show unified_exec enabled.

I did not capture the failed app-server's PATH or deleted helper directory before restarting, so I cannot yet prove that the live session referenced a deleted arg0 directory. However, the failure signature, healthy direct WSL shell, delayed onset, and restart recovery closely match this issue.

Separately, the Desktop git watcher produces repeated EISDIR errors on WSL UNC paths. That appears to be the distinct watcher problem tracked in #17991, rather than sufficient evidence that the watcher caused this shell failure.