›_ Codex Issues
Codex Issues / #40583

Regression in 26.818.8289.0: native WSL arg0 mapping is required to prevent helper deletion across restart

Open 💬 0 comments Opened Aug 25, 2026 by hhhappb

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

OpenAI.Codex 26.818.8289.0

Package: OpenAI.Codex_26.818.8289.0_x64__2p2nqsd0c76g0

Active Desktop-launched WSL binary:

%USERPROFILE%\.codex\bin\wsl\97e055fd1906481c\codex

What subscription do you have?

Not collected. This is a local pre-exec runtime failure and does not appear subscription-dependent.

What platform is your computer?

  • Windows 11, version 10.0.26200, build 26200
  • WSL2 Ubuntu 24.04.4 LTS
  • WSL kernel 6.18.33.2-microsoft-standard-WSL2
  • Codex Desktop launches the app-server in WSL
  • Desktop CODEX_HOME is Windows-backed and visible in WSL as /mnt/c/Users/<user>/.codex

What issue are you seeing?

This is a current-build regression report plus a verified recovery method.

Related reports already describe stale/deleted arg0 helpers and shared Windows/WSL runtime state: #25317, #25799, #26723, #26985, and #27462. In particular, #26985 proposed splitting persistent Windows-backed CODEX_HOME from native WSL runtime cache and was closed as completed on July 29, 2026.

The same failure is still reproducible in Desktop 26.818.8289.0.

Normal non-escalated commands fail before Bash starts:

exec_command failed for /bin/bash -lc pwd:
CreateProcess {
  message: "Rejected(\"Failed to create unified exec process: No such file or directory (os error 2)\")"
}

The active codex-code-mode-host environment had this as the first PATH entry:

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

That exact directory did not exist. The live WSL app-server still held an fd and POSIX advisory lock for its deleted lock inode:

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

Additional observations:

  • Windows Developer Mode was enabled.
  • Creating a Linux symbolic link on /mnt/c succeeded, so basic symlink capability was not the remaining problem.
  • Directly recreating the missing random helper directory under the shared /mnt/c arg0 root raced with the active cleanup/janitor logic and was removed again.
  • Adding the four helper symlinks to the versioned Codex binary directory did not recover the active thread. The runtime remained bound to the exact random arg0 path.
  • Fully exiting Desktop and running wsl --shutdown alone had not made this recovery reliable before the arg0 root was moved off DrvFS.

What steps can reproduce the bug?

Observed reproduction sequence:

  1. Enable Codex Desktop WSL mode on Windows 11.
  2. Use the Desktop Windows-backed Codex home:

/mnt/c/Users/<user>/.codex from WSL.

  1. Start a Desktop WSL task and run normal restricted shell commands.
  2. After the shared arg0 helper is cleaned, switch/reopen a task or restart Desktop/WSL.
  3. Run a normal command such as pwd without approving elevated execution.
  4. Observe that execution fails before the requested shell starts.
  5. Inspect the code-mode host PATH and the app-server lock fd. PATH references a missing random helper directory while the app-server remains pinned to a deleted lock inode.

What is the expected behavior?

Windows Desktop WSL mode should not place WSL runtime-only arg0 helpers in a shared DrvFS namespace where Windows-native and WSL processes can clean or invalidate one another's helper directories.

Expected behavior:

  • Persistent Desktop auth/config/session state may remain in the Windows-backed CODEX_HOME.
  • WSL-only runtime temp data, especially tmp/arg0, should live in the native WSL filesystem.
  • A cached helper path should be checked before every process launch.
  • If it returns ENOENT, Codex should rehydrate/rebind the active helper set once and retry.
  • wsl --shutdown, Desktop restart, and task switching should not poison normal shell execution.

Additional information

Verified local recovery

The durable part of the recovery was to keep the persistent Desktop Codex home on Windows, but route the entire WSL arg0 runtime root to the native WSL filesystem.

Sanitized layout:

/mnt/c/Users/<windows-user>/.codex/tmp/arg0
    -> /home/<wsl-user>/.codex-wsl-runtime/arg0

The operation was performed only after backing up the existing arg0 directory on both the Windows-backed path and WSL side.

A safe maintenance sequence is:

set -eu

windows_codex_home=/mnt/c/Users/<windows-user>/.codex
native_runtime_base=/home/<wsl-user>/.codex-wsl-runtime
native_arg0="$native_runtime_base/arg0"
backup_tag=$(date +%Y%m%d-%H%M%S)

mkdir -p "$native_arg0"
cp -a "$windows_codex_home/tmp/arg0"   "$windows_codex_home/tmp/arg0.backup-$backup_tag"
cp -a "$windows_codex_home/tmp/arg0"   "/tmp/codex-arg0.backup-$backup_tag"

# This intentionally fails instead of deleting anything if arg0 is not empty.
rmdir "$windows_codex_home/tmp/arg0"
ln -s "$native_arg0" "$windows_codex_home/tmp/arg0"

For the already-poisoned live app-server, the exact active random directory was then recreated under the new native root with a .lock and these four links:

apply_patch
applypatch
codex-execve-wrapper
codex-linux-sandbox

All four pointed to the current Desktop-launched WSL codex binary. Because the live app-server still held a deleted DrvFS lock inode, a temporary POSIX lock holder was needed during the live-session recovery. It was configured to exit with that app-server. A product fix should not require this manual lock step.

Validation

After the native WSL arg0 mapping and exact helper recovery:

pwd
/home/<wsl-user>/projects/<workspace>

This succeeded through normal restricted execution without require_escalated.

Helper resolution also succeeded:

command -v apply_patch
/mnt/c/Users/<user>/.codex/tmp/arg0/codex-arg0<random>/apply_patch

readlink -f "$(command -v apply_patch)"
/mnt/c/Users/<user>/.codex/bin/wsl/<hash>/codex

Finally, after running wsl --shutdown and allowing Codex Desktop to start WSL again:

  • the tmp/arg0 mapping still pointed to the native WSL runtime root;
  • the four helpers were still valid;
  • another normal non-escalated pwd succeeded.

This suggests the product-level fix should implement the runtime-home split specifically for arg0 helpers (or an equivalent runtime-family/distro namespace), rather than relying only on janitor locking under the shared Windows-backed CODEX_HOME.

View original on GitHub ↗