Possible Windows native sandbox regression: CreateProcessAsUserW failed: 2 on 0.153.4, works on 0.132.0

Body:

Summary

This may be environment-specific, but on the same machine and Windows installation, Codex 0.132.0 works correctly while Codex 0.153.4 consistently fails to start any Windows native sandbox child process.

Codex 0.153.4 fails with:

CreateProcessAsUserW failed: 2 (The system cannot find the file specified)

The same sandbox command succeeds with Codex 0.132.0.

Environment

• Windows 11 Professional
• OS version: 10.0.26200
• 64-bit
• Codex CLI: 0.153.4
• Install method: standalone Windows build
• Codex Desktop: 26.901.6511.0

Doctor result

codex doctor --json reports the Windows sandbox as healthy:

• sandbox.helpers: ok
• filesystem sandbox: unrestricted
• network sandbox: enabled
• sandbox backend: elevated
• sandbox provisioning: complete

The rest of the installation/runtime checks are also reported as healthy, except unrelated warnings.

Reproduction on 0.153.4

codex sandbox windows C:\Windows\System32\cmd.exe /c echo OK
Result:
windows sandbox failed: runner failed during SpawnChild: CreateProcessAsUserW failed: 2 (The system cannot find the file specified)
The same happens with:
codex sandbox windows C:\Windows\System32\cmd.exe /c whoami
I also tested the unelevated backend:
codex -c 'windows.sandbox="unelevated"' sandbox windows C:\Windows\System32\cmd.exe /c echo OK
Result:
CreateProcessAsUserW failed: 2
Troubleshooting already performed
I tested the physical standalone release binary directly:
C:\Users\<username>\.codex\packages\standalone\releases\0.153.4-x86_64-pc-windows-msvc\bin\codex.exe
The result is unchanged.
I also completely moved aside .codex\.sandbox so Codex could regenerate its sandbox state. The newly initialized sandbox still fails with the same error.
deny_read_acl_state.json does not appear corrupted:
Size: 22
NUL bytes: 0 / 22
Both helper executables exist under codex-resources:
codex-command-runner.exe
codex-windows-sandbox-setup.exe
I also copied those helpers into:
C:\Users\<username>\AppData\Local\Programs\OpenAI\Codex\bin
but this did not change the behavior.
Important A/B test
On the exact same PC and Windows installation:
npm exec --yes --package=@openai/codex@0.132.0 -- codex --version
returns:
codex-cli 0.132.0
Then:
npm exec --yes --package=@openai/codex@0.132.0 -- codex sandbox windows C:\Windows\System32\cmd.exe /c echo OK
returns successfully:
OK
So on the same environment:
Codex 0.152.1 -> CreateProcessAsUserW failed: 2
Codex 0.153.4 -> CreateProcessAsUserW failed: 2
Codex 0.132.0 -> OK
This suggests a possible Windows native sandbox regression introduced sometime after 0.132.0.
Possible related symptoms
Before identifying this sandbox failure, Codex frequently reported that it lacked permission to access normal project paths.
It also repeatedly reported that Tk/Tcl was not installed, even though the host Python installation has working Tk/Tcl:
python -c "import tkinter; print('Tk=', tkinter.TkVersion, 'Tcl=', tkinter.TclVersion)"
Output:
Tk= 8.6 Tcl= 8.6
Host Python:
C:\Users\<username>\AppData\Local\Programs\Python\Python313\python.exe
These may be secondary effects of the Windows sandbox execution failure rather than separate dependency problems.
Expected behavior
codex sandbox windows C:\Windows\System32\cmd.exe /c echo OK
should execute successfully under the Windows native sandbox, as it does with Codex 0.132.0.
Actual behavior
Codex 0.153.4 fails during sandbox child-process creation with:
CreateProcessAsUserW failed: 2

Start with the codex sandbox windows C:\Windows\System32\cmd.exe /c echo OK reproduction and compare Codex 0.153.4 with the working 0.132.0 behavior. Trace the Windows sandbox child-process path around CreateProcessAsUserW and the mentioned codex-command-runner.exe helper, using the regenerated .codex\.sandbox state as needed. Done means the native sandbox command returns OK on the reported Windows environment without the file-not-found failure.