[Bug] Fable 5 writes user-facing output into hidden thinking instead of a text block — same as #66112, fixed for Opus but still reproduces on Fable

Also reproduces on Windows (CLI TUI), so this is not platform-specific.

• OS: Windows 11 Pro (10.0.26200)
• Claude Code: 2.1.200 (CLI/TUI, PowerShell)
• Model: claude-fable-5

Same symptom as reported: when using fable-5, user-facing prose written right before an AskUserQuestion (or in the same turn) never renders — not a single line appears in the terminal. The model then proceeds as if the text had been delivered.

Model-dependent, not environment-dependent: switching the same session to Opus 4.8 makes the problem disappear entirely . Reproduces only while fable-5 is the active model.

Still reproduces on 2.1.229, and here the swallowed text is recoverable from the JSONL

Two independent organic reproductions from 2026-08-17, plus a variant of the block signature that may help localize the fault.

Environment

• Claude Code 2.1.229 (28 releases after the 2.1.201 in the report)
• Model: claude-fable-5, thinking on (defaults)
• Platform: darwin, Claude Code desktop app

Neither session used a synthetic prompt — these are ordinary work sessions; nobody asked for "a very long text".

Variant block signature: the thinking blocks are populated, not empty

The report documents [thinking (empty, signature only)] × 2 + tool_use. In our sessions the swallowed deliverable is present in the JSONL, carried inside a thinking-typed block with a full signature:

[thinking  7661 chars — English planning prose, ordinary summarized-thinking voice]
[thinking    75 chars — a second-person status/answer line addressed to the user, in the user's language]
[tool_use: Write]

The trailing thinking block is register-distinct from the first: a polished, second-person message to the user, not planning. When a text block is correctly emitted in the same session, that trailing block is absent and the shape is [thinking, text, tool_use].

So on this evidence the content is not lost upstream of persistence — it is emitted or classified as thinking and therefore never rendered. That may make it easier to localize than the empty-block case.

Frequency (every block below was read and content-verified, not keyword-matched)

• Session A: 23 of 48 assistant messages carried user-facing prose inside a thinking block; only 10 messages contained a real text block.
• Session B (different project, different task, 20 minutes later): 3 of 39.

User-visible impact

In session A the user asked the same direct question three times ("do I need to open a new session to take this over?"). All three answers were generated — they are readable in the JSONL, inside thinking blocks — and none of them rendered. From the user's side the assistant appeared to ignore the question while continuing to edit files and open further AskUserQuestion dialogs. The behavioural pattern is the one reported in #66960; this issue looks like its mechanical cause.

On the stale label — this is not stale; it reproduces on the current version.

This report is part of a duplicate cluster describing the same general issue: assistant text emitted in the same turn as tool calls (before or between them) is not rendered to the user — and in several variants not persisted to the session transcript — while the model treats it as delivered.

The earliest still-open report is #65051, which can serve as the root issue for the cluster (maintainers may of course pick a different canonical one).

_Drafted by Claude (Anthropic AI assistant)._

Sharper localization: the bug is positional. Turn-initial text survives, mid-turn text between tool calls does not.

Retested today on claude-fable-5 (darwin) with the original repro prompt, then variants. Results from one session, verified against the session JSONL:

1. Text emitted at the start of the turn, before the first tool call: clean. Persisted as a text block and rendered verbatim, across three attempts (190, 2,902, and 6,831 chars). The original repro prompt no longer reproduces the bug.
2. Text emitted mid-turn, after a tool result and before the next tool call: swallowed, reliably. In a turn shaped text A, Bash, text B, Bash, text C, AskUserQuestion, checkpoint A survived as a text block while B and C landed in the JSONL as thinking blocks.

Block dump of that turn:

[TEXT 130 chars] 'Variant four: text interleaved between Bash calls, ... checkpoint A, before any tool call.'
[tool_use: Bash]
[THINKING 105 chars] 'This is a checkpoint marker between two Bash calls, testing whether mid-turn narration renders correctly.'
[tool_use: Bash]
[THINKING 103 chars] "I've reached checkpoint C, right before the AskUserQuestion dialog. Next I'll proceed with that dialog."
[tool_use: AskUserQuestion]

New detail beyond the variant described in https://github.com/anthropics/claude-code/issues/74176#issuecomment-5313249145: the persisted thinking content is not the original text. It is a paraphrase of it. The model composed full sentences for B and C (B referenced the #65051 cluster by number; C described the checkpoint sequence), and what reached the JSONL is a ~100-char summary of each. The TUI renders these with a "summarized" tag, so the user sees that something was said, but the actual wording is unrecoverable from both the terminal and the transcript.

So the fix that landed for turn-initial text (the original #66112/#74176 signature) does not cover the between-tool-calls position, and that position additionally runs the content through the thinking summarizer before persisting it.

• Claude Code 2.1.251, darwin, claude-fable-5, thinking on (defaults)