VS Code extension (current v2.1.145 — also v2.1.140 after rollback): large assistant text responses after multi-tool dispatch chains silently fail to render

Resolved 💬 3 comments Opened May 21, 2026 by acelarski Closed May 21, 2026

Summary

In the VS Code extension (anthropic.claude-code on Windows 11), large final assistant text responses (~2–13 KB) fail to render in the chat UI when produced at the end of a long tool-dispatch chain (multiple Agent, Read, Glob, Grep, Skill, sometimes AskUserQuestion round-trips). The model produces the response, the harness writes it to the session JSONL on disk, but the UI displays nothing — only the user's prompt remains visible.

The conversation state is intact server-side: the next turn the model can see its own un-rendered response in context and responds coherently. The failure is strictly in the extension's render layer.

Affected versions — please do not dismiss as \"use the latest\"

  • First observed on v2.1.145 (latest at the time the bug appeared).
  • I rolled back to v2.1.140 hoping for a fix. The bug persisted in v2.1.140.
  • So this is reproducible in both the current latest (v2.1.145) and the prior release (v2.1.140) — it is not a regression introduced after v2.1.140, and it is not fixed by being on the newest version.

Rollback effectiveness confirmed via %USERPROFILE%\.vscode\extensions\.obsolete:

{
  ...,
  "anthropic.claude-code-2.1.100-win32-x64": true,
  "anthropic.claude-code-2.1.145-win32-x64": true
}

After rollback, v2.1.140 is the active version per extensions.json. The bug still occurs.

Why I'm certain it's the renderer, not the model

For each affected session, the session JSONL on disk (%USERPROFILE%\.claude\projects\<project>\<session-id>.jsonl) contains the full assistant text block as the last assistant/text message. I extracted these directly with a PowerShell parse of the JSONL.

Concrete repros (May 21 2026)

All sessions from the same Windows 11 VS Code instance, same project root. Sessions before yesterday ~16:10 local were on v2.1.145; sessions after the rollback are on v2.1.140. Both versions exhibit the failure.

Three sessions hit the render-drop bug. A fourth hit a different, more severe failure (no assistant text at all — included as a secondary observation).

| Session ID | Wall clock | Active ext. version | Lines in JSONL | Last assistant text size | Tool chain before final message | Failure |
|---|---|---|---|---|---|---|
| 27c5bcbb-f092-46e3-a4be-99a154ac8399 | 10:02 | v2.1.140 (post-rollback) | 61 | 2,119 chars | Agent × 3, Read, AskUserQuestion × 4 | Final assistant text on disk, not rendered |
| 87913e33-f953-4722-8b87-949da7f4058e | 10:38 | v2.1.140 (post-rollback) | 59 | 12,393 chars | Skill, Read, Agent × 2, Glob × 3, Grep × 2, Read | Final assistant text on disk, not rendered |
| 7b0a1d24-ab8c-4ee6-be23-d3fbaaf4b368 | 12:48 | v2.1.140 (post-rollback) | 30 | 13,257 chars | Skill, Read, Agent, Glob × 3, Grep × 2, Read (no AskUserQuestion in chain) | Final assistant text on disk, not rendered |
| c5bc54f9-4bc6-43fe-ba2a-60f21bc90644 | 12:42 | v2.1.140 (post-rollback) | 15 | 0 chars (zero assistant text turns) | — | Different bug: no assistant text produced at all; UI showed thinking/working state then silence |

The third row is important: AskUserQuestion is NOT required to trigger the render drop. The common factor across all three render-drop repros is (a) many Agent / file-system tool dispatches before the final message and (b) a large final text response.

Additionally, the original instance of this bug that triggered the rollback occurred earlier on v2.1.145 in a separate ongoing session — same shape (multi-tool chain → large final assistant message → silent drop). The JSONL for that one also contains the missing message in full.

VS Code logs are empty

Every VS Code log directory under %APPDATA%\Code\logs\ (going back at least a week) contains zero files. I cannot pull any extension-side console errors from the standard log location. Either logging is disabled in default builds, or the extension logs elsewhere — pointer to the right log location would help future bug reports.

Repro template

  1. In VS Code with anthropic.claude-code (either v2.1.145 or v2.1.140) active on Windows 11.
  2. Send a prompt that elicits a chain of tool dispatches: e.g., invoke a slash command that triggers a Skill then dispatches an Agent sub-agent, then issues several Read/Glob/Grep calls, then emits a single large (~10 KB) final text response.
  3. Observe: tool calls render normally; the final large text response does not appear in the chat panel. Only the user's original prompt is visible.
  4. Open the session JSONL on disk; the last assistant/text content block contains the full response.
  5. Restart VS Code: prior un-rendered messages remain un-rendered. Sending a new prompt in the same session: the model sees the missing response in its context and replies coherently — confirming the harness has the data.

What it looks like (hypothesis)

Streaming-buffer or render-pipeline state issue triggered when a large text message follows many tool round-trips in the same turn. Buffer overflow, missed message_stop event in the stream consumer, or a UI state machine that doesn't re-render the assistant block after the last tool result is processed.

Environment

  • OS: Windows 11 Pro 10.0.26200
  • VS Code: current stable
  • Extension: anthropic.claude-codebug present in v2.1.145 (current latest) AND v2.1.140
  • Project: ~10 GB monorepo, .NET solution; behavior is not project-specific

What I can provide

I have the full JSONL files for all affected sessions locally and am happy to share session IDs / timestamps / extracted message structures via a private channel if Anthropic engineers want raw repro data (the JSONL bodies contain proprietary content that I can't paste publicly).

Severity

High for users running architectural / multi-step consulting workflows: any prompt that triggers multi-tool chains followed by a large final text reliably hits the bug, making the extension effectively unusable for long-form sessions without out-of-band JSONL extraction as a workaround.

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