[BUG] Assistant text between tool calls is not displayed — regardless of focus view (only turn-initial and turn-final text renders reliably)
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
When using Claude Fable 5: Assistant text emitted between tool calls within a single turn is silently dropped from the live TUI. Only two text positions render consistently:
- Turn-initial text (before the first tool call of the turn)
- Turn-final text (after the last tool result, with no tool call following)
Everything in between — direct answers, warnings, findings, explanations the model writes while working — can be invisible. There is no indicator that text was suppressed. The verbose transcript (Ctrl+O) does not show it either, and the text is not persisted to the on-disk session log (~/.claude/projects/<project>/<session-id>.jsonl).
This is particular bad in combination with the AskUserQuestion tool: The model asks questions, but I never get the immediately preceding detailed explanation that the model tried to provide.
This is not focus mode: it reproduces with focus view off.
I notice that some transcripts have between tool-call messages, but in others it's suppressed - especially when chaining AskUserQuestion tool or the experimental setup below.
I do not get these issues with Sonnet or Opus.
What Should Happen?
Assistant prose should render wherever the model emits it.
At minimum the TUI should show a persistent "N hidden messages" indicator with a way to expand. Hiding tool noise is fine; hiding the assistant's words loses substantive content (answers, warnings, caveats) with no trace.
Error Messages/Logs
Steps to Reproduce
Ask Claude Fable 5 to run a controlled test, e.g.:
Run a harmless bash command, then write a distinctive marker paragraph (e.g. "🟣 MARKER-DELTA 🟣"), then run a second harmless bash command, then end the turn asking whether I saw the marker.
Result: the two Bash calls render; the marker paragraph between them never
appears.
Test matrix (as per Claude 5 Fable)
| # | Renderer | Focus view | Experiment flags | Text position | Shown? |
|---|----------|-----------|------------------|---------------|--------|
| 1 | inline | n/a (unavailable) | default | turn-initial → AskUserQuestion | ✅ visible |
| 2 | inline | n/a | default | between two AskUserQuestion blocks | ❌ hidden |
| 3 | inline | n/a | default | Bash result → text → AskUserQuestion | ❌ hidden |
| 4 | inline | n/a | default | Bash result → text → Bash | ❌ hidden |
| 5 | fullscreen (/tui fullscreen) | off (toggled via /focus) | default | Bash → text → Bash | ❌ hidden |
| 6 | inline | n/a | opted out (see below) | Bash → text → Bash | ❌ hidden |
| — | any | any | any | turn-final (after last tool result) | ✅ visible |
| 7 | either | off | opted out | hidden text, viewed via Ctrl+O verbose transcript | ❌ still hidden |
| 8 | either | off | opted out | hidden text, in on-disk session .jsonl | ❌ not persisted |
Experiment opt-out for row 6: removed tengu_swann_brevity: "focused" fromcachedGrowthBookFeatures in ~/.claude.json and launched withCLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC=1 (verified active in-session). No
change.
The same issue does not appear with Sonnet or Opus, but reproduces with Fable in new sessions.
Claude Model
Fable 5
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
2.1.173
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
WSL (Windows Subsystem for Linux)
WSL2 (Linux 6.6.87.2-microsoft-standard-WSL2), bash, Windows Terminal
Additional Information
Plan: Max subscription
Showing cached comments. Read the full discussion on GitHub ↗
3 Comments
Note: I cannot verify whether this could be model problem: maybe Claude Fable 5 outputs its explanation in thinking blocks, and doesn't notice that. That would be a model issue and not a Claude Code bug. It insists that it can distinguish between both though, and the above test reproduces in a fresh session for me.
I do observe that Claude 5 Fable is often confused in AskUserQuestion sessions where it routinely believes it provided a visible explanation before the AskUserQuestion tool (with the question refering to the "above explanation"), when no explanation is visible - that's why I filed the bug report. In these cases, I always need to write "Chat about this" and ask it to provide the explanation without calling the AskUserQuestion tool.
I've noticed this as well. Started doing it some time within the past week for me, near as I can tell.
I've been using Fable pretty much nonstop starting around that time, so it _could_ be model-specific. If I see it happen with Opus I'll come back and mention it.
Note: This could be a duplicate: https://github.com/anthropics/claude-code/issues/67426
Adding a macOS data point plus some cross-references, since both reports in this thread so far are on Windows/WSL.
Environment: Claude Code 2.1.221 (CLI), macOS (Darwin 23.6.0), zsh, model
claude-fable-5.What reproduces (matches rows 1, 3, and the turn-final row of the test matrix):
AskUserQuestioncall in the same response never renders — the question widget appears with no preceding explanation. This bites hardest in approval workflows: the model drafts a comment/PR body as text, then callsAskUserQuestionto ask "post this?", and the draft is invisible.previewfield onAskUserQuestionoptions does not mitigate — the preceding prose is still lost.Related open issues that look like the same underlying problem or close relatives:
AskUserQuestionwidget hides the immediately preceding text message (the specific case above).jsonlin some modes, matching rows 7–8 here (so this isn't purely a render-layer issue)On the model-vs-harness question raised earlier in this thread: #81853 reports the missing text is present in the Ctrl+O transcript on their setup, which suggests the model did emit ordinary text blocks and the display layer dropped them — while this issue's rows 7–8 document cases where the text is absent from the transcript and the JSONL too. Both may be true in different modes, but in neither case does it look like thinking-block confusion: the text is emitted and lost downstream.
Workaround we've settled on: instruct the model to end the turn with the substantive text as the final message (no tool call after it), and handle approval/next-step in a separate turn. Reliable, but it doubles round-trips for every approval-gated flow.