Assistant text before an AskUserQuestion dialog in the same turn is not displayed

Narrowed this down with a controlled A/B repro in the same session:

• Text block + AskUserQuestion as the first assistant message of a turn: text renders correctly.
• Text block + AskUserQuestion in a continuation message (i.e. the assistant message follows a tool_result earlier in the same turn): the text block is dropped; only the question dialog renders.

So the trigger is the combination: (assistant message follows a tool_result in the same turn) AND (message contains an AskUserQuestion tool_use) → preceding text blocks in that message are not displayed. Text in continuation messages containing other tool calls (Bash, Edit) renders fine, as does text+AskUserQuestion at turn start.

Verified by emitting marker strings (MARKER-7F3A9 visible / MARKER-2B8C4 dropped) and asking the user via the dialog itself whether the marker was visible.

🤖 Generated with Claude Code

Environment metadata for the repro above:

• Claude Code: v2.1.165, native installer (~/.local/share/claude/versions/2.1.165)
• Model: claude-opus-4-8[1m] (Opus 4.8, 1M context)
• OS: macOS 26.5 (Darwin 25.5.0), arm64 (M3 Max)
• Terminal: ghostty 1.3.1, TERM=xterm-256color
• Shell: zsh (homebrew)
• Permission mode during repro: auto-allow classifier active ("Allowed by auto mode classifier" visible on tool calls)
• Both dropped-text cases and the controlled A/B repro happened in a single long-running session (large context, several subagent/skill invocations earlier in the turn history)

🤖 Generated with Claude Code

Correction to the environment details: the affected session runs inside a herdr pane (terminal session manager, HERDR_ENV=1) within ghostty — so there is a multiplexing layer between Claude Code and the terminal that the earlier comment omitted. We are re-running the A/B repro in a bare ghostty shell (and tmux) to isolate whether the text drop is Claude Code's renderer or the multiplexer; will report back.

🤖 Generated with Claude Code

Isolation result: the drop reproduces in bare ghostty with no multiplexer in the stack (herdr exited, no tmux, same machine/version). Same A/B shape as before — a marker text block in a mid-turn continuation message containing AskUserQuestion was not displayed; only the dialog rendered.

So the multiplexer is exonerated and the original report stands: Claude Code's renderer drops text blocks from an assistant message when that message (a) follows a tool_result within the same turn and (b) also contains an AskUserQuestion tool_use.

🤖 Generated with Claude Code

Related issues, and why this is distinct:

• #62493 (AskUserQuestion overlay obscures previous message) and #64776 (Desktop: dialog hides most of the message) describe occlusion — the text exists but is covered or squeezed while the dialog is open.
• #61410 describes dimming of the final text when a turn ends with AskUserQuestion.

This issue is a permanent drop: after the dialog is answered and closed, the text block is still absent from terminal scrollback (verified — the marker line never appears, before, during, or after the dialog). And the trigger is narrower: only text in a mid-turn continuation message (one following a tool_result in the same turn) that also contains the AskUserQuestion tool_use. The same text+question shape at the start of a turn renders fine.

Plausibly shares a root cause with #62493 (text suppressed while the dialog paints, never flushed), but the observable behavior and repro conditions differ.

🤖 Generated with Claude Code

Here is a simple prompt to reproduce the bug:

Use the Bash tool to run echo hi. After you see the result, output one line of

normal message text that is exactly SENTINEL_TRIGGER, then immediately use the
AskUserQuestion tool to ask me to choose Yes or No. Keep SENTINEL_TRIGGER as
ordinary text, not inside the question.

<img width="997" height="728" alt="Image" src="https://github.com/user-attachments/assets/0cff5d3f-878f-4643-8cbf-ca5885cf5a53" />

Still hitting this on v2.1.177 (macOS), so it's not fixed in the latest build either.

One angle the thread doesn't cover yet: this is actively shaping how skills get written. We have approval-gate skills (/ship, /plan-check) that now hard-code a workaround — emit the explanation as the last message of one turn, then fire AskUserQuestion at the start of the next — purely because same-turn text vanishes. So it's not just cosmetic: every gated workflow eats an extra turn and a throwaway user reply to dodge it.

