[Bug] Assistant text blocks between tool calls not rendered in terminal output

Status Closed — duplicate
Reported on v2.1.212
Maintainer reply None cached
Activity 8 comments · opened Jul 17, 2026 · closed Aug 17, 2026

Bug Description
Title: Assistant text emitted between tool calls is never rendered — main deliverable silently lost (frequent with Fable 5)

What happened:
The model (claude-fable-5) produced its main deliverable — a long standup report — as a
text block, then continued the same turn with more tool calls (MCP ToolSearch + Atlassian
getJiraIssue, then AskUserQuestion). The report text was never displayed in the terminal:
I only saw the tool activity and the final short question. I had to tell the model
"i can not see the report", and it re-sent the entire report as a new message.
This exact turn is in the attached conversation.

Worst variant — AskUserQuestion referencing invisible text:
Very often the model writes explanatory text (e.g. a proposed design or plan), then asks
me via AskUserQuestion to approve or choose ("approve this design?") — but the text the
question refers to was swallowed because tool calls followed it. I'm being asked to
decide about content I never got to see, and nothing in the UI indicates that context
is missing.

Frequency:
Happens to me repeatedly, and noticeably more often with Fable 5 than with Opus/Sonnet —
Fable seems more inclined to emit the deliverable mid-turn and then keep calling tools
after it.

Expected:
Either (a) intermediate assistant text blocks between tool calls are rendered in the
transcript, or (b) the model reliably places deliverables in the final message of a turn
(and AskUserQuestion carries or displays the context it refers to). The current
combination — model writes the answer mid-turn, UI drops it silently — loses the primary
output of the turn with no indication anything is missing.

Repro shape:
Any turn of the form: [long text block] → tool call(s) → AskUserQuestion.
The text block before the tool calls is not shown; the question often refers to it.

Environment:
Claude Code 2.1.212, model claude-fable-5, Linux/WSL2
(6.6.87.2-microsoft-standard-WSL2), zsh.

Environment Info

  • Platform: linux
  • Terminal: WarpTerminal
  • Version: 2.1.212
  • Feedback ID: d5eaef2c-1157-43b7-bbff-90525dc4b4b9

Errors

[]

View original on GitHub ↗

7 Comments

Rebel028 · 1 month ago

So I'm not insane, it really happens, thanks!

Can confirm this behaviour on MacOS

CodeWattage · 1 month ago

I thought I was going insane here too, this is driving me mad too. It's been happening for at least a week.

MacOS, Claude Code in Ghostty, Fable. All latest versions.

benkingcode · 1 month ago

I emailed Claude support about this and they said it was intentional 😐

nApucco · 1 month ago
I emailed Claude support about this and they said it was intentional 😐

They can't be serious.... WTF.
This bug has existed since more than a month and seems to be getting worse from week to week.

Before, it only happened in very specific scenarios, when the agent was <Thinking> <Message (dropped)> <Thinking> <ToolUse>
(the transcript then only shows <Thinking> <Thinking> <ToolUse>)

Now it seems messages get dropped between tool uses, or before tool uses even if the agent gets instructed to never think between writing a message and using a tool.

Claude Code becomes more and more unusable and inconsistent. And no statement from Anthropic in any of the many GitHub issues that have been created on this topic. They just get closed after a while due to "inactivity". Super frustrating.

kotok9 · 1 month ago
I emailed Claude support about this and they said it was intentional 😐

Could you share specifics? Is it an anti-distillation measure (stripping intermediate assistant blocks would make responses less useful as training data), or is there some other rationale? Would be good to have the actual reason stated in one of these issues, since support's "intentional" doesn't explain much on its own.

benkingcode · 1 month ago

@nApucco @kotok9 this is the email response I received;

This is a known behavior difference with Fable in Claude Code rather than a broken tool. Fable is tuned to hold its substantive answer until after any tool calls finish, so when it opens an AskUserQuestion dialog it can skip the lead-in prose that Opus would have shown. If you answer (or decline) the question, Fable will include that content in its follow-up — which is the "Restating it…" you saw. As a workaround you can ask it to "answer first, then ask any clarifying questions." We've passed this along to the Claude Code team as a UX gap to smooth out.
vbiroshak · 1 month ago

The explanation in that support reply doesn't match the persisted evidence in #74260, and the mismatch matters because it reframes a data-loss defect as a tuning preference. (Thanks @benkingcode for sharing the full text — having the actual rationale on the record is exactly what these threads have been missing.)

  • "Holds its substantive answer" / "skips the lead-in prose" implies the text is never written. The transcripts show otherwise: the affected messages persist as [thinking, thinking, tool_use] — and two adjacent thinking blocks cannot occur legitimately, since the API merges contiguous thinking deltas into one block. A block existed between them and was removed. Wire-level observation and verbatim-quote recovery in #74260 both confirm the model composes the text; it is then destroyed from both render and transcript.
  • It isn't an AskUserQuestion behavior. Per-tool breakdown in #74260: Bash is the most affected tool by an order of magnitude (203 vs 24 for AskUserQuestion in one corpus). This morning, on 2.1.217, the destroyed text was the announcement of a shell action — which then ran with no visible explanation — and, in the same session, the report of the investigation into that first loss.
  • "Fable will include that content in its follow-up" is not the observed behavior. The model believes the text was delivered and proceeds accordingly; nothing restates it unless the user reports not seeing it. The loss is silent on both sides, and --resume/compaction make it permanent, since the text never reaches the .jsonl.

To the Anthropic team: whatever tuning intent exists, emitted user-directed text being removed from display and persistence — measured at ~58–60% of all mid-turn prose across seven-plus machines in #74260 — is a defect, not a UX gap. An engineering response on the record in #74260 would be much more useful than a support-channel paraphrase.

---

This analysis and write-up were done by Claude (Fable 5, in Claude Code) at the user's direction.

Showing cached comments. Read the full discussion on GitHub ↗