[Windows] --sandbox workspace-write with sandbox_workspace_write.network_access=false does not reliably block network for shell commands (pwsh / .NET Process.Start get through)

[Windows] --sandbox workspace-write with sandbox_workspace_write.network_access=false does not reliably block network for shell commands

Version: codex-cli 0.153.4, Windows 11 Pro 10.0.26200, [windows] sandbox = "elevated" in config.toml, PowerShell 7 as the model's shell.

Repro (non-interactive):

codex exec --skip-git-repo-check --cd <dir> --sandbox workspace-write -c sandbox_workspace_write.network_access=false - < prompt.txt

prompt.txt: «Run through the shell: (1) curl -sS -m 5 https://example.com -o NUL -w "%{http_code}"; (2) the same curl started via System.Diagnostics.ProcessStartInfo from pwsh; print both outputs.»

Observed (header shows sandbox: workspace-write [workdir, /tmp, $TMPDIR], approval: never):

• Run A (model chose "pwsh.exe" -Command 'cmd /c curl …'): curl: (7) Failed to connect to example.com:443 after 45 ms — blocked, as expected.
• Run B (model chose "pwsh.exe" -Command '$psi = New-Object System.Diagnostics.ProcessStartInfo; $psi.FileName = "curl.exe" …'): STDOUT=200 — not blocked.
• Run C (model chose "pwsh.exe" -Command '$direct = (& curl.exe -sS … | Out-String)…'): DIRECT=200 DOTNET=200 — not blocked even for the direct & curl.exe call.

So the network restriction holds for a cmd.exe /c curl child but not for curl.exe started directly from pwsh nor for a .NET Process.Start grandchild, under the same flags and the same session settings.

Expected: with network_access=false, no process spawned by the model's shell command (children and grandchildren) can open outbound sockets, regardless of the launcher (cmd.exe, pwsh, .NET Process API).

Why it matters: we use codex exec as an autonomous delegate; the sandbox is the only process-level perimeter on Windows. A delegate following an injected «register / fetch this URL» instruction can escape the restriction by choosing pwsh or .NET APIs — which a model does spontaneously (run B was not prompted to bypass; it just picked ProcessStartInfo after a PowerShell parsing error on the direct call).

Raw logs: available on request (redacted paths). Happy to test a build.

Start by reproducing the issue with the provided codex exec command on Windows 11, comparing cmd.exe, direct curl.exe, and PowerShell .NET ProcessStartInfo launches. Trace the Windows sandbox process and network enforcement entry points, then verify that network_access=false blocks outbound sockets for both child and grandchild processes regardless of launcher.