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

[fy-nn]

What version of Codex is running?

codex 26.325.31654 app
codex-cli 0.118.0-alpha.2

What subscription do you have?

plus

Which model were you using?

gpt-5.3 Codex (Codex desktop default coding model)

What platform is your computer?

Windows 11 + WSL2
Linux kernel: Linux 6.6.87.2-microsoft-standard-WSL2 x86_64

What issue are you seeing?

In an active Codex Desktop thread, non-escalated tool execution suddenly fails with ENOENT from unified exec.
The failing spawn target points to a temp runtime path under ~/.codex/tmp/arg0/<session>/codex-linux-sandbox that no longer exists.

After restarting the app, a new codex-arg0* runtime folder is created and tool execution works again.

What steps can reproduce the bug?

Intermittent, but this sequence reproduces it for me:

1. Start Codex Desktop in a WSL-backed workspace.
2. Use normal tool calls for a while (exec_command, apply_patch, etc.).
3. At some point, all non-escalated exec_command calls fail immediately.
4. Error references a specific stale temp path:
   .../tmp/arg0/codex-arg06KNIXk/codex-linux-sandbox ... ENOENT
5. Confirm that folder no longer exists.
6. Restart Codex Desktop.
7. A new folder appears (example: codex-arg0nHm5Gj) containing codex-linux-sandbox, and commands succeed again.

What is the expected behavior?

If an ephemeral codex-arg0* runtime folder is missing/rotated, unified exec should automatically rebind/recreate sandbox shims instead of hard-failing until full app restart.

What do you see instead?

Exact error captured in session log:

Failed to create unified exec process: Unable to spawn /mnt/c/Users/<redacted>/.codex/tmp/arg0/codex-arg06KNIXk/codex-linux-sandbox because it doesn't exist on the filesystem (ENOENT: No such file or directory)

Additional information

I checked related issues before filing:

• Agent cannot edit files using the sandbox when resuming a session #3947 (codex-linux-sandbox ... not provided on resumed sessions)
• No such file or directory (OS error 2) #4754 (generic os error 2)
• Codex CLI becomes unusable if the working directory from which it was launched is moved or removed #2252 (os error 2 after env/path changes)

This report is specifically about a stale ~/.codex/tmp/arg0/codex-arg* runtime path being referenced by unified exec during an active desktop session.

Local evidence:

• Failing log:
  /mnt/c/Users/<redacted>/.codex/sessions/2026/04/07/rollout-2026-04-07T10-37-51-019d655f-d19c-75e0-9fea-dc5638991fd9.jsonl
  (entry timestamp 2026-04-07T01:06:04.320Z)
• Missing stale folder after failure:
  ~/.codex/tmp/arg0/codex-arg06KNIXk (not found)
• Healthy after restart:
  ~/.codex/tmp/arg0/codex-arg0nHm5Gj/codex-linux-sandbox -> ~/.codex/bin/wsl/codex

### Sanitized diagnostic excerpt

[2026-04-07T01:06:04.320Z]
exec_command failed for `/bin/bash -lc ''`: CreateProcess {
  message: "Rejected(\"Failed to create unified exec process: Unable to spawn /mnt/c/Users/<redacted>/.codex/tmp/arg0/codex-arg06KNIXk/codex-linux-sandbox because it doesn't exist on the filesystem (ENOENT: No such file or directory)\")"
}

[2026-04-07T01:09:36.879Z]
Command: /bin/bash -lc 'ls -la /mnt/c/Users/<redacted>/.codex/tmp/arg0/codex-arg06KNIXk 2>/dev/null || true'
Output: <empty>  (folder missing)

[2026-04-07T01:17:00.619Z]
Command: /bin/bash -lc 'ls -la /mnt/c/Users/<redacted>/.codex/tmp/arg0'
Output:
  ... codex-arg0nHm5Gj

[2026-04-07T01:17:21.860Z]
Command: /bin/bash -lc 'ls -la /mnt/c/Users/<redacted>/.codex/tmp/arg0/codex-arg0nHm5Gj'
Output:
  ... codex-linux-sandbox -> /mnt/c/Users/<redacted>/.codex/bin/wsl/codex

[2026-04-07T01:18:04Z]
`pwd` and `node -v` succeed again in the same workspace after restart.

Environment:
- codex-cli 0.118.0-alpha.2
- Windows 11 + WSL2

Root-cause hypothesis:

• Unified exec/harness caches a per-session sandbox shim path under tmp/arg0.
• If that ephemeral folder is removed/rotated, the cached path is reused and all non-escalated spawns fail with ENOENT.

High-level fix suggestion:

• On ENOENT for the sandbox shim path, force a one-time runtime rehydrate/rebind:
  • recreate the per-session symlink in a fresh codex-arg0* folder, or
  • fall back to ~/.codex/bin/wsl/codex and rebuild session shims.

[github-actions]

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

• Frequent apply_patch failures after 0.117.0 appear to come from the execution/runtime path, not from patch grammar parsing #16102
• apply_patch fails with No such file or directory on existing files in codex-cli 0.118.0 #16791
• Stale '(deleted)' self-exe path can break apply_patch after binary replacement #16097

Powered by Codex Action

[fy-nn]

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

[brucek2]

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.