Windows Desktop + WSL2 workspace: exec_command fails before shell start; Windows elevated sandbox also fails setup refresh

[stevennitesh]

Summary

Codex Desktop on Windows appears to have two separate sandbox/runtime setup failures:

1. The elevated Windows sandbox setup/refresh path fails before command execution.
2. Desktop WSL mode fails while trying to spawn a missing or mismatched arg0/.../codex-linux-sandbox shim.

Environment

• Platform: Windows 11 + Ubuntu WSL2
• Codex App About dialog version: 26.527.31326
• Codex Desktop package: OpenAI.Codex 26.527.3686.0
• PackageFullName: OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0
• Subscription: ChatGPT Pro 20x
• Windows platform string: Microsoft Windows NT 10.0.26200.0 x64
• WSL distro: Ubuntu
• WSL version: 2

Windows helper codex.exe:

codex-cli 0.135.0-alpha.1
C:\Users\steve\AppData\Local\OpenAI\Codex\bin\7dea4a003bc76627\codex.exe

Desktop WSL app-server:

/mnt/c/Users/steve/.codex/bin/wsl/a7dedac45c162b68/codex app-server --analytics-default-enabled

Private WSL Codex binary:

codex-cli 0.135.0-alpha.1
/mnt/c/Users/steve/.codex/bin/wsl/a7dedac45c162b68/codex

Direct WSL tools are healthy:

bash=/usr/bin/bash
bwrap=/usr/bin/bwrap
bubblewrap 0.9.0

1. Windows-local repo works with the unelevated Windows sandbox

Adding this to C:\Users\steve\.codex\config.toml allows shell commands to work for a Windows-local repo:

[windows]
sandbox = "unelevated"

With Codex Desktop in Windows mode and the repo at:

E:\GitHub\StockMarket-ML-Gate

these commands work:

pwd
git status --short

This suggests the Windows repo itself, PowerShell, cmd.exe, Git, and repo permissions are not the issue.

2. Elevated Windows sandbox path still fails

The default/elevated Windows sandbox path still fails with errors like:

windows sandbox: spawn setup refresh

and:

Failed to create unified exec process: setup refresh failed with status exit code: 1

Directly checking the setup helper showed:

$setup = Get-ChildItem "$env:LOCALAPPDATA\OpenAI\Codex\bin" -Recurse -Filter "codex-windows-sandbox-setup.exe" |
  Sort-Object LastWriteTime -Descending |
  Select-Object -First 1

try {
  Start-Process -FilePath $setup.FullName -ArgumentList "--help" -NoNewWindow -Wait -PassThru
} catch {
  $_.Exception.ToString()
}

Output:

System.InvalidOperationException: This command cannot be run due to the error: The requested operation requires elevation.
   at System.Management.Automation.MshCommandRuntime.ThrowTerminatingError(ErrorRecord errorRecord)

Running Codex Desktop as administrator did not fix the normal sandbox path. It only allowed elevated/out-of-sandbox execution to work.

So for Windows-local repos, the current working workaround is:

[windows]
sandbox = "unelevated"

3. Desktop WSL mode still fails, but the failure is more specific

Direct WSL is healthy, and Codex CLI launched directly inside Ubuntu WSL works for the WSL repo.

However, non-elevated WSL commands from Codex Desktop fail because the generated arg0 sandbox shim path appears mismatched or incompletely staged.

Original WSL-mode failure for basic commands:

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

After rerunning with a TTY, the failure narrowed to a missing Linux sandbox shim:

CreateProcess { message: "Rejected(\"Failed to create unified exec process: Unable to spawn /mnt/c/Users/steve/.codex/tmp/arg0/codex-arg0aAx2wH/codex-linux-sandbox because it doesn't exist on the filesystem (ENOENT: No such file or directory)\")" }

But the generated arg0 directory visible at that time was:

C:\Users\steve\.codex\tmp\arg0\codex-arg0CW2mbB

In a later repro, the launcher tried to use:

/mnt/c/Users/steve/.codex/tmp/arg0/codex-arg0rjzLRb/codex-linux-sandbox

Polling /mnt/c/Users/steve/.codex/tmp/arg0 while triggering a failing sandboxed WSL command showed that the visible arg0 directories contained only:

.lock
applypatch.bat
apply_patch.bat

codex-linux-sandbox never appeared in the target directory.

So Desktop WSL mode appears to either:

• retain or reference a stale codex-arg0... directory, or
• generate only Windows helper files where the WSL launcher expects the Linux sandbox executable.

4. Direct WSL execution passes

Direct WSL execution outside Codex works correctly. Bash, sh, Git, repo access, temp writes, and bubblewrap all pass from PowerShell using wsl -d Ubuntu -- bash.

This PowerShell test passes:

$distro = "Ubuntu"

$script = @'
set -e
repo="/home/steve/code/StockMarket-ML-Gate"
echo "WSL_DIRECT_PROCESS_OK"
command -v bash
/bin/bash -lc "echo BIN_BASH_OK"
/usr/bin/bash -lc "echo USR_BIN_BASH_OK"
/bin/sh -lc "echo BIN_SH_OK"

cd "$repo"
pwd
git rev-parse --show-toplevel >/dev/null
git status --short >/dev/null

