Assistant text replies after mid-turn user messages silently dropped by terminal renderer (rendered as bare '[')

What happened

During a long working session with background workflows running, I sent several mid-turn messages. The assistant's text replies to at least two of them were never displayed in the terminal — the transcript shows my message, then a stray [ character on its own line, then the assistant's next tool call. No reply text.

The assistant did reply: the session JSONL on disk contains the full text block (verified by grep — exactly one occurrence, correctly sequenced after my message). Only the rendering dropped it.

Why it's serious

From the user's side this is indistinguishable from the agent ignoring you. I escalated twice ("why are you ignoring me?") against an agent that was in fact answering every message. A renderer bug that manufactures the "my agent ignores me" experience is trust-destroying in a way ordinary display glitches aren't — and it's only detectable if you later notice a reply referencing text you never saw.

Repro context

• Long turn with many tool calls; user message arrives mid-turn (surfaced alongside a tool result).
• Assistant emits a text block first, then tool calls (Edit/Bash) in the same response.
• The text block renders as a single [ character; the tool calls after it render normally.
• Happened at least twice in one session (2026-07-25). Screenshots exist showing the orphaned [ directly under the user's message.
• Session conditions: multiple background Workflow tasks streaming progress; /workflows monitor opened earlier in the session; terminal 264×67; --dangerously-skip-permissions; macOS (Darwin 27).
• Version: Claude Code 2.1.220, model claude-fable-5.

Expected

The text block renders before the tool calls — or at minimum is recoverable in the transcript view (ctrl+o did not surface it).

Suspected area

Race between mid-turn user-message injection and assistant text-block rendering when tool calls follow in the same message — the orphaned [ suggests the block's opening delimiter rendered before the content was dropped.

Related smaller issue

The workflow monitor shows idle Ns for subagents that are mid-generation (it only tracks tool-call activity). "analyzing" / "no tool activity Ns" would be honest without implying a hang — idle 43s on a synthesis agent reads as hung and generates exactly the confusion above.