Why

Recent main CI had repeated Windows timeouts in the legacy sandbox process tests:

• codex-windows-sandbox session::tests::legacy_capture_powershell_emits_output failed in runs 24909500958, 24908076251, 24906197645, 24905411571, 24903336028, and 24898949647.
• legacy_tty_powershell_emits_output_and_accepts_input failed in the same set of runs.
• legacy_non_tty_cmd_emits_output failed in runs 24909500958, 24908076251, 24906197645, and 24903336028.
• legacy_non_tty_powershell_emits_output failed in runs 24908076251, 24906197645, and 24903336028.

These failures were 30s timeouts on Windows x64 and/or arm64 rather than assertion failures.

Root Cause

The active legacy Windows sandbox process tests all exercise host-level resources: sandbox setup, ACL/user state, private desktop process launch, stdio capture, and PowerShell/cmd child cleanup. Running several of these tests concurrently can leave them competing for the same Windows sandbox setup path and process/session resources, which makes command startup or output collection hang under CI load.

What Changed

• Added a shared in-process mutex for the active legacy Windows sandbox process tests.
• Held that guard across each legacy cmd/PowerShell process test so those host-resource-heavy cases run one at a time.
• Kept the skipped legacy cmd TTY tests unchanged.

Why This Should Be Reliable

The tests still use unique homes and run the real legacy sandbox process path, but they no longer overlap the fragile host-level setup and process/session lifecycle. Serializing just this small group removes the concurrency race without reducing the behavioral coverage of each test.

Verification

• cargo test -p codex-windows-sandbox
• GitHub Windows CI is the primary validation signal for the affected tests; on this PR, Windows clippy, Windows release, and Windows local Bazel passed after the serialization fix.