0.152.0 Windows: `--ignore-user-config` leaves exec with no usable sandbox — every command "rejected: blocked by policy" (regression from 0.147.0)

What happened

On Windows, codex exec with --ignore-user-config and --sandbox read-only refuses every shell command the model attempts — including plain reads like rg --version wrapped in powershell.exe -Command — with:

exec_command failed for `"C:\WINDOWS\System32\WindowsPowerShell\v1.0\powershell.exe" -Command 'rg --version'`:
CreateProcess { message: "Rejected(\"... rejected: blocked by policy\")" }

The identical invocation executes fine on 0.147.0. The process still exits 0 and the model answers from the prompt alone, so automated callers get a plausible-looking response produced without the model having read anything.

Minimal reproduction (verified)

Windows 11 Pro (10.0.26200), codex-cli 0.152.0 standalone, Codex desktop app installed (so ~/.codex/config.toml contains [windows] sandbox = "elevated"):

codex exec -C <scratch-dir> --skip-git-repo-check --ignore-user-config --sandbox read-only ^
  -c model_reasoning_effort=low --json "Run the command: rg --version . Report its stdout, or the exact error if it cannot run."

→ every command rejected "blocked by policy", exit 0.

Each of the following makes the same invocation work:

• same command on codex-cli 0.147.0;
• removing --ignore-user-config (the user config loads, including [windows] sandbox = "elevated");
• keeping --ignore-user-config and adding -c windows.sandbox="elevated".

What it is not (bisected)

Each of these was toggled independently on 0.152.0 with no effect: --ignore-rules, -c approval_policy="never", --ephemeral, --sandbox workspace-write instead of read-only, and a fully inherited vs. sanitized environment. codex sandbox cmd.exe /c "echo OK" also succeeds, so the restricted-token machinery itself launches processes.

Root cause (apparent)

0.152.0 moved Windows command execution onto the elevated sandbox, selected by [windows] sandbox = "elevated" in the user config. --ignore-user-config drops that selector, and instead of falling back to a working path (as 0.147.0 did) or failing loudly, the policy layer rejects every command.

--ignore-user-config is the documented way for automation to run hermetically — a config-suppressing flag silently disabling all command execution seems unintended.

Suggestions

1. When the user config is ignored on Windows, default the exec sandbox to something usable, or emit a startup error naming the missing setting rather than rejecting each command as "blocked by policy".
2. Consider a nonzero exit (or a machine-readable marker in --json output) when every command execution in a turn was refused — exit 0 makes this invisible to callers.

Possibly related: #38898, #40047 (elevated-sandbox helper failures with different symptoms).

Start by reproducing the Windows 0.152.0 behavior with codex exec --ignore-user-config --sandbox read-only, then compare it with 0.147.0 and the windows.sandbox configuration path. Trace how the Windows sandbox is selected when user config is ignored. Done means the documented hermetic invocation either executes permitted commands or reports a clear failure instead of silently returning exit 0.