Sign up
View stargazers13Sign up

[Bug]: Claude assistant text never streams in paragraph mode — ClaudeAdapterV2 drops text_delta#17270

opened16d agobySSalloxy

This issue was written by Claude Opus 5.5 (running in T3 Code) after investigating the installed nightly bundle and the upstream source.

Before submitting

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

Area

apps/server

Steps to reproduce

  1. In Settings, leave Response streaming on Show finished paragraphs (the default responseStreamingMode: "paragraph").
  2. Open a thread on the Claude provider (seen with Claude Opus 5.5).
  3. Send a prompt that produces a multi-paragraph answer without tool calls, e.g. "Write five paragraphs about the history of the printing press."
  4. Watch the assistant message while the turn runs.

Expected behavior

Each paragraph or code block of the assistant reply appears as soon as it is complete, as the setting describes ("Each paragraph or code block appears as soon as it is complete."). This worked on nightlies before the orchestrator v2 switch.

Actual behavior

No assistant text appears until the whole text block is finished; then it all appears at once. It behaves exactly like Wait for the full response (turn), regardless of the selected mode. Reasoning still streams; only the assistant reply text doesn't.

Cause, as far as I can tell from source:

  • ClaudeAdapterV2 asks the SDK for partial messages (includePartialMessages: true, ClaudeAdapterV2.ts#L866) and advertises streamsAssistantText: true (#L202).
  • But the stream_event branch (#L5855-L5899) only handles thinking blocks / thinking_delta and then unconditionally returns, so every text_delta is dropped. The file contains no text_delta handling at all.
  • Assistant text is only emitted from the final SDK assistant message via buildAssistantArtifacts (#L2562), which always sets streaming: false on the message and turn item.
  • makeAssistantStreamingFilter (assistantStreaming.ts#L92-L114) passes streaming: false events through untouched, so the paragraph splitting never gets a chance to run for Claude assistant text.

The pre-v2 adapter streamed text_delta (provider/Layers/ClaudeAdapter.ts#L2945, parent of #2829). Every commit to ClaudeAdapterV2.ts since #2829 (2026-10-02) has zero text_delta references, so this looks like a regression introduced with the new orchestrator. A likely fix is to route text_delta through a ProviderTextDeltaCoalescer the same way thinking_delta is, emitting streaming: true assistant message / turn item updates, and complete them with the final assistant snapshot.

Related but different: #17171 (live reasoning row not updating in the web UI). Here the server never emits streaming assistant text in the first place.

Impact

Minor bug or occasional failure

Version or commit

0.0.46-nightly.20261008.2833 (also still present on main @ a0066d5)

Environment

Windows 11 Pro (26300), T3 Code (Nightly) desktop app, Claude provider (Claude Agent SDK), Claude Opus 5.5. responseStreamingMode unset in settings.json (defaults to paragraph).

Logs or stack traces

shell
1# From the installed server.asar (apps/server/dist/binCli-*.mjs), ClaudeAdapterV2 stream_event branch:
2if (message.type === "stream_event" && !message.parent_tool_use_id) {
3 ...
4 } else if (event.type === "content_block_delta" && event.delta.type === "thinking_delta") {
5 ... reasoningDeltas.append(...)
6 } else if (event.type === "content_block_stop") { ... }
7 return; // text_delta never handled
8}

Screenshots, recordings, or supporting files

No response

Workaround

None via settings; switching between "Show finished paragraphs" and "Wait for the full response" makes no difference for Claude threads. Rolling back to a nightly from before 2026-10-02 restores paragraph streaming.

JJulius Marminge16d ago

Note

Grok responding on behalf of Julius.

Thanks for the detailed write-up. I checked it against main @ 0b6ec43, and the root cause you describe matches what I see in the source. I haven't reproduced it at runtime.

What the code shows

  • ClaudeAdapterV2.ts:866 sets includePartialMessages: true, and :202 advertises streamsAssistantText: true.
  • The root stream_event branch at ClaudeAdapterV2.ts:5855-5899 only handles message_start, thinking block starts, thinking_delta and content_block_stop. It then returns unconditionally. The file has no text_delta handling (the only text_delta in the adapter's tests is a protocol-logger fixture).
  • Assistant text comes only from the SDK assistant snapshot: assistantTextFromSdkMessage (:1078-1088) feeds emitAssistantTextArtifacts (:5228, called at :6549), which goes through buildAssistantArtifacts (:2562). That sets streaming: false on both the message and the turn item (:2622, :2644). The comment at :5907 notes the SDK sends one snapshot per completed content block, so a long text block lands all at once.
  • makeAssistantStreamingFilter (assistantStreaming.ts:92-128) passes streaming: false events straight through (:110-113). Paragraph splitting only runs for streaming: true events, so Claude text never reaches it.
  • There is no token or "full" mode on v2 anymore. ResponseStreamingMode is ["turn", "paragraph"] (packages/contracts/src/settings.ts:1156), and a persisted "token" setting is migrated to "paragraph" (apps/server/src/serverSettings.ts:359-367). So it looks like Claude reply text doesn't stream in any mode right now.

Regression The pre-v2 adapter streamed text_delta as content.delta with streamKind: "assistant_text" (provider/Layers/ClaudeAdapter.ts:2943-2995 @ 024d495). ClaudeAdapterV2.ts as introduced in #2829 (de34391) already had no text_delta handling, and none of the ~20 later commits to the file add it. I didn't find a comment or decision suggesting the omission was intentional, so this appears to be a gap from the rewrite. Codex streams agent text through makeProviderTextDeltaCoalescer (CodexAdapterV2.ts:3339-3393, fed at :4196-4206), and ACP appends agent_message_chunk text as streaming: true items.

Possible fix (untested)

  • In the stream_event branch at ClaudeAdapterV2.ts:5855-5899, also handle content_block_start with type: "text" and text_delta. Use a second coalescer set up like reasoningDeltas (:4876-4916).
  • While streaming, emit streaming: true assistant_message turn items. Following Codex (CodexAdapterV2.ts:3379-3393), the message would only be sent on completion.
  • The main catch is IDs. The snapshot path keys assistant text on the snapshot's message.uuid (:1085, deduplicated at :5233), and stream events don't carry that uuid. The streamed item would probably need a stable ID like ${message.id}:text:${index}, which is how thinking blocks already pair streams with snapshots (:5868, :5913), with the snapshot reusing it. Otherwise the reply may render twice. Interrupted turns and the fallbackText path (:5011) would also need to complete or skip the streamed item.

Related #17171 is a separate reasoning-row display issue (reasoning does stream from this adapter). #15767 adds coalescing for Pi, OpenCode and Cursor text_delta but doesn't touch Claude. I didn't find a duplicate issue or an open or merged PR that fixes this.

SSalloxy16d ago
Synced from GitHub

I can have Opus 5.5 Extra open a PR if it helps

JJulius Marminge3d ago

Reproduced on Linux web with Claude Opus 5.5 at a12d6ed942. With Response streaming set to Show finished paragraphs, the five-paragraph printing-press prompt displayed no assistant text while generating, then displayed the answer together. A second prompt in the same thread showed the same behavior: no new assistant text for 50 seconds, then the full ten-paragraph answer appeared. First-run recording. Windows desktop remains unverified.