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

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:

Enable Codex Desktop WSL mode on Windows 11.
Use the Desktop Windows-backed Codex home:
/mnt/c/Users/<user>/.codex from WSL.
Start a Desktop WSL task and run normal restricted shell commands.
After the shared arg0 helper is cleaned, switch/reopen a task or restart Desktop/WSL.
Run a normal command such as pwd without approving elevated execution.
Observe that execution fails before the requested shell starts.
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.

I investigated a related pre-exec failure and documented a local mitigation in #44918: placing Linux helpers under a separate tmp/arg0-linux directory. Focused tests verified isolation from cleanup under the legacy directory. We did not identify the historical process that removed the helper, so this is mitigation evidence rather than confirmation of the same root cause.

I encountered the same failure today, September 29, 2026, on desktop app version 26.928.20755, using Windows + WSL.

Commands stopped working after an app update this morning. A subsequent Microsoft Store update and fully restarting the desktop app/server did not resolve it. My own WSL terminal continued working normally, and the app's Agent environment was set to WSL.

All desktop agent shell commands, including pwd, failed before execution with:

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

The desktop's WSL app-server held an open file descriptor to an arg0/<helper-directory>/.lock path whose parent directory no longer existed. The remaining directory under the shared Windows-backed CODEX_HOME/tmp/arg0 contained only .lock, apply_patch.bat, and applypatch.bat.

After restarting the server, the same mismatch recurred with a new PID and new helper directory names. For example, the server referenced codex-arg0B0U9e4/.lock, while the directory on disk was codex-arg0uAFk7x with Windows wrappers.

Moving the original tmp/arg0 directory aside as a backup and symlinking that path to a directory on WSL's native Linux filesystem restored execution. The desktop agent then successfully ran pwd, resolved codex-linux-sandbox, and ran git status --short --branch. Chat history and configuration remained in place.

I haven't yet verified persistence across another restart or update. We also haven't identified which process removed the Linux helper directory, so this confirms the failure pattern and successful mitigation rather than the exact underlying cause.

Is there a confirmed fixed release or a planned fix, and is this workaround expected to remain compatible with upcoming releases?

I’m seeing a very similar issue after a recent desktop update.

Environment:

Desktop version: 26.928.20755
Windows package: 26.928.1915.0
Bundled WSL CLI: 0.159.0
WSL2, Ubuntu 24.04

Read-only diagnostics confirmed:

Ordinary sandboxed exec_command calls fail before Bash starts, even for pwd.
With tty enabled, the error identifies a missing helper:
/mnt/c/Users//.codex/tmp/arg0/codex-arg0/codex-linux-sandbox
That entire helper directory is missing, but the running WSL app-server still holds a file descriptor and POSIX advisory lock referencing its .lock file.
The shared tmp/arg0 directory contains only another directory with .lock, apply_patch.bat, and applypatch.bat.
The identical pwd command succeeds with require_escalated. WSL, Bash, and the repository directory are accessible.
Logs show a native Windows Local Work executor starting shortly after the WSL app-server. The remaining arg0 directory’s timestamp coincides with that startup.

Separately, the Windows node_repl.exe rejects the WSL workspace URI:
sandboxCwd is not a local file URI: file:///home//

These observations support the shared Windows/WSL helper-cache hypothesis, but we have not identified the process that deleted the Linux helper directory or proven that the update caused it.

No configuration changes or workaround patches were applied. Is there an officially supported workaround or a confirmed fixed release?

Confirming this workaround resolved the failure in the ChatGPT Windows desktop app's Codex view, using WSL and bundled Codex CLI 0.159.2.

The desktop runner failed because its session-specific codex-linux-sandbox helper was missing. The same binary successfully ran a standalone sandbox test from WSL. Application repair and reinstallation did not help.

With the app fully closed, I renamed the Windows-backed tmp/arg0 directory as a backup and replaced it with a symlink to a fresh directory on the native WSL filesystem. Normal and PTY shell execution then succeeded, including after an additional full restart of the ChatGPT desktop app.

No manual helper-link recreation, lock handling, or disabling of sandbox protections was needed. WSL shutdown and Windows reboot remain untested; the underlying cleanup race was not independently confirmed.

Recovery script (anonymized paths)

Run from an independent WSL terminal with the desktop app fully closed and other Codex sessions using the same Windows-backed home stopped. Replace both placeholder paths before running. Keep the printed backup path for rollback.

