pastilhasandClaude Opus 5
6b8cf848ff
"Turn finished · no closing message" kept appearing over an agent that was plainly still working, with output resuming a moment later. isGenerating was set in exactly three places: sendPrompt, and the two reconnect handshakes. So it answered "am I waiting for a reply I asked for", never "is this conversation working". Every other way a turn begins left it false — a commander waking on its own schedule, a queued prompt the server delivered, another tab driving the same session, or a turn that started before this tab was looking. The events still render, but buildRows reads isGenerating to decide whether the last turn is finished, so a live turn was `complete` and the moment it sat on a completed tool call with nothing said after it, the banner fired. Same gap left the composer enabled mid-turn, and a message typed then was not marked injected — which splits the live turn and prints the banner a second way, the exact failure injected exists to prevent. session:claude now sets it: the harness's own turn-start signal, and the only one that arrives before any work does. tool:start sets it too, because session:claude is not durable and a socket connecting mid-turn never receives one, while a tool cannot start outside a turn. Two candidates were measured rather than argued. A genuinely silent turn ending earns the banner honestly, but 667 of 673 recorded turns end with assistant:text immediately before result, so that is ~1% and cannot be it. And a stale sync:live is real but rare: correlating every attach in the officer log against the agent's own later output, 15 of 549 "not generating" attaches were contradicted and one provably so. That residue is left alone — the tool:start fallback now corrects it on the next event — and noted on the refresh card, which is the same seam. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Officer-Session: f7a62308-0977-4cf4-aa29-c020853fd420
3.3 KiB
id, title, theme, status, created, date_source, order
| id | title | theme | status | created | date_source | order |
|---|---|---|---|---|---|---|
| known-bugs/a-turn-this-tab-did-not-start-reads-as-finished | A turn this tab did not start reads as finished — "no closing message" over a working agent | known-bugs | done | 2026-08-25 | stated | 6 |
"Turn finished · no closing message" appears while the agent is still working, and output resumes a
moment later. Reported by the owner 2026-08-25 with a screenshot: the session list shows Platform Harry
generating, and Platform Harry's own panel shows the banner under two completed Bash calls. He reports it
happens often.
Not the same bug as the two below it, and not a race. isGenerating was set in exactly three places:
sendPrompt, and the two reconnect handshakes (sync:live, sync:messages). So it answered "am I
waiting for a reply I asked for", never "is this conversation working". Every other way a turn begins
left it false — a commander waking on its own schedule, a queued prompt the server delivered, another
tab or another device driving the same session, or simply a turn that started before this tab was looking.
The tab still renders the work, because the events arrive regardless. But buildRows reads isGenerating
to decide whether the last turn is finished (generatingNow = isLast && isGenerating), so with it false a
live turn is complete — and the moment that turn sits on a completed tool call with nothing said after
it, the banner fires. Then the next event arrives and the conversation carries on, which is exactly what
"still outputting in a bit" is.
Two further consequences of the same gap, both visible in the screenshot: the composer stays enabled
during someone else's turn, and a message typed then is not marked injected — which splits the live turn
and prints the banner a second way, the precise failure injected was added to prevent (types.ts).
Ruled out on the way, with evidence rather than reading. A silent turn ending would earn the banner
honestly, so that was measured first: across every durable event ever recorded, 667 of 673 turns end with
assistant:text immediately before result. Genuine silent endings are ~1% and cannot account for "a lot
of times". A stale sync:live was the other candidate and is real but rare — correlating every attach in
the officer log against the agent's own subsequent output, 15 of 549 "not generating" attaches were
contradicted, and only one provably so (the first event after it was a tool:result, so a tool was
already in flight when officer answered).
Fixed 2026-08-25. session:claude — the harness's own turn-start signal, and the only one that arrives
before any work does — now sets isGenerating. tool:start sets it too, as a fallback: session:claude is
not durable, so a socket that connects mid-turn never receives one, and a tool cannot start outside a turn.
Residual, and left alone deliberately: sync:live can still report isGenerating: false for a turn that is
running (the one proven case above, sidecar.isClaudeGenerating answering for an adopted session). The
tool:start fallback now corrects that on the next event rather than leaving the turn wrongly settled, so
the symptom is covered even where the answer is not. Fixing the answer itself belongs with
known-bugs/refresh-mid-tool-call-renders-the-turn-folded, which is the same seam.