Files
platform/todo/known-bugs/refreshing-a-finished-chat-turn-loses-output.md
T

2.5 KiB

id, title, theme, status, created, date_source, order
id title theme status created date_source order
known-bugs/refreshing-a-finished-chat-turn-loses-output Refreshing a finished chat turn loses output — replay collapses to a fold and the closing message vanishes known-bugs open 2026-08-25 stated 4

Refreshing a finished chat turn loses output. Reported by the owner 2026-08-25, with a screenshot: a Command HQ chat (the "Voice Memos" commander, first turn), refreshed after the turn completed, shows the prompt, then one collapsed seam reading 6 tool calls · 3 messages · 3 failed, then TURN FINISHED · NO CLOSING MESSAGE. The turn's actual output — including AskUserQuestion activity the prompt explicitly requested — is gone from view. The header confirms how wrong the fold is: 0 turns · 0 tok · $0 on a session that plainly ran six tool calls. He reports this happens "a lot of times" on refresh, not once.

Two distinct wrongs, and they may have different owners:

  1. The collapse itself is (he recalls) a deliberate decision — fold past tool calls on replay. If so, the decision needs revisiting where it hides MESSAGES, not just tool chatter: "3 messages" inside a collapsed seam means prose the agent wrote is behind a click, and a first-time reader concludes the turn produced nothing.
  2. "No closing message" on a turn that had one. The fold's own code says that banner was built for turns that genuinely ended without an answer, and its comments record it once mis-fired for streams (turn-rows.ts:178, types.ts:38 — "printed 'Turn finished · no closing message' under work that was still going"). A replay reaching that state on a turn that DID close means the replay source is missing the final message — so look at what the fold is FED on refresh, not at the fold: the event log the page replays (chat_session_events → turn-rows.ts folding) versus what the live socket streamed. 3 failed inside the seam is a second clue about what the stored events actually hold.

Where to look, verified in the tree: Chat/components/turn-rows.ts (the folding, with its own history of exactly this class of bug in comments and tests), TurnFold.tsx:88 (renders the banner), and whatever writes the durable events the replay reads — the claude sidecar has owned chat_session_events writes since the isolation work. Note 0 turns · 0 tok · $0 suggests the commander's turn ledger also saw none of it, which points the same direction: the durable record, not the renderer.