bash <<'BASH'
set -eu

windows_codex_home='/mnt/c/Users/<windows-user>/.codex'
native_runtime_base='/home/<wsl-user>/.codex-wsl-runtime'

windows_arg0="${windows_codex_home}/tmp/arg0"
backup_tag=$(date +%Y%m%d-%H%M%S)
backup_arg0="${windows_arg0}.backup-${backup_tag}"
native_arg0="${native_runtime_base}/arg0-${backup_tag}"

if [ ! -d "$windows_arg0" ] || [ -L "$windows_arg0" ]; then
  echo "STOP: arg0 is missing or is already a symbolic link."
  exit 1
fi

test ! -e "$backup_arg0"
test ! -e "$native_arg0"
mkdir -p -- "$native_arg0"
mv -- "$windows_arg0" "$backup_arg0"

if ! ln -s -- "$native_arg0" "$windows_arg0"; then
  mv -- "$backup_arg0" "$windows_arg0"
  echo "STOP: link creation failed; original directory restored."
  exit 1
fi

printf 'BACKUP=%s\nTARGET=%s\n' "$backup_arg0" "$native_arg0"
ls -ld -- "$windows_arg0"
BASH

Relaunch the desktop app and test shell execution. This preserves the original directory rather than deleting it; it does not move authentication, configuration, conversation databases, or project files.

Confirming the native WSL arg0 mapping workaround also works on Windows on ARM64.

Environment

Codex Desktop 26.928.21956
Windows 11 ARM64 (Snapdragon X2 Elite Extreme), build 28000
WSL2, repos on the Linux filesystem

Before: In Desktop WSL mode, normal sandboxed commands failed before the shell started with ENOENT on /mnt/c/Users/<user>/.codex/tmp/arg0/codex-arg0<random>/codex-linux-sandbox. Restarting the app produced a new arg0 path, but the helper was still missing. Escalated commands worked. I run separate reviewer and implementer sessions concurrently.

Applied (with Desktop fully closed and no Desktop WSL processes running):

mkdir -p "$HOME/.codex-wsl-runtime/arg0"
mv /mnt/c/Users/<user>/.codex/tmp/arg0 /mnt/c/Users/<user>/.codex/tmp/arg0.backup-<timestamp>
ln -s "$HOME/.codex-wsl-runtime/arg0" /mnt/c/Users/<user>/.codex/tmp/arg0

After: In a fresh chat, pwd, git status --short, command -v codex-linux-sandbox, and readlink -f on the helper all succeeded with normal sandboxed execution and no escalation. The helper resolves to the Desktop WSL binary under .codex/bin/wsl/<hash>/codex.

This suggests the issue isn't architecture-specific. +1 to making the arg0 runtime-home split the product fix.

Confirmed on desktop version 26.928.21956 (build 12404), with an isolated reproduction identifying native Windows codex.exe exec-server startup as a trigger for deleting a live WSL helper directory.

Environment and impact

Windows package: OpenAI.Codex 26.928.2636.0.
Ubuntu on WSL2; desktop-bundled Linux CLI: codex-cli 0.159.2.
Desktop update check reports up_to_date.
WSL app-server and native Windows Local Work executor share the Windows-backed Codex home: C:\Users\<user>\.codex, seen in WSL as /mnt/c/Users/<user>/.codex.

Every normal sandboxed exec_command fails before the shell starts, including pwd in /tmp:

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

Fully terminating the desktop app in Task Manager and reopening it did not fix the failure. Approved unsandboxed diagnostic execution succeeds; the Linux shell, project directory, and project files are accessible.

The live WSL app-server retains an open file descriptor and POSIX advisory write lock for tmp/arg0/codex-arg0<id>/.lock, but that directory is no longer accessible by pathname. Its Linux helper links are missing. The remaining shared cache contains Windows apply_patch.bat / applypatch.bat wrappers instead.

Isolated reproduction

This was reproduced using a dedicated scratch directory on the Windows filesystem as CODEX_HOME. No existing authentication, configuration, project files, or conversation state was copied into it.