I have an interactive review skill and this is really bad. I've tried pretty much any possible workaround and all of them are plain garbage. Question cannot render markdown, the panel type question cannot show freeform option, the panel type doesn't fit long markdown descriptions, and can't even remember what I've tried.

Now only option that works is that in the first turn I render the review issue rationale, then ask user to triage the issue and then in the next turn ask the question. This is really stupid and makes the skill pretty much unusable.

For me I only saw this after switching to Fable. After being forced to go back to Opus, it resumed normal functionality for my use cases.

For me I only saw this after switching to Fable. After being forced to go back to Opus, it resumed normal functionality for my use cases.

I see, reverted my workarounds and tested with Opus again and it seems to work correctly. Thanks!

I'm convinced Anthropic doesn't even use Claude Code at this point. This is insane.

I'm convinced Anthropic doesn't even use Claude Code at this point. This is insane.

X2

Same-session A/B/C across three models: reproduces on Fable 5, not on Sonnet 5 or Opus 4.8

I ran a controlled comparison in the desktop app on Windows (app v1.19367.0, bundled Claude Code runtime 2.1.202 — the latest release, verified from the app package), using the minimal turn shape from @ozturkberkay's repro: a Bash tool call, then a plain text block (TEST_TEXT), then an immediate AskUserQuestion in the same continuation turn. After each question I confirmed via the dialog itself whether the TEST_TEXT line was visible in the transcript.

Same machine, same session structure, only the model changed:

| Model | Turn shape | TEST_TEXT visible? |
|-------|-----------|----------------------|
| Sonnet 5 | Bash → text → AskUserQuestion | ✅ Yes |
| Opus 4.8 | Bash → text → AskUserQuestion | ✅ Yes |
| Fable 5 | Bash → text → AskUserQuestion | ❌ No — text dropped |

With Fable 5 the transcript jumped straight from the Bash result to the question dialog; the TEST_TEXT line between them never rendered. With Sonnet 5 and Opus 4.8, the exact same structure rendered the text correctly.

This lines up with @dsbecker's earlier observation ("only saw this after switching to Fable; reverting to Opus restored normal behavior").

Two takeaways worth flagging:

• The trigger correlates with the model (Fable), not with context size, at least on this build.
• Not fixed in the latest release. The bundled runtime is 2.1.202 (the newest published version). The changelog through 2.1.202 lists no fix for the pre-question text drop — only the unrelated 2.1.200 auto-continue change — and I reproduced the bug on this exact build.

Screenshots below: Sonnet 5 and Opus 4.8 showing the text, Fable 5 with it missing.

<img width="1398" height="863" alt="Image" src="https://github.com/user-attachments/assets/3378f8d6-cbf9-40d4-bbe5-a7acfb73e2c3" />

<img width="1251" height="1000" alt="Image" src="https://github.com/user-attachments/assets/6ded5a84-a1a0-46fe-9100-66bf355e78d6" />

<img width="1266" height="1023" alt="Image" src="https://github.com/user-attachments/assets/f9185d1c-925c-4603-a754-baab794d279f" />

Update (2026-07-15): no longer reproducible with Fable 5 on my setup

I re-ran the same reproduction today — a distinctive marker text emitted in the same turn immediately before an AskUserQuestion tool call — and the text now renders correctly before the dialog with Fable 5.

Environment:

• Claude Code desktop app (Windows 11), current bundled build as of 2026-07-15 (2.1.2xx series)
• Model: claude-fable-5

Notes:

• I checked the changelog up to 2.1.210 and found no entry explicitly mentioning this fix, so it may have been fixed server-side (model output formatting) rather than in the client — which would be consistent with the model-correlated pattern observed here and in #67051 / #67230.
• If others can confirm it no longer reproduces on their setups, this issue (and #67051) may be closeable.

It started happening to me yesterday. Very annoying when you have skills that elaborate on several options and then ask for a choice, and they do it multiple times as part of their normal working.

<img width="654" height="460" alt="Image" src="https://github.com/user-attachments/assets/9bf51821-84b0-4a59-8fa4-d7b22f2fbd69" />

<img width="776" height="1256" alt="Image" src="https://github.com/user-attachments/assets/c7e88b9c-7e33-401a-bc13-f8ec89b687c3" />