codex - 💡(How to fix) Fix Regression: Windows Desktop + WSL shell stays poisoned after reboot; live app-server holds deleted CODEX_HOME/tmp/arg0 helper path despite unified_exec=false

Summary

This is a regression / worse state than the already-reported Windows Desktop + WSL shell failures in #22185 and #16970.

• #22185 covered unified_exec=true causing Windows Desktop + WSL to try to CreateProcess a Linux shell path such as /bin/bash. The workaround was unified_exec=false.
• #16970 covered stale CODEX_HOME/tmp/arg0/codex-arg0* helper paths where restarting Desktop generally regenerated a working helper directory.
• This report is worse: unified_exec=false is already set in both the Windows Desktop Codex home and the WSL Codex home, the machine was fully rebooted more than once, and a fresh Desktop + WSL app-server session can still reach a poisoned state where the active shell/tool runtime is pinned to a deleted tmp/arg0 helper directory.

In other words, reboot/relaunch is no longer a reliable recovery for this failure class.

Environment

• Windows Desktop package: OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0
• Desktop release string in logs: 26.527.31326
• Electron runtime: 42.1.0
• Active WSL app-server / hashed WSL agent: codex-cli 0.135.0-alpha.1
• Stable WSL agent path still present: codex-cli 0.130.0-alpha.5
• Platform: Windows 11 + WSL2 Ubuntu
• WSL kernel observed: 6.6.114.1-microsoft-standard-WSL2
• Desktop CODEX_HOME: %USERPROFILE%\.codex, seen from WSL as /mnt/c/Users/<user>/.codex
• Shell in the affected Desktop session: /bin/bash
• unified_exec=false in both:
  • %USERPROFILE%\.codex\config.toml
  • <wsl-home>/.codex/config.toml

Actual Behavior

Normal shell/tool calls fail before the requested command starts:

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

The workspace path is not the problem. The active session's PATH contains a stale helper directory:

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

That directory no longer exists:

stat: cannot statx '/mnt/c/Users/<user>/.codex/tmp/arg0/codex-arg0UXHjoV': No such file or directory

However, the live WSL app-server still holds an fd to the stale helper lock path:

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

And fdinfo shows the live process still has a POSIX advisory write lock on that old lock inode:

lock: 1: POSIX  ADVISORY  WRITE <app-server-pid> ...

Later, a new codex-arg0* directory can appear under the same tmp/arg0 root with valid Linux symlinks:

apply_patch -> /mnt/c/Users/<user>/.codex/bin/wsl/<hash>/codex
applypatch -> /mnt/c/Users/<user>/.codex/bin/wsl/<hash>/codex
codex-execve-wrapper -> /mnt/c/Users/<user>/.codex/bin/wsl/<hash>/codex
codex-linux-sandbox -> /mnt/c/Users/<user>/.codex/bin/wsl/<hash>/codex

But this does not repair the active thread, because the active thread/app-server state remains pinned to the deleted codex-arg0UXHjoV helper path.

Why This Is Not Just a Duplicate

This is related to #16970 and #22185, but it is not the same recovery state:

• unified_exec=false is already applied in every relevant config.
• A full OS reboot was attempted more than once.
• The failure still reappears in the current Desktop build family.
• The live app-server can retain an fd/lock for a helper path that is already gone from the filesystem.
• Creating a newer helper directory does not rebind the active shell/tool runtime.

So the old practical workaround, "restart/reboot Desktop so a fresh helper dir is created," is no longer sufficient.

Source-Level Findings

I checked current origin/main of openai/codex at:

8acaec73b6a227ae9375064e910ecf86f2620ec0

Relevant current behavior in codex-rs/arg0/src/lib.rs:

• The helper root is shared under find_codex_home()/tmp/arg0.
• Unix creates helper symlinks in that root: apply_patch, applypatch, codex-execve-wrapper, codex-linux-sandbox.
• Windows creates .bat helper shims in the same root.
• Cleanup is lock-only: janitor_cleanup() attempts to lock each child dir and deletes it if locking succeeds.

This is fragile in Windows Desktop + WSL because the Desktop home is shared across a Windows process family and a WSL/Linux process family, and in this setup CODEX_HOME is on DrvFS under /mnt/c.

PR #17570 adds a .pid owner sentinel and appears to address the Linux-side stale-helper case, but I do not see that commit on origin/main. Also, as currently written on that branch, the owner PID liveness check returns false on non-Linux. That means it may not fully protect a WSL-owned helper directory if a Windows-native Codex process is janitoring the same shared %USERPROFILE%\.codex\tmp\arg0 tree.

Related Runtime Evidence

The same Desktop logs show mixed runtime surfaces in the same launch:

stdio_transport_spawned ... executablePath=%USERPROFILE%\.codex\bin\wsl\<hash>\codex ... spawnCommand=wsl.exe
Current reported app-server version: currentVersion=0.135.0-alpha.1

But Browser/Computer Use runtime selection in the same session selected Windows-native paths:

browser_use_runtime_paths_selected codexCliPath=%LOCALAPPDATA%\OpenAI\Codex\bin\<hash>\codex.exe ... platform=win32
computer-use native pipe startup failed ... "Windows Computer Use helper paths are unavailable"

I am not claiming the Browser/Computer Use plugin failure is the root cause of the shell failure. I am including it because it shows the same Desktop session crossing Windows-native and WSL-native runtime/cache surfaces while sharing the same Codex home.

Expected Behavior

For Windows Desktop + WSL sessions:

• unified_exec=false should remain a reliable mitigation for the Windows CreateProcess(/bin/bash) failure class.
• Reboot/relaunch should not deterministically return to a poisoned helper state.
• A live app-server should not have its active tmp/arg0 helper directory deleted while it still uses paths inside it.
• If a cached codex-linux-sandbox / arg0 helper path returns ENOENT, the runtime should rehydrate/rebind helper paths instead of leaving the thread permanently broken.

Suggested Fix Direction

One or more of:

1. Namespace arg0 helper dirs by runtime family/platform/distro, for example separate Windows-native helpers from WSL/Linux helpers instead of sharing CODEX_HOME/tmp/arg0.
2. Add a helper manifest containing platform, helper kind, owner PID, and WSL distro/runtime identity; janitors should only clean dirs from their own runtime family.
3. Make the active-helper ownership check cross-runtime safe. If a Windows process cannot verify a WSL PID, it should not treat that helper dir as safe to delete.
4. On ENOENT for cached codex_linux_sandbox_exe / arg0 helper paths, rebind once from the live app-server's current helper guard or recreate a helper dir, then retry.
5. Add a Windows Desktop + WSL release-gate test with:
   • CODEX_HOME on %USERPROFILE%\.codex / /mnt/c/Users/<user>/.codex
   • unified_exec=false
   • WSL app-server active
   • repeated Desktop restarts/reboots or workspace/thread switches
   • verification that shell calls still run and PATH does not point at a deleted codex-arg0* dir.

Related Issues / PRs

• #22185: earlier unified_exec=true / Windows CreateProcess(/bin/bash) failure
• #16970: stale tmp/arg0 helper dir ENOENT until restart
• #17570: proposed .pid sentinel fix for active arg0 helper dirs
• #22759: Windows Desktop + WSL config/Codex-home split
• #25216: umbrella release-gate issue for Windows Desktop + WSL