Start the installed Linux codex app-server in WSL with that scratch CODEX_HOME, keeping its stdin open.
Confirm tmp/arg0/*/codex-linux-sandbox exists.
Start the installed native Windows codex.exe exec-server with the Windows path to the same physical scratch directory as CODEX_HOME. Use the plain local command, without --remote; no task needs to be submitted.
Wait until a Windows apply_patch.bat appears under tmp/arg0.
Check the original Linux helper while its app-server is still alive.

Observed results:

LINUX_HELPER_BEFORE_WINDOWS_EXEC_SERVER True
NATIVE_WINDOWS_HELPER_CREATED True
LINUX_TEST_PROCESS_STILL_RUNNING True
LINUX_HELPER_AFTER_WINDOWS_EXEC_SERVER False
ISOLATED_TEST_CLEANED_UP True

All isolated test processes and scratch directories were cleaned up. Existing desktop/Work processes and user configuration were left unchanged.

In the actual affected desktop session, a native Windows Local Work executor (exec-server --remote ...) starts alongside the WSL app-server. The isolated test establishes the cross-platform deletion trigger; the precise cleanup/locking implementation responsible was not inspected.

Expected behavior

Starting a Windows executor must preserve live WSL helper directories. Platform-specific temporary helper namespaces, or cleanup that reliably recognizes live processes across Windows/WSL, would prevent this startup sequence from invalidating the WSL sandbox launcher.

Separate dependency repair symptom

Settings → workspace dependencies → reset/reinstall also fails after downloading the bundle, during plugin synchronization:

Failed to sync primary runtime bundled plugin marketplace
marketplace `openai-primary-runtime` is reserved and cannot be added from this source

Logged fields: bundle 26.921.10847, target win32-x64, stage sync_plugins, category post_install_failed. Similar initialization errors are recorded in #49365. A causal relationship between this registration error and helper deletion has not been established.

Only sanitized observations are included above; no credentials, project identifiers, raw session logs, or personal filesystem paths are attached.

I am seeing the same thing here, Win11 + WSL2 (desktop app set to run inside WSL), on ARM. Bypass permissions mode works fine, but I don't want to use that.

Same issue on my end (I believe)
How do they always introduce new bugs in respect with WSL.
This is now the fourth or fifth time, WSL related issues completely break the app.

Even if it wasn't broken it's still a compromise. I would love if we could use both a Windows host + WSL host together in the app instead of having to choose one.

I switched to Paseo for most of my work and it's great for this. I was able to install the paseo daemon in WSL and on another machine on my network and have all 3 environments seamlessly together in the desktop app and phone app.

I’m seeing what looks like the same failure pattern on a newer Desktop build.

Environment:

ChatGPT Plus
ChatGPT/Codex Desktop app version: 26.930.31730
Windows 11, Version 26H2, OS Build 26300.9457
Ubuntu under WSL
Agent environment: Windows Subsystem for Linux
repo located under /home/<user>/projects/<repo>
project added through \\wsl$\Ubuntu\home\<user>\projects\<repo>

Observed behaviour:

pwd initially succeeded and returned the expected WSL repository path.
A subsequent git status --short failed before command execution with:

Unable to run git status --short: the command runner could not start a shell (os error 2: No such file or directory).
Earlier attempts also produced:

helper_unknown_error: setup refresh had errors

WSL itself appears healthy:

Codex CLI works correctly inside the same WSL distribution against the same repository.
Git works normally from WSL.
codex doctor reports:
20 ok, 0 warn, 0 fail

Troubleshooting already attempted:

confirmed Agent environment = Windows Subsystem for Linux
fully restarted the desktop app
deleted/recreated the Desktop project
initially tested a \\wsl.localhost\... path
retested using the Support-recommended \\wsl$\... path
verified the same repository works from Codex CLI inside WSL

This looks consistent with the pre-exec WSL helper failure described in this issue, where Desktop cannot start the sandbox/shell process even though WSL itself is healthy.

OpenAI Support asked me to submit the failing Desktop session through in-app feedback and include the resulting session ID on GitHub.

Session ID:
01a108a6-db78-7c41-a8e6-44961e7f0f95

I have not yet applied the tmp/arg0 symlink workaround described in this issue.

If useful, I can provide sanitized diagnostics from:

WSL: ~/.codex/sessions
Windows: %USERPROFILE%\.codex

I’ve intentionally omitted private repository names, usernames, remotes, server details and other project-specific identifiers from this public report.

Follow-up: I ran read-only diagnostics and this appears to match the missing arg0 helper condition described in this issue.

The Desktop-launched WSL app-server is alive and holds an fd to:

/mnt/c/Users//.codex/tmp/arg0/codex-arg0/.lock

However, a read-only listing of:

/mnt/c/Users//.codex/tmp/arg0

shows no child helper directories.

The corresponding codex-code-mode-host process has this as its first PATH entry:

/mnt/c/Users//.codex/tmp/arg0/codex-arg0

and that path is MISSING.

Meanwhile, Codex CLI running natively inside WSL continues to work normally.

So on my system the Desktop WSL process is referencing an arg0 helper directory that no longer exists, which appears consistent with the failure mechanism documented here.

Session ID:
01a108a6-db78-7c41-a8e6-44961e7f0f95

Desktop version: 26.930.31730
Windows 11 26H2, OS Build 26300.9457

No workaround or filesystem mutation has been applied yet; these observations were read-only.

Follow-up #2:

Confirmed on my system. Before workaround, the Windows-backed tmp/arg0 was empty while the Desktop WSL app-server/code-mode host referenced a missing codex-arg0... helper directory, causing pre-exec os error 2.
I fully closed Codex Desktop, moved the existing Windows-backed tmp/arg0 aside, and replaced it with a symlink to a native WSL directory. After restarting Desktop, both pwd and git status --short work, including after a second full Desktop restart. The native WSL target is now populated with the expected codex-arg0... directory, .lock, and helper symlinks.
Session ID: 01a108a6-db78-7c41-a8e6-44961e7f0f95
Desktop: 26.930.31730
Windows 11 26H2, build 26300.9457

Confirming the same regression on a newer Codex Desktop build.

Environment

Codex Desktop: 26.930.31730 (build 12947)
Bundled WSL CLI: codex-cli 0.160.0
Windows build: 10.0.26300.9550
WSL2 distro: Ubuntu 24.04.5 LTS
WSL kernel: 6.18.40.1-microsoft-standard-WSL2
bubblewrap: 0.9.0
Workspace is on the native WSL filesystem under /home/..., not under /mnt/c

Failure

Normal restricted commands such as pwd and git status fail before Bash starts:

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

The same read-only commands succeed when sandbox execution is bypassed/approved, so the repository, shell, and Git are healthy.

Definitive arg0 evidence

The live codex-code-mode-host process has this as the first PATH entry:

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

That exact directory does not exist:

ls: cannot access '.../codex-arg0xQXbgC': No such file or directory

The current arg0 root instead contains a different random directory:

.../.codex/tmp/arg0/codex-arg0lY97cx/

That new directory contains .lock and all four valid helper symlinks:

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

All four resolve to the current bundled WSL Codex binary. This shows the live code-mode host retained a stale/deleted arg0 path while a replacement helper directory was created.

Controls and attempted recovery

unshare -Ur true: succeeds
Minimal bwrap launch: succeeds
bwrap --version: 0.9.0
WSL updated and fully shut down/restarted
Codex confirmed current through Microsoft Store
Desktop fully restarted
%USERPROFILE%\.codex\bin\wsl cache renamed and regenerated
Failure persists in normal restricted execution

A historical .sandbox/sandbox.log entry from an older app build also records SetNamedSecurityInfoW failed: 5 while granting a read ACE to the old WindowsApps resources directory. This may be unrelated to the current WSL arg0 failure and is included only as a secondary signal.

No credentials, sandbox secrets, project contents, or machine SID are included here.

Additional affected installation confirmed on 2026-10-05, using the Desktop-bundled codex-cli 0.160.0. This matches the missing live arg0 helper-directory pattern in this issue.

Environment

Codex Desktop on Windows, with the agent and integrated terminal configured for WSL.
Ubuntu 22.04.5 LTS under WSL2.
Kernel: 5.15.167.4-microsoft-standard-WSL2.
Desktop app version was not independently collected; the CLI version above was verified.
CODEX_HOME=/mnt/c/Users/<windows-user>/.codex.
Workspace on the native Linux filesystem, under /home/<wsl-user>/....
findmnt reports 9p for the original Windows-mounted helper location and ext4 for the native Linux recovery location.
sandbox_mode = "workspace-write".

Failure and control

Ordinary exec_command calls failed before the requested shell command ran:

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

Explicit bash, sh, and zsh paths, and both the workspace and /tmp as cwd, produced the same failure. The integrated WSL terminal could list the workspace normally.

The identical /bin/zsh + workspace + pwd command succeeded with individually approved execution outside the sandbox. This narrowed the problem to the sandbox launch path rather than the shell or workspace.

Additional filesystem evidence

The live WSL app-server still held a file descriptor pointing to:

/mnt/c/Users/<windows-user>/.codex/tmp/arg0/codex-arg0<active-id>/.lock

However, the corresponding active directory was absent from the parent listing, and lstat, stat, and listdir on that exact directory all returned ENOENT.

Attempting to recreate that same directory with Python Path.mkdir(exist_ok=True) returned EEXIST:

FileExistsError: [Errno 17] File exists

This ENOENT/EEXIST mismatch prevented simple in-place recreation. We did not trace the deleting process or establish the underlying Windows delete/locking state, so this is an observed filesystem inconsistency, not proof of a particular cleanup implementation.

Verified local recovery

We preserved the original helper directory as a backup, copied its remaining contents to a user-owned native WSL directory, recreated the active directory's four helper symlinks to the same installed WSL Codex executable, and redirected the original tmp/arg0 path to that native directory:

/mnt/c/Users/<windows-user>/.codex/tmp/arg0
    -> /home/<wsl-user>/.cache/<native-helper-directory>

The restored helpers were codex-linux-sandbox, codex-execve-wrapper, apply_patch, and applypatch.

Because this was a live-session repair and the app-server retained its original lock handle, a temporary process holds an exclusive flock on the new active directory's .lock. It is configured to exit when the original app-server exits, checking both PID and process start time.

No sandbox policy, network policy, authentication data, configuration file, or project source file was changed.

Validation and limits

After recovery, normal sandboxed execution without require_escalated successfully:

ran pwd through zsh and executed a command through the default shell;
created, read, updated, and deleted temporary workspace files;
resolved all four helper paths;
confirmed the new active directory lock was held.

Temporary test files were removed, and normal sandboxed workspace I/O passed again during subsequent report preparation.

This is a verified local workaround, not an upstream fix. Persistence after a full Desktop/WSL restart or upgrade has not been tested on this installation. We have not established a deterministic trigger or identified the process responsible for invalidating the original helper directory.

Please include CLI 0.160.0 / Ubuntu 22.04.5 in the affected-environment evidence, and investigate helper-directory lifetime/cleanup on Windows-backed CODEX_HOME, safe recovery of missing active helpers, and error messages that identify the missing executable path.

Submitted at the affected user's request. Usernames, project paths, conversation IDs, credentials, and raw session logs are omitted.

Still reproducible after updating to Desktop 26.930.7945.0, with both bundled Windows and WSL binaries reporting codex-cli 0.160.1 (WSL2, Ubuntu 24.04).

I tested the deletion directly using a fresh, empty CODEX_HOME on the Windows filesystem, without copying my configuration or manually recreating helpers:

Start the Linux codex app-server --listen stdio:// with that test home and keep it running. It creates its tmp/arg0/codex-arg0*/ directory, .lock, and helper symlinks.
Run Linux codex --version against the same home: the live app-server's helper directory survives.
Run Windows codex.exe --version against the same home, using the corresponding C:\... path: the live Linux helper directory, including codex-linux-sandbox, is deleted. The Linux app-server is still running.

