Windows Codex app cannot launch sandboxed commands for WSL2 project

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

• #25280
• #25370
• #25317

Powered by Codex Action

I have reproduced this in new and existing Codex WSL project workspaces.

Feedback ID 019e871c-fc6c-7173-b7e8-f1f884077c65

Confirmed: the newly registered clean probe workspace fails identically in a brand-new Codex app thread.

Exact error:

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)\")"
}

This cleanly rules out:

• Existing workspace contents
• Dirty repositories
• Stale thread state
• Missing Bash
• Missing bubblewrap
• Broken WSL2
• Standalone Codex CLI sandbox issues

The failure is isolated to the Codex desktop app’s restricted WSL command bridge. Include this clean-workspace reproduction in the /feedback submission and GitHub issue.

I confirmed this is not durable across a Codex restart.

After restarting Codex Desktop, a new WSL thread failed on a trivial sandboxed command:

pwd

with the same pre-shell failure:

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

Running the local arg0 repair script fixed the active session again.

The script finds the live WSL app-server, reads the helper path from the app-server’s open .lock fd, recreates that exact helper directory from the Windows side, and adds the missing Linux helper symlinks:

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

Those symlinks point to the active app-server executable from:

/proc/$app_pid/exe

Important detail: after restart, Codex regenerated %USERPROFILE%\.codex\tmp\arg0, but the active helper dir was still incomplete for WSL use. Manually deleting tmp and bin/wsl did not permanently fix it. The repair has to target the currently active codex-arg0* dir held by the live app-server.

Minimal workaround script:

#!/usr/bin/env bash
set -euo pipefail

CODEX_HOME="${CODEX_HOME:-/mnt/c/Users/$USERNAME/.codex}"

app_pid="$(
  pgrep -f "$CODEX_HOME/bin/wsl/.*/codex app-server" | head -1 || true
)"

if [ -z "$app_pid" ]; then
  echo "No Codex WSL app-server process found" >&2
  exit 1
fi

codex_bin="$(readlink -f "/proc/$app_pid/exe")"

helper="$(
  for fd in /proc/"$app_pid"/fd/*; do
    target="$(readlink "$fd" 2>/dev/null || true)"
    case "$target" in
      "$CODEX_HOME"/tmp/arg0/codex-arg0*/.lock)
        dirname "$target"
        break
        ;;
    esac
  done
)"

if [ -z "$helper" ]; then
  echo "No active arg0 helper lock path found" >&2
  exit 1
fi

win_helper="$(wslpath -w "$helper")"
powershell.exe -NoProfile -Command \
  "New-Item -ItemType Directory -Force -LiteralPath '$win_helper' | Out-Null" \
  >/dev/null

# Do not overwrite .lock. The app-server already holds the lock fd.
for name in apply_patch applypatch codex-execve-wrapper codex-linux-sandbox; do
  ln -sfn "$codex_bin" "$helper/$name"
done

echo "Repaired Codex WSL arg0 helper: $helper"

After running it, sandboxed pwd succeeds again.

Security / side effects:

• This is a workaround, not a fix.
• It is only valid for the active app-server process.
• It should not modify arbitrary codex-arg0* dirs.
• It should not overwrite .lock.
• The helper directory is PATH-prepended for tool execution, so the symlinks must point only to the trusted active Codex executable.
• On shared/untrusted systems, writable %USERPROFILE%\.codex\tmp\arg0 helper dirs are security-sensitive.
• Once Codex ships a fix, close Codex and remove only transient arg0 state:

%USERPROFILE%\.codex\tmp\arg0

I have the exact same problem with Codex 26.601.21317.

I have the exact same problem with Codex 26.601.10930
No solutions yet.

I’m still experiencing the same problem, even with the latest Codex version released today: 26.602.30954. I can’t do anything in Codex right now. This issue needs to be fixed as soon as possible. I'm a Pro user.

WSL was working on a Codex app instance left open on my laptop:

Codex Desktop app: 26.519.81530
Codex CLI:         0.133.0

