From faed6d5c070f7b77db3c8f55b86cc2e9ca6f1be1 Mon Sep 17 00:00:00 2001
From: Michael Bolin <mbolin@openai.com>
Date: Tue, 21 Apr 2026 21:14:45 -0700
Subject: [PATCH] tests: serialize process-heavy Windows CI suites (#18943)

## Why

A [Windows Cargo
build](https://github.com/openai/codex/actions/runs/24754807756/job/72425641062)
on `main` timed out in several unrelated-looking suites at the same
time:

- `codex-app-server` account tests failed before account logic, while
`mcp.initialize()` was waiting for the first JSON-RPC response.
- `codex-core` `apply_patch_cli` tests timed out while running full
Codex/apply_patch turns.
- `codex-windows-sandbox` legacy session tests timed out while creating
restricted-token child processes and private desktops.

The app-server log reached the test harness write path in
[`McpProcess::initialize_with_params`](https://github.com/openai/codex/blob/731b54d08fb93aec31fb020999a62447886f3ab3/codex-rs/app-server/tests/common/mcp_process.rs#L244-L263),
but never printed the matching stdout read from
[`read_jsonrpc_message`](https://github.com/openai/codex/blob/731b54d08fb93aec31fb020999a62447886f3ab3/codex-rs/app-server/tests/common/mcp_process.rs#L1123-L1128).
The server initialize handler is a small bookkeeping/response path
([`message_processor.rs`](https://github.com/openai/codex/blob/731b54d08fb93aec31fb020999a62447886f3ab3/codex-rs/app-server/src/message_processor.rs#L601-L728)),
so the failure looks like Windows runner process/pipe scheduling
starvation rather than account-specific behavior.

## What Changed

This updates `.config/nextest.toml` to serialize two process-heavy sets:

- `codex-core` tests matching `package(codex-core) & kind(test) &
test(apply_patch_cli)`
- `codex-windows-sandbox` tests matching `package(codex-windows-sandbox)
& test(legacy_)`

`codex-app-server` integration tests were already serialized inside
their own package; this change reduces overlap with the other suites
that were saturating the runner at the same time.

## Verification

- `cargo nextest list --filterset "package(codex-core) & kind(test) &
test(apply_patch_cli)"`
- `cargo nextest list --filterset "package(codex-windows-sandbox) &
test(legacy_)"`

The Windows sandbox filter naturally lists no tests on macOS, but it
validates the nextest filter/config syntax locally.
---
 codex-rs/.config/nextest.toml | 17 +++++++++++++++++
 1 file changed, 17 insertions(+)

diff --git a/codex-rs/.config/nextest.toml b/codex-rs/.config/nextest.toml
index 3f68bbbe9..86d00e463 100644
--- a/codex-rs/.config/nextest.toml
+++ b/codex-rs/.config/nextest.toml
@@ -8,6 +8,11 @@ max-threads = 1
 [test-groups.app_server_integration]
 max-threads = 1
 
+[test-groups.core_apply_patch_cli_integration]
+max-threads = 1
+
+[test-groups.windows_sandbox_legacy_sessions]
+max-threads = 1
 
 [[profile.default.overrides]]
 # Do not add new tests here
@@ -27,3 +32,15 @@ test-group = 'app_server_protocol_codegen'
 # Keep the library unit tests parallel.
 filter = 'package(codex-app-server) & kind(test)'
 test-group = 'app_server_integration'
+
+[[profile.default.overrides]]
+# These tests exercise full Codex turns and apply_patch execution, and they are
+# sensitive to Windows runner process-startup stalls when many cases launch at once.
+filter = 'package(codex-core) & kind(test) & test(apply_patch_cli)'
+test-group = 'core_apply_patch_cli_integration'
+
+[[profile.default.overrides]]
+# These tests create restricted-token Windows child processes and private desktops.
+# Serialize them to avoid exhausting Windows session/global desktop resources in CI.
+filter = 'package(codex-windows-sandbox) & test(legacy_)'
+test-group = 'windows_sandbox_legacy_sessions'