The startup cleanup is in janitor_cleanup, which attempts to lock each directory before deleting it. In this setup, the Windows cleanup does not preserve the directory owned by the live WSL process.

This reproduces a deletion mechanism, rather than only observing a missing helper after restart. It does not identify which Windows invocation deleted my original session's helpers. The test process and isolated test home were removed afterwards.

Verified recovery: use a Linux-native CODEX_HOME only for Codex Desktop WSL sessions

I verified another working recovery for this Windows Codex Desktop + WSL sandbox/helper issue.

Symptom

When using Codex Desktop with the agent running in WSL, normal non-elevated commands in the WSL project could fail through the sandbox/helper execution path.

The project itself and the WSL user environment were accessible, but normal Codex sandbox execution did not work correctly.

Recovery approach

The working solution was to separate the Codex Desktop WSL helper/runtime environment from the Windows-backed filesystem and give Codex Desktop WSL sessions a dedicated CODEX_HOME on the native Linux filesystem.

In my environment:

WSL user: vdiuser
Linux home: /home/vdiuser

Dedicated Codex Desktop CODEX_HOME:
/home/vdiuser/.codex-desktop

First, I prepared:

/home/vdiuser/.codex-desktop

Before switching CODEX_HOME, I preserved the existing Codex configuration, authentication, and session information required by the environment.

