[Windows] Elevated sandbox setup: orchestrator-built payload silently rejected by the same helper that accepts a hand-built payload (CLI 0.154.0)

What version of Codex CLI is running?

codex-cli 0.154.0

What subscription do you have?

ChatGPT Plus

Which model were you using?

N/A — the failure occurs during codex sandbox setup (provisioning), before any model interaction.

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64

What terminal emulator and version are you using (if applicable)?

Windows PowerShell 5.1 (elevated) for the standalone CLI test; the same failure also occurred through the Codex App's built-in orchestrator.

Codex doctor report

Not attaching the full `codex doctor --json` output because it contains
environment-identifying details unrelated to this bug. Relevant facts from it:

- CLI: codex-cli 0.154.0, installed via npm (WSL side; the standalone
  Windows build 0.154.0 was used for the tests above)
- overall status: "warning" — all warnings are unrelated to the sandbox
  issue (background app-server not running, non-critical path notices)
- config loads OK; auth via ChatGPT

What issue are you seeing?

Running codex sandbox setup --elevated --current-user makes the setup helper (codex-windows-sandbox-setup.exe) exit with code 1 silently — no stderr, no log entry, no Win32 error code. The orchestrator retries with the same payload and fails identically every time (three consecutive runs).

Environment:

• Windows 10 Home 19045 x64
• Codex CLI 0.154.0 (standalone Windows build); identical behavior with the Codex App's bundled orchestrator (0.154.0-alpha.6.2)
• CODEX_HOME=D:\CodexHome (non-default location)
• Elevated sandbox, provisioning partially completed earlier

What steps can reproduce the bug?

1. On Windows 10 19045 x64 with a non-default CODEX_HOME and [windows] sandbox = "elevated" partially provisioned, run from an elevated shell:

   codex sandbox setup --elevated --current-user

2. The helper spawns and exits 1 before its logging initializes — silent. Repeats identically on retry.

Control experiment (decisive):

3. Hand-build an ElevationPayload per schema v5 (JSON → base64, ~556 chars, empty read/write/deny roots and proxy_ports, passed as the single positional argument) and invoke the same helper binary with it.

4. Result: the helper completes the FULL provisioning flow — ensures both sandbox users, creates 4 firewall rules and 12 WFP filters, writes the setup marker, and the lock step tightens F→M as designed.

5. Same machine, same day, same helper: the hand-built payload succeeds, the orchestrator-built one is rejected. The difference is payload content only — something in what elevated_provisioning_payload() serializes (local-state-dependent fields) fails the helper's early parse.

Thread id: N/A (failure is in the setup CLI path, not a chat thread).

What is the expected behavior?

• The orchestrator-built payload should be accepted by the same helper that accepts the hand-built one.
• At minimum, the helper's rejection reason must reach the orchestrator: stderr is currently wired to Stdio::null() in bin/setup_main/win.rs, which makes the failure undiagnosable and causes blind retries.

Additional information

This looks like a third failure mode of the payload-over-argv transport:

• #32315 — payload > 32,767 chars → os error 206 at CreateProcessW
• #41809 — deny-read glob expansion inflates the payload to MBs

Ours is a mid-size payload rejected inside the helper at parse time. The transport fix proposed in #32315 (stdin / temp file / named pipe) would presumably cover this mode as well.

Caveats (reported honestly):

• Tested on 0.154.0; not verified on 0.155.1 yet.
• The trigger may depend on local configuration (e.g. the non-default CODEX_HOME); root cause not pinpointed to a specific field.
• Happy to re-test on 0.155.1 if needed.

Hand-built payload that succeeded (base64-decoded JSON; "real_user" placeholdered)

{
"version": 5,
"offline_username": "CodexSandboxOffline",
"online_username": "CodexSandboxOnline",
"codex_home": "D:\CodexHome",
"command_cwd": "D:\CodexHome",
"read_roots": [],
"write_roots": [],
"deny_read_paths": [],
"deny_write_paths": [],
"proxy_ports": [],
"allow_local_binding": false,
"real_user": "",
"otel": {"environment": "production"},
"mode": "interactive-provision",
"refresh_only": false
}

Start in bin/setup_main/win.rs, especially the elevated_provisioning_payload() path and the helper invocation where stderr is sent to Stdio::null(). Reproduce the failure with the orchestrator-built payload and compare it with the successful hand-built schema v5 payload. Done means the generated payload is accepted, or the helper's rejection reason reaches the orchestrator without silent retries.