Assistant text before/between tool calls is not rendered in the CLI, while hooks and the transcript still see it

Summary

Assistant text blocks emitted before or between tool calls in the same turn are silently dropped from the rendered CLI transcript. The text still exists in the underlying transcript — the model counts it as said, and PreToolUse/supervisory hooks read it and judge the model on it — but the human never sees it. The model, the hooks, and the user are looking at three different conversations, and two of them agree the third is wrong.

Reproduction

1. Send the model a message mid-task (e.g. a correction).
2. The model responds with a text block (acknowledgment/answer) followed by tool calls (Read, Write, Edit) in the same assistant turn.
3. The CLI renders only the tool-call lines. The text block is not displayed.

What the user sees:

❯ Claude, individual edits are more costly for me, as each is a hook call.

  Read 1 file (ctrl+o to expand)
  ⎿  Loaded .claude/worktrees/exit-types/CLAUDE.md

⏺ Write(.claude/worktrees/exit-types/pkg/script/read_next_test.go)

What the transcript contains at that position: a full paragraph acknowledging the correction and describing the consolidation strategy. The user has no indication it exists.

Why this is worse than a cosmetic rendering gap

1. The system prompt solicits exactly this text. It instructs the model: "Before your first tool call, say in a sentence what you're about to do; while working, give brief updates when you find something load-bearing." The same prompt elsewhere warns "text you write between tool calls may not be shown to the user." The harness asks the model to write into a channel it then doesn't render.

1. Hooks validate against the transcript, not the rendering. In our setup a PreToolUse reasoning-audit hook reviewed a blocked edit and wrote, verbatim, "The agent acknowledged this" — about the invisible paragraph. Supervisory tooling confirmed communication had happened; the human it was addressed to saw nothing. Any hook- or transcript-based oversight (audits, "did the agent reply" checks, post-hoc review) inherits this false positive.

1. The failure is silent on both sides. The model has no signal its text was dropped; the user has no signal text existed. In our case this compounded into a day of escalating conflict: the user repeatedly demanded answers the model believed it had already given — because it had, into the void.

Expected behavior

Render assistant text blocks wherever they occur in the turn (collapsed/dimmed is fine), or make the drop consistent end-to-end: if pre-tool-call text is not rendered, it should not be solicited by the system prompt, and it should be flagged or excluded for hooks so transcript-based review and the human are judging the same artifact.

Environment

• Claude Code 2.1.170, macOS (darwin), CLI terminal UI
• Observed with text-then-tool-call turns of both single and batched tool calls