codex-bridge: one wake can start two turns during turn/start

[ainyan03]

Thanks for agmsg — it's become a daily driver for multi-agent messaging here. Filing a timing-sensitive race in the Codex bridge, with a deterministic harness reproduction.

Symptom: a single wake occasionally produces two injected turns — the second an empty poll ("No new messages.") that burns a turn on the live thread. Observed in live use (on a v1.1.13-era install); the affected code path is unchanged on current main.

Mechanism: turn/completed and thread/status idle arrive independently and both funnel into the bridge's turn-end handling (#41 is why idle has to count as an end). App-server requests and notifications can arrive before an outstanding RPC response — the approval-collision test already exercises that interleaving. So:

1. Turn A ends; the bridge delivers a deferred wake and sends turn/start for turn B.
2. Before B's ACK arrives, turn A's trailing end signal (an idle, or a completed without a usable id) lands.
3. The bridge attributes it to B, believes B already ended, and re-delivers the wake → a second turn from the same wake.

Reproduction: a bats harness driving the bridge against a scripted app-server reproduces the duplicate deterministically; two additional regression tests cover the legitimate orderings a fix must not break (pre-ACK completion, stale-idle attribution). On live current main (f7de22a, codex-cli 0.147.0) I could not provoke it in 13 rounds of mid-turn message bursts — the harness is what reproduces the relevant ordering reliably.

Fix shape (running locally, holding up in daily use): claim the pending wake before sending turn/start, and attribute mid-start end signals by turn id — only an id-matching completed defers the end; an idle or id-less signal landing during start is discarded, since the #41 watchdog already covers the pathological no-signal case. As defense in depth, the injected prompt reads the inbox with --quiet so an empty read cannot become a turn prompt. Patch + the three regression tests are ready; happy to PR if this direction fits.

[fujibee]

Please open the PR.

We confirmed the window exists on current main, by reading the code rather than reproducing it: tryStartTurn() awaits the turn/start round-trip and only clears pendingWake after the ACK returns, while onTurnEnded() clears turnActive, sets threadIdle, and re-enters tryStartTurn() whenever pendingWake is still set. A trailing end signal arriving inside that round-trip passes every guard.

We are not in a position to endorse the fix direction from here — your harness is what reproduces the ordering, and we have not run it. What would settle it is the three halves failing independently. If the PR shows that, the direction proves itself:

reverted	what should go red
claiming the wake before turn/start	the duplicate-turn case, and only that
attributing mid-start end signals by turn id	the stale-idle attribution case, and only that
the --quiet inbox read	nothing

The third row is the one we would look at hardest. --quiet is described as defense in depth, so removing it alone should leave every case green; if it turns something red, the load is sitting on the wrong half and the real fix is elsewhere.

Also worth stating in the PR: which of the two ordering tests covers pre-ACK completion and which covers stale-idle attribution, so the rows above can be checked without reading the harness first.

[ainyan03]

Fix is up as #889.

The per-half revert matrix didn't survive measurement — the wake claim turned out to be subsumed by the in-flight gate (reverting it alone changes nothing), and reverting the id attribution reds the pre-ACK case, not stale-idle. So the PR is a cumulative series instead: each commit flips exactly the tests its mechanism owns, measured at every step.

That also means two of the four commits are red on their own, deliberately:

• commit 1 (tests only) fails all three — the tests proving they detect the bug before any fix lands;
• commit 2 (wake claim + in-flight gate) fails pre-ACK completion — the blanket gate's own breaking point, which is exactly what motivates the id attribution in commit 3.

Commits 3 and 4 are green (full test_codex_bridge suite 45/45). CI runs on the head, so the checks are unaffected; only a per-commit bisect would land on a red step. If you'd rather not carry knowingly-red commits, I can squash the series and keep the table as a reproduction recipe instead.

The table, the test-to-ordering mapping you asked for, and one open question (keep or drop the wake claim) are in the PR body.

[ainyan03]

Heads-up before you spend time on #889: I moved it to draft, because two of its checks are red for a reason that is not in the branch.

check-enforced-assertions reports 639 against a baseline of 638 — that is main's current state, not this branch's. Measured three ways: the branch alone is at 638 and the checker exits 0; main at 2910722 is at 639 and exits 1; main's own latest run is red on the same job. The PR inherits it because CI runs the merge, and bats (ubuntu-latest 3/4) fails for the same reason (it carries test_enforced_assertions.bats).

Walking the commits since f7de22a, the count goes 638 → 639 at fa826b7 (#771): tests/test_compat_posix.bats:112 is [[ "$raw" == *"Application Support"* ]], a non-last [[ ]], so the ratchet counts it while the baseline stayed at 638.

I deliberately kept that fix out of #889: PRs land as a single squash commit here, and an unrelated CI fix carried inside "codex-bridge: one wake, one turn" would be wrong to keep in the history forever. Happy to send it as a one-line PR, or to fold it into #889 if you would rather look at one thing — your call.

The bridge work itself is unchanged and green on its own; I will mark #889 ready as soon as this is sorted.