Assistant text blocks intermittently dropped from BOTH display and session transcript when followed by tool_use in the same turn (AskUserQuestion is the worst case)

Environment

• Claude Code CLI v2.1.201 (macOS, darwin 25.6.0)
• Model: claude-fable-5 (extended thinking active)
• Terminal UI (not IDE extension)

Summary

Assistant text emitted between thinking and a tool_use in the same turn is
intermittently missing from BOTH the rendered UI and the session .jsonl
transcript. In one session, 4 of ~6 such text blocks vanished. When the
following tool call is AskUserQuestion, the user receives a naked question
with none of the analysis it refers to — they must answer without the
context the model wrote for them.

This extends #66112 / #67267 with two new data points: (1) the drop is not
display-only — the text is also absent from the .jsonl transcript, so
transcript-based tooling cannot distinguish "model never wrote text" from
"harness dropped it"; (2) there is a structural fingerprint in the
transcript (below).

Fingerprint

Listing assistant entries with their content-block types
(jq -r 'select(.type=="assistant") | .timestamp + " | " + ([.message.content[]?.type] | join(","))'):

• Turns where the text SURVIVED log: thinking then text then tool_use

entries — one thinking entry.

• Turns where the text was DROPPED log: **two consecutive thinking

entries 1–2 ms apart** (both signature-only, thinking field empty),
then tool_use — and no text entry at all.

Observed 6/6 in the evidence session: every dropped-text turn shows the
double-thinking pair; every surviving-text turn shows a single thinking
entry. This is consistent with the streaming pipeline misclassifying the
text block as a (redacted) thinking block — which would explain why it is
simultaneously hidden from the UI and absent as text in the transcript.
Content-level confirmation is not possible from the file because thinking
blocks are stored signature-only.

Sample from the evidence session (times UTC, 2026-07-05):

15:53:53.977 | thinking            ← survived: single thinking
15:53:54.970 | text                ← "Starting the session…" (displayed)
15:53:55–58  | tool_use ×6
15:55:12.856 | thinking            ← dropped: double thinking, 2ms apart
15:55:12.858 | thinking
15:55:17.530 | tool_use            ← AskUserQuestion, rendered with NO text

Model attribution (added 2026-07-07)

New controlled evidence narrows this to a specific model. Running the same
slash command against the same repository state, back to back:

• claude-fable-5: the turn that emitted a briefing and then called

AskUserQuestion recorded as thinking, thinking, tool_use with no text
block — the briefing was dropped from both UI and transcript. Within that
same session, single-thinking turns kept their text; only the
double-thinking turns lost it.

• claude-opus-4-8: identical command — every turn recorded

thinking, text, tool_use; text survived. Zero double-thinking turns.

• claude-sonnet-5: identical failure-shaped turn (visible text immediately

followed by AskUserQuestion in one turn) — text survived. Zero
double-thinking turns.

Aggregated over ~48 local sessions:

| Model | double-thinking (drop) events | notes |
|---|---|---|
| claude-fable-5 | 30–47 per long session (~15–20% of turns) | heavily affected |
| claude-opus-4-8 | 0 across ~20 sessions / thousands of turns | not observed |
| claude-sonnet-5 | 0 across 2 sessions (one with 121 thinking turns / 12 questions) | not observed |

A 121-thinking-turn Sonnet session would show ~18 drops at Fable's rate; it
showed none. So the double-thinking mis-bin appears specific to
claude-fable-5 with extended thinking active — not to all extended-thinking
models. Every session above had extended thinking enabled, so thinking-active
alone is not sufficient to trigger it.

Impact

• Users act on AskUserQuestion prompts without the recommendation/analysis

the model wrote immediately above them.

• The dropped text is unrecoverable — it is in neither the UI nor the

transcript, so --resume sessions and transcript audits lose it too.

• Downstream hook/audit tooling that reads the transcript to verify "did

the model render text before asking" cannot attribute the failure
correctly (model vs harness).

Reproduction

Not deterministic. Correlates with: extended thinking enabled, a turn shape
of thinking → text → tool_use, and (in the failing cases) the thinking
being recorded as two entries. A session mixing long-thinking turns with
text-then-AskUserQuestion turns reproduced it 4 times in ~10 minutes.

Ask

Check the stream-event classification path for thinking→text transitions —
specifically whether a text block arriving immediately after a thinking
block boundary can be binned as a second (redacted) thinking entry, which
would remove it from both the renderer and the transcript writer while the
in-memory conversation (replayed to the model on later turns) still carries
it as text.