Review flow: follow-up rounds never reach a live codex reviewer (round 2 times out, no dispatch activity in daemon log) #349

Summary

submit_review_round on an existing code-review flow never delivers the round-2 prompt to the still-running codex reviewer. The round sits until the server's timer expires and is recorded as unclear: timeout waiting for participant result. Round 1 of a fresh flow works reliably every time — only follow-up rounds into a live agent fail. Reproduced on daemon 0.10.13 and 0.11.3 (so it is not fixed by the latest release), across 3 consecutive flows; 6 consecutive fresh-flow round-1 launches succeeded in the same session, including one that returned clean.

Environment

• Daemon host: Windows 11 Pro (10.0.26200), daemon stephen-tung
• Daemon versions tried: 0.10.13 and 0.11.3 (updated mid-investigation; identical failure)
• Server: https://kurrent.kcap.ai
• Reviewer vendor: codex (the built-in code-review flow definition)
• Flow driver: Claude Code session using kcap mcp flows (plugin), repo kurrent-io/kcap-server, PR Simplify the desktop pull request reader #1158

Repro

1. start_review_flow(kind: "code-review", …) → reviewer launches, returns findings. ✅ (worked 6/6 times)
2. Fix findings, submit_review_round(flow_run_id, context) → tool call accepts the round (flow shows running, round_count 2).
3. Nothing further happens. The codex process stays alive but idle (~50 CPU-seconds over an hour; e.g. PID 51244 / 5148 / 59176 across attempts). After the server-side window, get_review_flow_status returns unclear / timeout waiting for participant result.
4. Retrying submit_review_round on the same flow reproduces the timeout.

Affected flow_run_ids (for server-side correlation — did the round-2 dispatch ever get emitted to the daemon connection?):

• 2b1878488bed40f8abbfea9f6b64eeb2 (round 2 + one retry, daemon 0.10.13, 2026-07-22 ~23:55–00:20 local)
• ea35fce682ac41ffaec4e3aaa4b60652 (round 2 + one retry, daemon 0.10.13, 2026-07-23 ~12:5x)
• 3fcdaf880d5448c0b110b0c166660615 (round 2, daemon 0.11.3, 2026-07-23 ~13:45)

Key evidence: the daemon log is completely silent at round-2 time

The daemon logs launches, stops, exits, and permission-bridge denials — but shows zero lines at every round-2 submission time. Example (0.11.3 run):

13:21:49.395 info AgentOrchestrator  Launching agent eb4ef230 for C:\git\kcap-server (effort=default, model=default)
13:21:49.428 info AgentOrchestrator  Agent eb4ef230 spawned (PID=59176, worktree=C:\git\kcap-server, vendor=codex)
13:22:12.199 warn LocalPermissionBridge  Denied out-of-allowlist tool mcp__kcap_review__get_pr_summary for unattended reviewer session 019f8d6c...
[round-1 findings returned ~13:35; round 2 submitted ~13:45 — NO further log lines at all]

So either the server never emitted the follow-up dispatch, or the daemon's mid-session input-delivery path does its work (or fails) entirely unlogged. The evidence cannot discriminate — which is itself a finding (see Observability below).

What works vs. what fails

Hypotheses (either fits all evidence)

1. Server-side: the follow-up round dispatch is never sent to the daemon connection — possibly gated on the sequenced-settlement delivery protocol that is still incomplete (the B2-b residual documented in kcap-server's CLAUDE.md), while launch uses the older working path.
2. Daemon/OS-side: the dispatch arrives but writing the prompt into a live codex.exe console mid-session fails silently — plausibly Windows-specific (stdin/PTY delivery into a running console process differs from macOS, where most kcap development happens). Round 1 dodges this because launch-time prompts don't use that path.

A server-side log check for the flow_run_ids above (was a round-2 participant dispatch emitted, and was it acked?) should discriminate between the two in minutes.

Observability ask (regardless of root cause)

Launch, stop, death, and permission decisions are all logged; mid-session prompt delivery logs nothing on success or failure at either end. Please add a daemon log line (and/or a server-side delivery ack) at the moment a round prompt is written into an agent — this bug took a three-flow forensic session to characterize and would be a five-minute diagnosis with that one line.

Workaround (functional today)

Run each round as a fresh flow: close the current flow, start_review_flow again with the prior findings/fix SHAs carried in the context as a "verification round". Round 1 delivery is reliable, so the campaign converges — at the cost of a fresh (paid) reviewer per round and no reviewer memory.

Related Linear context: AI-1470 / PR kurrent-io/kcap-server#1158 (the review campaign where this was hit); kcap-server CLAUDE.md item 14 documents the B2-b heal residual which may share a root cause.