[Bug]: Assistant text emitted before a tool call disappears once later text in the same turn arrives

[jameswasher]

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/client (chat timeline)

Steps to reproduce

Provider: Claude Code harness, model claude-fable-5-1.

1. Ask a question the model answers in prose, then has it call a tool (in my case SendMessage to a resumed subagent), then write a short closing line. Turn shape is text → tool_use → text.
2. Watch the timeline: the first prose block streams in and is fully readable.
3. When the tool call completes and the closing text arrives, the first block is gone. Only the closing line (e.g. "Queued to the worker.") remains as the assistant message.

Reproduced 3 of 3 times with that turn shape. Turns with no tool call render fine. A turn with text → tool_use → text that ran later did not reproduce, so it may be timing-dependent.

Expected

All text blocks in the turn stay visible, interleaved with the tool-call cards.

Actual

The earlier text block is replaced by the last text block. The substantive answer is lost from the visible transcript.

Environment

• T3 Code 0.0.41-nightly.20260911.1533
• macOS 26.6 (Darwin 25.6.0)
• Claude Code provider

Notes

Possibly related to #7137 (stalled stream truncates the message to its first delta), but the symptom here is the reverse: earlier text is dropped in favour of the last block. Happy to add a screen recording on request.

[OffCrazyFreak]

Also reproduces on the stable release, not only nightly.

• T3 Code 0.0.38 (T3-Code-0.0.38-x86_64.AppImage), Linux Mint (kernel 6.8), Claude Code provider, model claude-opus-5.
• Turn shape: text -> tool_use (AskUserQuestion) -> text after the answer. The prose written before the question is not visible in the thread once the turn continues; only the later text remains.
• Frequent enough that the workaround in our agent instructions became "put everything the user needs inside the question text", which is how we noticed it.

Happy to test a build with a fix.

[jameswasher]

Still reproduces on 0.0.43-nightly.20260921.2044 (macOS desktop, Claude Code provider, model claude-fable-5-1).

Turn shape today: text (a ~200-word draft, the actual answer) → Write → Bash → text (one short line). After the turn settled, only the short closing line was visible; the draft was inside the Worked for 19s fold. Expanding the fold shows the draft under a "Thought" label, so it is being classified as intermediate rather than as the opening response.

This looks like the same class as #7518 / #7529, which #7723 fixed on Aug 22 by keeping the opening response visible. That fix does not cover this case: here the opening text is the substantive answer and it still folds. The distinguishing factor may be that the opening text is followed by more than one tool call, or that the closing text is much shorter than the opening one.

Expected: every assistant text block in a turn stays visible in place; only tool activity folds.

[beardedarchitect]

Same here with the Claude Code provider (Claude Opus 5.5), T3 Code Nightly 0.0.43 on Windows 11. The agent shows images, then asks a question; while the question is open, the images are not visible, so I have to answer about mockups I cannot see.

[Jamie-Kent]

Same on T3 Code (Alpha) 0.0.42, macOS 27, Claude Code provider (Claude Opus 5.5). Turn shape: text (the actual answer) → Edit → Bash → text (one short line). After the turn settled, only the closing line was visible; the answer was folded under "Worked for 7.9s".

[AndrewEyesman]

Also reproduces on T3 Code (Nightly) 0.0.43, Windows 11, Claude Code 2.1.283, Claude Opus 5.5. I dug into the local data. Two separate things end up in the Worked for … fold:

1. Real text blocks before a tool call are folded

Turn shape text → tool_use → … → text. The intermediate blocks are stored as role: "assistant" in projection_thread_messages, but only the last assistant message of the turn shows outside the fold. A substantive mid-turn message (in my case, a deploy-preview URL plus findings), followed by one more tool call and a one-line closing note, was only visible after expanding the fold.

2. On Opus 5.5 / Fable 5.1, many "messages" never arrive as text at all

This is documented API behavior. The notes the model writes between tool calls come back as progress-update thinking blocks, at most one before each tool_use (Opus 5.5 migration guide: "Text between tool calls is returned in thinking blocks", thinking docs: "Progress updates between tool calls").

T3 requests --thinking-display summarized. Under summarized, progress updates are "not distinguishable from a reasoning block" (per the docs), so ClaudeAdapter maps them to reasoning_summary_text and they're stored as role: "reasoning". They show up as collapsed Thought rows, as a summary of what the model wrote to the user.

In the Claude Code transcripts, the affected responses have the shape thinking → thinking → tool_use with no text block, and the second thinking block is user-facing ("Confirmed via the contact form check that … is your real production site…"). Share of responses with that shape across my local Claude Code transcripts:

Model	≥2 thinking blocks, no text
Opus 4.8	2–4%
Opus 5.5	23%
Fable 5.1	45%

A headless A/B (10-step read-only task, model told to post an update after each tool call) gave the same miss rate with summaries on and off, so hiding summaries isn't a fix. It just makes the updates disappear entirely.

Workaround that works today

Set Claude provider Launch arguments to --thinking-display highlights. ClaudeAdapter passes it through and stops forcing summarized (it still sets showThinkingSummaries: true). With exactly that combination, a headless Opus 5.5 run returned 4/4 progress updates as normal text blocks. That fixes problem 2. Problem 1 (text folding) still applies.

Suggested fix

• Keep assistant text blocks visible in place, and fold only tool activity (the expected behavior in the original report).
• For Claude 5.x models, request highlights (the CLI's name for the API's updates mode), or otherwise render the progress-update block that immediately precedes a tool_use inline instead of as a Thought row, as the migration guide recommends ("render each non-empty thinking block ahead of the tool_use block it precedes").

[kkolodziej7]

Still reproduces on the stable T3 Code (Alpha) 0.0.44 (macOS, Claude Code provider, Claude Opus 5.5). Turn shape: text (≈12k chars, the actual answer) → Bash → text (583 chars). After the turn settled, only the closing text was visible under "Worked for 2m 19s".

What we checked (read-only):

• The hidden text is not lost. It is identical in projection_thread_messages, in the thread.message-sent events and in the provider log (same SHA-256), with a separate message id per text block.
• The cause is the fold selector in v0.0.44. deriveTerminalAssistantMessageIds (apps/web/src/components/chat/MessagesTimeline.logic.ts:530) keeps only the last assistant message per turnId. deriveTurnFolds (:648, hidden ids at :737) puts every earlier assistant message into the fold. Content and length play no part.
• The behaviour is pinned by tests (MessagesTimeline.logic.test.ts:1670 and :1858). A fix therefore has to change those tests deliberately.
• main at c18e5ea6ed does not touch this code yet.
• The trigger is a later separate assistant message in the same settled turn, not the tool call itself. When the long text is the last assistant message, it stays visible. That likely explains the "doesn't always happen" reports.

Suggested direction, same as #7529: fold tool and reasoning activity, but never add plain assistant text messages to the hidden set (or make it a setting).