tmp="$(mktemp -d)"
echo hello > "$tmp/probe.txt"
cat "$tmp/probe.txt" >/dev/null
rm -rf "$tmp"
command -v bwrap >/dev/null
bwrap --version >/dev/null
bwrap --ro-bind / / --dev /dev --proc /proc --tmpfs /tmp /bin/bash -lc "echo BWRAP_EXEC_OK" >/dev/null

echo "WSL_DIRECT_ALL_CHECKS_PASSED"
'@

$script | wsl -d $distro -- bash

Output:

WSL_DIRECT_PROCESS_OK
/usr/bin/bash
BIN_BASH_OK
USR_BIN_BASH_OK
BIN_SH_OK
/home/steve/code/StockMarket-ML-Gate
WSL_DIRECT_ALL_CHECKS_PASSED

So WSL can launch shells, access the repo, run Git, write temp files, and run bubblewrap.

5. Current isolation matrix

Codex app mode	Repo location	Sandbox setting	Result
Windows mode	Windows repo	unelevated	pwd and git status --short work
Windows mode	WSL repo	unelevated	initial sandboxed WSL call denied, but rerunning with approved WSL access works
Windows mode	Windows repo	elevated/default	fails with windows sandbox: spawn setup refresh
WSL mode	Windows repo	tested current settings	command tool fails trying to spawn /bin/bash
WSL mode	WSL repo	tested current settings	fails because referenced arg0/.../codex-linux-sandbox path does not exist

6. Things already tried

• Verified direct WSL execution works.
• Verified /bin/bash, /usr/bin/bash, /bin/sh, and /usr/bin/sh work directly.
• Verified repo path and git status work directly.
• Verified temp writes work directly.
• Verified bubblewrap exists and can run a minimal sandbox.
• Set unified_exec = false in both Windows and WSL config.
• Set experimental_use_unified_exec_tool = false.
• Set shell_snapshot = false.
• Confirmed no persistent CODEX_HOME, CODEX_CLI_PATH, or NODE_REPL_NODE_PATH Windows user env vars remain.
• Moved/recreated .codex state.
• Restarted WSL and Windows.
• Tested Windows-local repo separately from WSL repo.
• Tested [windows] sandbox = "unelevated".
• Tested running Codex Desktop as administrator.
• Confirmed out-of-sandbox/elevated execution can run simple commands.

7. Current diagnosis

This no longer looks like a generic WSL or repo problem.

Current best diagnosis:

1. The elevated Windows sandbox setup/refresh path is broken.
2. The unelevated Windows sandbox works for Windows-local repos.
3. Desktop WSL mode has an arg0 sandbox shim lifecycle/staging/path mismatch.
4. In WSL mode, the command runner expects arg0/.../codex-linux-sandbox, but the generated/available arg0 directories either differ or contain only Windows .bat helpers, not the Linux sandbox binary.
5. Codex CLI launched directly inside Ubuntu WSL works for the WSL repo, so WSL itself and the repo are healthy.

Expected behavior

• Elevated Windows sandbox setup should complete or report an actionable setup error.
• Unelevated Windows sandbox should remain usable for Windows-local repos.
• Desktop WSL mode should generate and use the correct WSL/Linux sandbox shim.
• If codex-linux-sandbox is required, it should be staged into the exact arg0 directory the command runner tries to execute from.
• If the WSL Desktop sandbox path is unavailable, Codex should provide a documented safer fallback short of full danger-full-access.

Actual behavior

• Elevated Windows sandbox fails before command execution with setup refresh errors.
• Unelevated Windows sandbox works for Windows-local repos.
• Desktop WSL mode fails before command execution because the referenced arg0/.../codex-linux-sandbox path does not exist.
• The available arg0 directories contain Windows .bat helpers but not the Linux sandbox executable.

Question

Is there a known workaround to force Desktop WSL mode to regenerate and use the correct arg0 sandbox shim path, or to disable only the WSL Desktop sandbox path without switching to full danger-full-access?

The current practical workaround is to use:

[windows]
sandbox = "unelevated"

for Windows-local repos, and to run Codex CLI directly inside Ubuntu WSL for WSL repos.

[github-actions]

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

• Windows Desktop + WSL needs an end-to-end release gate across config, state, plugins, exec, and recovery #25216

Powered by Codex Action

[MisterRound]

Cross-linking a narrower follow-up issue with live fd/lock evidence: #25317.

This issue appears to cover a broader current failure set: elevated Windows sandbox setup/refresh plus Desktop WSL arg0 helper mismatch. #25317 isolates the WSL/Desktop arg0 regression specifically:

• unified_exec=false is already set in both Windows and WSL configs.
• Full OS reboot/relaunch was already attempted more than once.
• The active WSL app-server still holds an fd to the deleted tmp/arg0/codex-arg0*/.lock path.
• fdinfo shows a POSIX advisory write lock owned by the live app-server pid.
• Newer helper dirs can appear later, but the active thread remains pinned to the deleted helper path.

So #25280 and #25317 are related. The distinction is that #25317 is meant to preserve the narrower regression evidence that reboot/relaunch no longer reliably recovers the WSL helper state.