<img width="2880" height="1704" alt="Image" src="https://github.com/user-attachments/assets/6ed34502-545f-48d1-a06c-7bfdbcebae9d" />

so it is now working with the new update?

so it is now working with the new update?

No. I am just giving a reference point before the regression.

I've seen this for about a week, it seems that the windows .bat helpers are being created instead of the linux ones for me, still happening with 26.602.40724

laverya@framework:~$ ls /mnt/c/Users/laver/.codex/tmp/arg0/*
/mnt/c/Users/laver/.codex/tmp/arg0/codex-arg0cPwxf8:
apply_patch.bat  applypatch.bat

/mnt/c/Users/laver/.codex/tmp/arg0/codex-arg0mGaeSS:
apply_patch.bat  applypatch.bat

EDIT: After running the script above, I see _one_ session with the linux helpers, but a number of other sessions created after it returned to the .bat helpers. I really don't understand this.

laverya@framework:~$ ls /mnt/c/Users/laver/.codex/tmp/arg0/*
/mnt/c/Users/laver/.codex/tmp/arg0/codex-arg0FL6Cpu:
apply_patch.bat  applypatch.bat

/mnt/c/Users/laver/.codex/tmp/arg0/codex-arg0NYvXM4:
apply_patch.bat  applypatch.bat

/mnt/c/Users/laver/.codex/tmp/arg0/codex-arg0RqkWD5:
apply_patch  applypatch  codex-execve-wrapper  codex-linux-sandbox

/mnt/c/Users/laver/.codex/tmp/arg0/codex-arg0cPwxf8:
apply_patch.bat  applypatch.bat

/mnt/c/Users/laver/.codex/tmp/arg0/codex-arg0mGaeSS:
apply_patch.bat  applypatch.bat

/mnt/c/Users/laver/.codex/tmp/arg0/codex-arg0qQmA3k:
apply_patch.bat  applypatch.bat

/mnt/c/Users/laver/.codex/tmp/arg0/codex-arg0rBPZNC:
apply_patch.bat  applypatch.bat

EDIT2: despite still having .bat files, new sessions appear able to run commands within the sandbox (pwd, date, curl etc - curl helpfully fails when it attempts to reach the open internet, because it's sandboxed)

I’m seeing the same issue after the recent Codex Desktop update.

Environment:

• OS: Windows
• WSL distro: Ubuntu
• WSL version: 2
• Codex Desktop app: Version 26.602.71036
• Agent environment: Windows Subsystem for Linux
• Integrated terminal: WSL
• Workspace path: WSL filesystem, e.g. /home/ser/code/OZE

Error:

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)\")" }

Observed behavior:

• WSL workspaces fail in Codex Desktop.
• Even a basic pwd command fails when using the WSL agent.
• The app stays on “thinking” for a long time, around 1 minute, before the response starts or fails.
• The task timer appears to start only after that delayed initialization phase.
• The diff/review panel incorrectly shows massive deletions, for example +0 -79,210, as if the repo contents disappeared.
• However, the files are still present and normal inside WSL.

What I verified:

• wsl -l -v shows Ubuntu running on WSL2.
• /bin/bash -lc pwd works fine directly inside WSL.
• /bin/bash -lc pwd also works when called from PowerShell through WSL.
• bwrap exists and basic bubblewrap tests succeed.
• Codex CLI inside WSL works normally.
• Windows native agent + PowerShell + a Windows filesystem project works normally in Codex Desktop.
• So the issue seems specific to Codex Desktop’s WSL agent / unified exec path.

What I tried:

• Updated Codex CLI inside WSL.
• Fully quit and restarted Codex Desktop.
• Reinstalled Codex Desktop.
• Removed and re-added the WSL project.
• Added the following to %USERPROFILE%\.codex\config.toml:

[features]
unified_exec = false
shell_snapshot = true

• Removed %USERPROFILE%\.codex\tmp\arg0.
• Removed ~/.codex/tmp/arg0 inside WSL.
• Ran wsl --shutdown and restarted Codex Desktop.

None of the above fixed the issue.

This looks like a regression in Codex Desktop’s WSL execution path after the recent update. The important detail is that WSL itself, /bin/bash, bwrap, the repo, and Codex CLI are all working normally; only Codex Desktop in WSL agent mode fails.

Update: I updated Codex Desktop from 26.602.71036 to 26.608.12217, but the issue still persists.

WSL agent mode still fails even for:

/bin/bash -lc pwd

The app reports:

No such file or directory (os error 2)

The working directory is still detected as /home/ser/code/OZE, but the shell process cannot be created. Windows native agent + PowerShell still works normally. So this still appears to be specific to the Windows Desktop + WSL execution path.

I've updated the bash script based on poroburu post, as shown below:

#!/usr/bin/env bash
set -euo pipefail

CODEX_HOME="${CODEX_HOME:-/mnt/c/Users/myuser/.codex}"

if [ ! -d "$CODEX_HOME" ]; then
  echo "CODEX_HOME does not exist: $CODEX_HOME" >&2
  exit 1
fi

app_pid="$(
  pgrep -f "$CODEX_HOME/bin/wsl/.*/codex app-server" | head -1 || true
)"