I did not delete the existing authentication or session data.

Then I added the following conditional configuration to:

/home/vdiuser/.bash_profile

20261007 SH Codex Desktop: separate WSL temporary helpers onto the Linux filesystem

if [ "${CODEX_INTERNAL_ORIGINATOR_OVERRIDE:-}" = "Codex Desktop" ]; then
if [ -d /home/vdiuser/.codex-desktop ]; then
export CODEX_HOME=/home/vdiuser/.codex-desktop
fi
fi

Why the conditional override is important

I did not globally change CODEX_HOME for every WSL shell.

The override is applied only when:

CODEX_INTERNAL_ORIGINATOR_OVERRIDE="Codex Desktop"

Therefore, the behavior is:

Normal WSL login/session
-> existing environment remains unchanged

Codex Desktop -> WSL
-> CODEX_HOME=/home/vdiuser/.codex-desktop

This allows the Codex Desktop WSL helper/runtime files to live on the native Linux filesystem without unnecessarily changing normal WSL sessions.

Important preparation step

Do not simply create an empty .codex-desktop directory and immediately switch CODEX_HOME.

Before enabling the override, make sure the dedicated Linux-side CODEX_HOME has access to the existing Codex state required by your installation.

In particular:

preserve authentication;
preserve required configuration;
preserve required session state;
do not delete existing authentication/session files;
do not expose authentication contents;
keep the temporary helper/runtime files on the native Linux filesystem.

