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" />

Could not reproduce on v2.1.233 (macOS) — including with Fable 5, the model this thread narrowed the drop down to.

Steps used (the minimal prompt from this thread), in a fresh directory, once each with --model fable, Opus, and Sonnet:

1. Start claude.
2. Send: 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.
3. Answer the question and check the transcript.

Observed (all three models): the marker line renders between the Bash result and the question dialog, and it stays in the transcript after answering. Expected: same.

⏺ I'll run the command now.
  Ran 1 shell command
⏺ SENTINEL_FABLE
────────────────────────────────────────
 ☐ Choice
Yes or No?
❯ 1. Yes
  2. No

After answering:

⏺ SENTINEL_FABLE
⏺ User answered Claude's questions:
  ⎿  · Yes or No? → Yes

Assessment: this was a genuine bug — text the model emits right before an AskUserQuestion in the same turn is meant to render like any other assistant text, and there is nothing in the client that intentionally hides it. It no longer reproduces on the current release (v2.1.233) with any model, which matches the reports above that it stopped happening around mid-July (roughly the v2.1.210 timeframe) without a client change, so the fix appears to have landed on the model/server side for Fable 5. Changelog: https://github.com/anthropics/claude-code/blob/main/CHANGELOG.md. Closing this as fixed; if it recurs on v2.1.233 or later, please comment with the model and a /share link and we will reopen.

🤖 Generated with Claude Code

@bcherny I think this is not restricted to AskUserQuestion, it's the same bug as https://github.com/anthropics/claude-code/issues/75900. The bug is still happening, see my session just now with feedback ID 1d3c1681-1ae8-4f1c-9e31-c86909c2f8fb where responses are being swallowed.

Fable Extra High in the Mac Desktop app Claude 1.30096.5 (6e1346) 2026-08-14T21:58:49.000Z;

I was in Plan mode, rejected the plan and replied "Give me a TLDR of the plan". It responded "TLDR posted. Plan awaiting your approval." but there was none.

/debug  Responses disappearing

Found the cause: text followed by tool calls is not rendered. Fix: I now put replies last, tool calls first. Full explanation in chat.

Found it — no log needed. Your responses are not lost; they are hidden by message ordering. The client does not reliably render text that has tool calls after it in the same turn. Only the final text block of a turn is guaranteed to display.

What happened in this session

Both "disappeared" TLDRs followed the same pattern:

I wrote the TLDR text.
I then called PushNotification (your global CLAUDE.md tells me to call it every turn) and ExitPlanMode.
The client dropped the text because tool calls came after it. You saw only the plan-approval dialog.

The third attempt worked because I reversed the order: tool call first, TLDR as the last block.

The conflict in your setup

Your global CLAUDE.md rule "call PushNotification at the end of every turn" is what pushes a tool call after my final text — which is exactly the trigger. The rule and the renderer fight each other.

Yep, the issue just came back. The first time it showed up, it was fixed in less than two weeks without anyone paying much attention to this thread. Then, as soon as they finally looked into it and marked it as closed, it showed up again!

Yeah, absolutely not fixed. The issue persists with Fable 5.1 as well.

This happens to me all the time, with Opus 5.5 as well on 2.1.289

Still reproduces on Claude Code 2.1.292, VS Code extension, macOS, Opus 5.5.

Reproduced twice in one session today. Both times the turn was a text block followed by an AskUserQuestion call. The text (a drafted ticket update the question asked me to approve) never rendered: the user saw only the question and answered "you didn't show me the draft". A turn that ended in plain text with no AskUserQuestion rendered normally, earlier in the same session.

This hits hardest in the review-then-approve pattern ("here's the draft, post it?"), because the user is asked to approve content they can't see. Putting the content into the option's preview field didn't reliably fix it either: see #73009 for previews not rendering in the extension.