if [ -z "$app_pid" ]; then
  echo "No Codex WSL app-server process found." >&2
  echo "Open Codex Desktop first with Agent environment = WSL, then run this script from Debian." >&2
  exit 1
fi

codex_bin="$(readlink -f "/proc/$app_pid/exe")"

if [ -z "$codex_bin" ] || [ ! -x "$codex_bin" ]; then
  echo "Could not resolve executable for Codex app-server process: $app_pid" >&2
  exit 1
fi

helper="$(
  for fd in /proc/"$app_pid"/fd/*; do
    target="$(readlink "$fd" 2>/dev/null || true)"
    case "$target" in
      "$CODEX_HOME"/tmp/arg0/codex-arg0*/.lock)
        dirname "$target"
        break
        ;;
    esac
  done
)"

if [ -z "$helper" ]; then
  echo "No active arg0 helper lock path found." >&2
  exit 1
fi

echo "Codex app-server PID: $app_pid"
echo "Codex binary: $codex_bin"
echo "Helper directory: $helper"

win_helper="$(wslpath -w "$helper")"

powershell.exe -NoProfile -Command \
  "[System.IO.Directory]::CreateDirectory('$win_helper') | Out-Null" \
  >/dev/null

for name in apply_patch applypatch codex-execve-wrapper codex-linux-sandbox; do
  ln -sfn "$codex_bin" "$helper/$name"
done

echo
echo "Repaired Codex WSL arg0 helper:"
echo "  $helper"

Currently, I need to run this on Debian 13 (WSL) for each chat thread and every time I open Codex Desktop (on Windows). For now, this works as a temporary workaround for me.

I seem to be able to use WSL2 in codex after latest update: Version 26.609.30741 • Released Jun 11, 2026

It still happens in Codex App (currently it becomes ChatGPT Desktop) with WSL2, Codex 0.144.5.
I have already changed the agent setting to "Windows Subsystem for Linux" and shell to "WSL", but it still usually says something like "it can't see /home/... in Windows sandbox" and requires executing outside the sandbox.

I added a small diagnostic CLI after seeing several Windows/WSL reports like this one:

npx --yes codex-doctor

Repo: https://github.com/warren2008-2020-spec/codex-doctor

Right now it checks the general setup layer: platform/WSL signals, Node/npm, Git/GitHub CLI, Codex CLI, Codex config, proxy hints, and CI signals. It is read-only and does not try to repair the arg0 helper directory.

Given the details in this thread, I think the next useful checks would be more specific:

• whether the active Codex WSL app-server exists
• whether %USERPROFILE%\.codex\tmp\arg0\codex-arg0* contains Linux helpers or only .bat helpers
• whether codex-linux-sandbox / codex-execve-wrapper are present for the active helper dir
• whether WSL sees the workspace as /home/... vs /mnt/c/...
• whether bwrap is available inside WSL

I am going to add those as read-only checks rather than a repair script, because the repair path is security-sensitive. If anyone here has a current failing machine and can share what signal would be most useful in a safe report, I can tune the output around this issue.