The Windows bridge-launcher test fails intermittently and blocks landing, while the issue it names is closed

[fujibee]

launcher: windows-native starts the bridge (#567) still fails intermittently, and #567 is closed. The test outlived its issue, so there is nothing open to attach the failures to.

Measured today, same code:

integration tip (push run)      failure
three PR heads on that base     success, success, success
one PR head                     failure, failure on two consecutive runs

The failure is always the same assertion, at tests/test_codex_bridge_launcher.bats:507:

not ok 2 launcher: windows-native starts the bridge (#567)
#   `[ -f "$CAPTURE" ] || { echo "no bridge was started on native Windows"; false; }' failed
# no bridge was started on native Windows

So the bridge sometimes does not start, or does not start in time, and the capture file is absent when the assertion runs.

Two things make this worth an issue of its own rather than a line in a workflow comment:

• It blocks landing. A merge gate that requires CI success on a head SHA cannot be satisfied while this is red, and it needed two reruns today on one PR. That cost is real even though the underlying defect may be small.
• The record points at a closed issue. tests.yml names it as one of two known intermittent reds, and the test name carries #567, but codex bridge on Windows: port-detection liveness probe asks tasklist about an MSYS pid, so it always aborts on iteration 1 #567 is closed — so a reader who follows the reference finds a resolved problem and a live failure with no explanation between them.

What would settle it, roughly in order of cost: whether the assertion has a wait at all or checks immediately (the message reads like a bare existence check); whether the bridge start is asynchronous on that platform and the test assumes it is not; and whether the failure correlates with runner load, which today's data hints at but does not establish — the failures clustered on a run that also carried five macOS shards.

Not claimed here: that this is the same root cause #567 described. The symptom matches the name, which is why the name is still on it, but the issue was closed and the failure continued, so they may be different things wearing one label.

[fujibee]

Recording the pre-fix rate, so that "this is fixed" can be checked later
against a number rather than an impression.

The bounded handshake landed a few minutes ago. Every run measured below
predates it, so this is the baseline, not a result.

Measured over the 14 most recent tests.yml runs that completed this leg
(bats (windows-latest, windows runtime (#567))), across main,
integration/terminal-driver-v1, and six feature branches:

• completed green: 9
• completed red: 2
• cancelled before completing (a newer push replaced the run): 3

Both reds are on feature branches that had a green result for the same
leg on an earlier run of the same branch. So the failures do not track a
branch's content; the same tree produced both outcomes on different runs.
That is the signature the intermittency claim rests on.

Two things this baseline is deliberately not claiming:

• It does not say the handshake change fixes this. No run containing that
  change has completed this leg yet.
• It does not attribute these two reds to the launcher window the change
  replaced. The leg is named for a different, closed issue, and the two are
  easy to conflate because both are "the Windows one". Whether the remaining
  intermittency has the same cause is open.

What would settle it: the same count over the next comparable set of runs,
all of which contain the handshake change. If the red count stays at roughly
2 in 11, the cause is elsewhere and this issue should stay open on that
basis.

[fujibee]

Post-#1165 status: the launcher test is fixed; the leg's residual red is a different, already-tracked flake

The launcher: windows-native starts the bridge test (this issue's subject)

#1165 removes the named race by construction, not by lengthening a timeout. The old body was:

sleep 6 3>&- & local p=$!
bash "$LAUNCHER" codex "$PROJ" "ws://127.0.0.1:1" "$p" >/dev/null 2>&1 3>&- || true
wait "$p" 2>/dev/null || true          # <- the 6s lifetime process exits HERE
for i in {1..30}; do [ -f "$CAPTURE" ] && break; sleep 0.1; done   # <- only THEN we wait for CAPTURE

The bridge launch is asynchronous, and CAPTURE is created by a role child the dispatcher spawns while its parent lifetime is still alive. Once the sleep 6 parent exits, the dispatcher is no longer eligible to spawn that child — so on a loaded runner, if the async launch had not produced CAPTURE within those 6 seconds, the subsequent 3-second poll waited for a file that could never appear. That is exactly the issue's candidate causes 1 (the check effectively fires after too short a window), 2 (async start), and 3 (load): the failures "clustered on a run that also carried five macOS shards."

#1165 replaces this with run_launcher_until_capture, which holds a sleep 30 lifetime alive across a 20s capture poll and kills it only after CAPTURE is observed. The dispatcher stays eligible for the whole window, so the launch has ~20s under load instead of ~6s-and-then-ineligible.

Counts — the launcher test's own ok/not ok line, last 14 integration runs (same per-run method as the baseline above), split at #1165 (33b2b47, merged 2026-09-12 05:14Z):

group	runs	launcher test
post-#1165	2	ok , ok (now named #1161)
pre-#1165	10 completed (+2 cancelled, leg did not run)	ok × 10

The launcher test did not fail on integration in this window. Its documented failures (the baseline above) were on loaded PR heads — the condition #1165 addresses. Verified from the job logs that the test ran (not skipped): ok 2 launcher: windows-native starts the bridge (#1161).

The rename #567 -> #1161 also settles this issue's second concern: the test no longer points a reader at a closed issue.

The leg's residual red is NOT this test

The windows runtime (#567) leg runs two windows-native tests — codex-monitor: ... reaches the bridged handoff (test_codex_monitor.bats) and launcher: ... starts the bridge (test_codex_bridge_launcher.bats). #1165 only touches the launcher.

The one leg failure in the last 14 integration runs (b631e87) was the monitor test, and it failed in teardown, body passing:

not ok 1 codex-monitor: windows-native reaches the bridged handoff (#567)
#   (from function `teardown_test_env' ... from `teardown' in test file tests/test_codex_monitor.bats, line 76)
#   `teardown_test_env' failed

That is the already-tracked "Directory not empty" teardown flake — #1036 / #662 — not this issue and not something #1165 changes. The leg name and both test names all carry #567, which is what makes them easy to conflate.

Not yet, and recommendation

• main still carries the old racy launcher body (test(codex): wait for the Windows bridge handshake #1165 is on integration/terminal-driver-v1 only) — so a main-targeted PR's windows leg can still hit this race until the next integration -> main merge carries test(codex): wait for the Windows bridge handshake #1165.
• No post-test(codex): wait for the Windows bridge handshake #1165 loaded PR-head run (the decisive stress case) has completed the leg yet; the 2 post-test(codex): wait for the Windows bridge handshake #1165 samples are integration pushes, where the test was already green. The fix is correctness-by-construction, so I am confident, but that is the run that would settle it by count as well as by argument.

Recommendation: keep this open until #1165 reaches main; then close it against #1165. Track the leg's remaining instability under #1036/#662 (the monitor teardown), which is a separate defect.