[Bug]: Claude provider drops thinking blocks — reasoning_text deltas are emitted without an itemId, so the UI never renders them #5542

Activity

1. some-du6e commented on Aug 21, 2026

   

   some-du6e

   on Aug 21, 2026

   More actions

   Corroborating this from a different angle — and I think the scope is actually wider than the Claude-only framing here. Verified on main @ 68966c1e (2026-08-20); the line numbers below are current, drifted from the OP's pinned 4f5834b.

   The Claude itemId gap is real and still present. content_block_start only registers text blocks via ensureAssistantTextBlock; a thinking block falls through to the early return for non-tool blocks (ClaudeAdapter.ts:2598-L2611). So on thinking_delta, assistantBlockEntry resolves undefined (ClaudeAdapter.ts:2462) and the content.delta ships with streamKind: "reasoning_text" but no itemId. Matches points 1-3 in the OP.

   But there's a second, provider-agnostic gate upstream of any renderer — and it drops reasoning for every provider, not just Claude. The ingestion layer only forwards assistant_text:

   // ProviderRuntimeIngestion.ts:1660
   const assistantDelta =
     event.type === "content.delta" && event.payload.streamKind === "assistant_text"
       ? event.payload.delta
       : undefined;

   Anything reasoning_text / reasoning_summary_text → undefined → never buffered, never dispatched as thread.message.assistant.delta. Codex emits reasoning_text (CodexAdapter.ts:1263) and reasoning_summary_text (CodexAdapter.ts:1244); OpenCode emits reasoning_text (OpenCodeAdapter.ts:771). All of them hit this same gate. So the "it renders like Codex does today" premise doesn't hold on current main — Codex reasoning doesn't render either.

   And I couldn't find the renderer the OP references. The collapsible reasoning UI from #287 / #3853 doesn't appear in current apps/web or apps/mobile: zero consumers of content.delta / streamKind / reasoning_text anywhere outside packages/contracts (the producer) and the generated Codex SDK schemas, no ReasoningBlock / ReasoningTrace / collapsible component, and no reasoning/thinking text field on the persisted assistant message (only reasoningOutputTokens token accounting). If it landed and was later removed, that's worth noting; if it never did, the fix is bigger than the itemId.

   So as I read it, getting Claude thinking traces on screen needs three things, not one:

   1. The Claude content_block_start itemId fix (this issue) — still required.
   2. Forward reasoning_text (and probably reasoning_summary_text) through ingestion instead of dropping at :1660 — unblocks Codex / OpenCode too.
   3. A client renderer + a persisted field to replay it on reload; plus the thinking.display = "summarized" SDK option (OP's second gap) so Claude actually streams non-empty thinking text.

   Happy to file the ingestion-gate / renderer pieces as a separate issue if that's cleaner than expanding this one — flagging here first since it directly changes the fix sketch.

   ---

   Written by a Claude Code agent (Opus 5) running for the account holder, who asked it to post on their behalf. The analysis and write-up are the agent's; the human only pressed the button — and says sorry for being a meatproxy.
2. razvandinculescu

   added a commit that references this issue on Aug 22, 2026

   feat(server): render Claude thinking blocks as live reasoning items

   ...

   abaa854
3. t3dotgg commented on Sep 4, 2026

   

   t3dotgg

   on Sep 4, 2026

   Member

   More actions

   Note

   🤖 GPT-6 Astra (preview) responding on behalf of Theo

   This note is part of an automated cleanup pass.

   Related report #8822 covers OpenCode specifically. OpenCodeAdapter.resolveTextStreamKind maps native reasoning parts to reasoning_text, but ProviderRuntimeIngestion still returns for content.delta streams other than assistant_text. Keep OpenCode in the shared ingestion and rendering scope already described here. Its requested behavior includes seeing reasoning while the turn runs and retaining it after the turn or reload. Fixing only Claude thinking-block IDs would not cover this report.
4. IcTxDiogo commented on Sep 9, 2026

   

   IcTxDiogo

   on Sep 9, 2026

   More actions

   Reproduced independently on stable 0.0.40 (in addition to 0.0.34-0.0.36): content_block_start still only registers text blocks via ensureAssistantTextBlock, so a thinking block falls through unrecorded and the later thinking_delta resolves no block entry — the content.delta ships with streamKind: "reasoning_text" but no itemId, matching the OP.

   Two design notes from a minimal local workaround we run with offline fixtures:

   • Giving thinking blocks their own small bounded registry (keyed per turn/block) instead of reusing assistantTextBlocks avoids a worse outcome: reusing that bookkeeping would complete a reasoning block as a mislabeled duplicate assistant message on turn end.
   • Alongside @some-du6e's ingestion finding above: with adapter-side identity fixed, we validated the full cycle locally (delta identity → completion/persistence → reload as a collapsible block). One caution from that exercise — the live path only stays cheap if the per-delta persisted update carries progress metadata rather than cumulative text; persisting full cumulative text per delta went O(N²) for us on a long thinking stream.

   Happy to share the offline fixtures/cases if useful for the fix design.
5. Wassap124 commented on Sep 16, 2026

   

   Wassap124

   on Sep 16, 2026

   More actions

   Reproduced on stable 0.0.40 (macOS 26.6.2, Claude Code CLI 2.1.273, claudeAgent with default launch args, model claude-fable-5-1[1m], effort high, auto mode). Adapter paths unchanged on main @ ccf220be: content_block_start still registers only text blocks, and handleAssistantMessage never reads thinking blocks either, so the final claude/assistant message carrying a non-empty thinking block is dropped too, not just the deltas.

   Adding a concrete user-facing failure mode this causes, since the report above frames it as "nothing renders" and this is worse than that:

   Free-text answer to AskUserQuestion gets answered inside thinking only, then the next question card says "Given that reasoning…" with nothing shown.

   1. Model calls AskUserQuestion with options.
   2. Instead of picking one, I typed a question in the "Type your own answer" box (why do you recommend no raw sink?) and submitted.
   3. The next card opened immediately: "Given that reasoning, how should the envelope travel and be named?". No explanation anywhere in the thread.

   Provider event log for the 26 seconds between my answer and the next card:

   09:13:00.945Z CANON user-input.resolved   answers: {"<question>": "why do you recommend no raw sink?"}
   09:13:00.961Z NTIVE claude/user            [tool_result] "The user answered: ...=\"why do you recommend no raw sink?\". Read the answers carefully ..."
   09:13:04.038Z NTIVE claude/stream_event/message_start
   09:13:04.838Z NTIVE claude/stream_event/content_block_start
   09:13:05 - 09:13:22  NTIVE claude/system/thinking_tokens  (x~30)
   09:13:22.187Z NTIVE claude/assistant       [thinking ""]                       # empty, signature only
   09:13:22.194Z NTIVE claude/assistant       [thinking "I've concluded a raw ... sink isn't justified—there's no consumer for it, ..."]
   09:13:22.196Z CANON item.started           AskUserQuestion
   09:13:26.229Z NTIVE claude/assistant       [tool_use AskUserQuestion] "Given that reasoning, how should the envelope travel and be named?"
   09:13:26.231Z CANON user-input.requested
   
   content_block_delta in window: 0
   text blocks: 0
   assistant thread.message-sent: 0   # last one 7 min earlier

   The model's whole answer to my question is the second thinking block. It then asks the follow-up as if I had read it. Note the thinking text did arrive non-empty in the claude/assistant notification even without --thinking-display, so for this path the "second gap" in the OP isn't the blocker; the adapter just has nowhere to put it.

   Two things worth considering beyond rendering thinking:

   • When a user-input.requested follows a user-input.resolved with no assistant text in between, surfacing the thinking summary (or at least a "model reasoned, nothing shown" marker) on the card would stop the user from guessing.
   • The tool_result T3 writes back ("The user answered: … Read the answers carefully…") could say the user cannot see thinking, so the model writes its answer as text.

   Happy to open this as a separate issue if you'd rather track the AskUserQuestion path on its own.
6. juliusmarminge commented on Sep 16, 2026

   

   juliusmarminge

   on Sep 16, 2026

   Member

   More actions

   Fixed by #11784 — provider thinking/reasoning traces now reach the timeline as expandable Thinking/Thought rows on web and mobile.
7. juliusmarminge

   closed this as completedon Sep 16, 2026