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

Activity

1. OffCrazyFreak commented on Sep 12, 2026

   

   OffCrazyFreak

   on Sep 12, 2026

   More actions

   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.
2. jameswasher commented on Sep 22, 2026

   

   jameswasher

   on Sep 22, 2026

   Author

   More actions

   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.
3. beardedarchitect commented on Sep 25, 2026

   

   beardedarchitect

   on Sep 25, 2026

   More actions

   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.
4. Jamie-Kent commented on Sep 25, 2026

   

   Jamie-Kent

   on Sep 25, 2026

   More actions

   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".
5. AndrewEyesman commented on Sep 26, 2026

   

   AndrewEyesman

   on Sep 26, 2026

   More actions

   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").
6. kkolodziej7 commented on Sep 30, 2026

   

   kkolodziej7

   on Sep 30, 2026

   More actions

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

   closed this as completedin #2829on Oct 2, 2026