Desktop app: assistant text preceding a tool call is never rendered — only post-tool-result text displays

Status Open

Reported on v2.1.206

Maintainer reply None cached

Activity 3 comments · opened Jul 11, 2026

Summary

In Claude Code sessions run inside the Claude Desktop app (macOS), assistant message text that precedes a tool call in the same turn is not rendered in the UI. Only text emitted after the final tool result (the turn-final message) displays. The swallowed text exists in the session transcript (JSONL) and in model context — later turns can quote it verbatim — but the user never sees it.

Environment

Claude Code 2.1.206, local agent session inside the Claude Desktop app (macOS)
macOS 26.5.2 (Build 25F84)
Model: claude-fable-5

Observed behavior (two independent instances, same week)

2026-07-10: A turn consisting of a ~1,200-word structured markdown reflection followed by a single AskUserQuestion tool call rendered ONLY the question UI. The preceding reflection never displayed. The user answered the questions (the option chips happened to be self-contained) and only discovered the loss afterward, asking why the model had "held" its response. The text was present in model context and was re-delivered verbatim on request.
2026-07-06 (separate session): Several paragraphs of editorial prose preceding file-write tool calls were not rendered; only the short post-tool closing line displayed. Verified at transcript level: content present in the session JSONL (grep-confirmed), absent from the UI. Notably, both user and model initially misdiagnosed this as a model-side omission before transcript inspection exonerated the turn.

Expected

All assistant text should render in order, interleaved with tool-call/result blocks — or at minimum, pre-tool text should render when the turn completes.

Impact

Beyond the information loss itself, two second-order effects:

It corrupts the collaboration record. In instance 2, both parties initially concluded the model had failed to produce something it had in fact produced — the bug masquerades as model unreliability, which is corrosive in long-running collaborative sessions.
It structurally conflicts with AskUserQuestion. Context for the questions must precede the tool call by construction, so current behavior guarantees users answer questions whose context is invisible. No correct ordering exists under this bug.

User note (verbatim, included at his request): "this is quite important to me for communication and pacing purposes and because I don't like making [the model] repeat things through no fault of its own."

Workaround

Place all load-bearing prose in the turn-final message, after all tool calls — which works everywhere except AskUserQuestion (see above).

---
Filed jointly by Callaway Sprinkle and Claude (Fable 5, the sessions' assistant): drafted by the latter, authorized and submitted by the former.

View original on GitHub ↗

3 Comments

Gythiro · 1 month ago

Reproducing on Windows desktop app — with an extra data point that may connect this issue to #76635.

Environment: Claude desktop app 1.20186.1.0 (Microsoft Store), bundled CLI core 2.1.202 (Claude Code), Windows 11, model claude-fable-5, heavy agentic session (background tasks + file edits), permission mode: auto.

Two distinct cases observed in the same session:

Persisted but never rendered (matches this issue): an assistant message containing only a text block, emitted between tool calls, exists in the session .jsonl as a standalone assistant record — but never renders. One additional detail beyond the OP: the text is also absent from the expanded "used N tools" activity group, so there is no way to view it anywhere in the UI.

Not persisted at all (what #76635 reports for the CLI — but here on the desktop app, with ordinary tool calls and no AskUserQuestion involved): a text block that shared one assistant response with tool_use blocks (Write/Bash) left zero trace in the .jsonl — multiple distinctive substrings searched, 0 hits — while the same turn's tool_use/tool_result records are present, and a control text block that ended a later turn was persisted and rendered normally.

So the swallowing appears to have two layers: a desktop rendering gap (this issue / #75025), and a deeper turn-serialization loss (#76635) that also reproduces on the desktop app. Happy to provide sanitized .jsonl excerpts on request.

callawaysprinkle · 1 month ago

macOS desktop reproduction of the #76635 turn shape — with block-level .jsonl anatomy showing the drop is block-type-selective within a single message.

This matches @Gythiro's case 2 (not persisted at all), triggered by the exact turn shape #76635 reports on the CLI — tool calls → long assistant text → AskUserQuestion — here on the macOS desktop app, extending the platform matrix (Windows desktop + Windows CLI + macOS desktop).

Environment: Claude Code desktop app, bundled CLI core 2.1.205, agent SDK 0.3.205, macOS (Darwin 25.5.0), model claude-fable-5, local project session in a git worktree, heavy agentic session (background subagents + file edits), permission mode: auto.

Instance (2026-07-11, session 26023f6f-ee88-42fc-aef3-22049a99c15e): several file-edit/Bash tool calls, then a ~9k-char analysis addressed to the user, then AskUserQuestion ending the same turn. Only the question card rendered; the analysis appeared nowhere in the UI.

Block-level anatomy — the .jsonl writer emits one record per content block; all three surviving records carry the same message id msg_011CcvaCXAGr88PfC6AsbMvG / req_011CcvaCUFuGFMR8PyqQ6NPp:

2026-07-11T16:20:53.709Z  assistant  [thinking]
2026-07-11T16:20:53.722Z  assistant  [thinking]
2026-07-11T16:20:58.194Z  assistant  [tool_use: AskUserQuestion]

The message's thinking and tool_use blocks persisted; its text block did not — there is no text record for that message id anywhere in the 1,086-line transcript (grep-verified; distinctive multi-word phrases from the lost text match nothing except a later manual re-print). So whatever drops the text is selective by block type within one message, not a whole-message or whole-request serialization loss.

Control, same session, +11 minutes: the assistant re-sent the same content as a text-only turn (msg_011Ccvb9Sr6vRfqF4pqBNjg2) → persisted normally as [thinking][text: 9,070 chars] and rendered fine.

Corroborating #76635's API-side-survival claim concretely: when asked to re-print, the assistant reproduced the lost message from its own context — the API-side conversation replay still contained the text block. So the block was present in the API response and in in-memory conversation state; it is dropped at or before per-block .jsonl persistence, and never rendered.

Redacted .jsonl slice around those timestamps available on request.

glen-84 · 6 days ago

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)._