Symptom

On Windows with "Run agent in WSL" on, every sandboxed command fails before it starts, even pwd. Commands approved outside the sandbox still work. The .codex/tmp/arg0 folder often holds only Windows .bat helpers and no codex-linux-sandbox.

Evidence what you'll see

Error: Failed to create unified exec process: No such file or directory (os error 2)
Users still reproduced it on Desktop 26.1007.71326 after the issue was closed

Cause

Community diagnosis, not a staff post: the Linux app-server and a Windows exec-server share one CODEX_HOME on the Windows drive. Each clears helper folders it can lock, and Linux and Windows locks cannot see each other, so one side deletes the other's live sandbox helper.

Fix steps

0 of 5 done

Step 1Community workaround: bind-mount a Linux folder over the arg0 path. Back up /etc/fstab first.
Step 2mkdir -p ~/.codex-arg0-wsl && chmod 700 ~/.codex-arg0-wsl
Step 3Add /home/<linux-user>/.codex-arg0-wsl /mnt/c/Users/<WindowsUser>/.codex/tmp/arg0 none bind,nofail 0 0 to /etc/fstab, then run sudo mount --bind with the same two paths.
Step 4Quit the Desktop app fully (including the tray), run wsl --shutdown in PowerShell, then reopen the app.
Step 5Other interim options: approve each command outside the sandbox, or use Windows agent mode.

Your check marks stay in this browser only.

Verify the fix worked

findmnt /mnt/c/Users/<WindowsUser>/.codex/tmp/arg0 shows your Linux filesystem as the source.
A codex-arg0* folder with a codex-linux-sandbox link appears there after the app starts.
pwd runs in a sandboxed session without escalation.

Did this fix it?

Sources and credit

Summarized in our own words from these public reports. Credit goes to their authors.

Provided as is, without warranty. Test in a non-production environment and back up first. Security-related steps: verify against the official docs. Terms · Request removal or attribution change