The exact files that need to be preserved or connected should be checked against the existing installation rather than blindly deleting or copying the entire Codex directory.

Validation

I first checked the shell profile syntax:

/bin/bash -n ~/.bash_profile

Then I completely exited Codex Desktop and started it again.

From Codex Desktop, using normal non-elevated WSL execution in the actual project directory, I verified:

pwd
printenv CODEX_HOME

pwd successfully returned the actual WSL project path.

CODEX_HOME returned:

/home/vdiuser/.codex-desktop

After this change:

normal non-elevated WSL execution worked;
the actual WSL project directory was accessible;
the Codex Desktop WSL environment used the Linux-native CODEX_HOME;
existing authentication remained usable;
existing configuration remained usable;
existing session state remained available;
the sandbox/helper execution problem was resolved in this environment.

Recommendation for affected users

I recommend checking the affected machine before applying this change.

First verify:

whoami
echo "$HOME"
pwd
printenv CODEX_HOME

If normal Codex Desktop WSL sandbox execution is already working, I would not apply this change preventively.

Before modifying .bash_profile, make a backup, for example:

cp ~/.bash_profile ~/.bash_profile.backup-$(date +%Y%m%d-%H%M%S)

Also replace /home/vdiuser in the example above with the actual WSL user's home directory.

This is a locally verified recovery method from a real affected environment. I am reporting the observed recovery rather than claiming that this identifies the complete upstream root cause.

I hope this helps other Windows + WSL Codex Desktop users who are currently blocked by the same sandbox/helper execution problem.

If maintainers or affected users need additional sanitized details about the configuration or validation procedure, feel free to contact me:

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

Description

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

What subscription do you have?

What platform is your computer?

What issue are you seeing?

What steps can reproduce the bug?

What is the expected behavior?

Additional information

Verified local recovery

Validation

Activity

Bruce-anle commented on Sep 12, 2026

902msa commented on Sep 29, 2026

youngcs1024 commented on Sep 30, 2026

narwajea commented on Sep 30, 2026

brian-yuen84 commented on Sep 30, 2026

GitJuuuN commented on Sep 30, 2026

Environment and impact

Isolated reproduction

Expected behavior

Separate dependency repair symptom

RyanEwen commented on Sep 30, 2026

fbernklau commented on Oct 4, 2026

RyanEwen commented on Oct 4, 2026

jfletch2424 commented on Oct 4, 2026

fhyyh123 commented on Oct 4, 2026

Environment

Failure

Definitive arg0 evidence

Controls and attempted recovery

xu62u4u6 commented on Oct 5, 2026

Environment

Failure and control

Additional filesystem evidence

Verified local recovery

Validation and limits

LookAsPelc commented on Oct 6, 2026

xrpia999-ship-it commented on Oct 7, 2026

Verified recovery: use a Linux-native CODEX_HOME only for Codex Desktop WSL sessions

Symptom

Recovery approach

20261007 SH Codex Desktop: separate WSL temporary helpers onto the Linux filesystem

Why the conditional override is important

Important preparation step

Validation

Recommendation for affected users

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions