[BUG] v2.1.141 regression: VSCode stream stalls at ~670 bytes after tool_use; UI hangs in "thinking" 5 min, work silently lost

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

After upgrading the VSCode extension to v2.1.141, streaming responses occasionally die mid-turn: the SSE stream sends ~650–700 bytes (enough for a tool_use block to be dispatched) and then goes silent. The webview shows "thinking" until the 5-minute idleDeadlineMs expires.

The damaging part is what happens to the user:

1. The tool_use block executed server-side, so files on disk were modified.
2. The stream then stalled, so the assistant's final explanatory message never arrived.
3. The turn is not recorded in the transcript — UI just keeps spinning.
4. The user is left with file mutations on disk and no record of what was changed, why, or whether it completed.

For a writing/editing workflow this is worse than a crash, because a crash signals "something broke." Here you can't tell whether the on-disk state is the model's intended final state or a half-applied stub.

4 occurrences within ~30 min of the upgrade. 0 occurrences in the prior 2 days on v2.1.140 with the same project and workflow.

What Should Happen?

The stream should complete normally: the assistant's final message should reach the webview after the tool_use round-trip, the turn should be recorded in the transcript, and the UI's "thinking" indicator should clear.

At minimum (even if the underlying stream issue is hard to fix immediately), when the webview observes sdk_stream_ended_no_result { had_error: true }, it should surface a visible error toast in the chat — not silently leave the "thinking" indicator running for 5 minutes. That alone would prevent the silent-data-loss class of damage.

Error Messages/Logs

[WARN] [Stall] stream_idle_partial lastChunkAgeMs=15000 bytesTotal=668 idleDeadlineMs=300000
log_event sdk_stream_ended_no_result { had_error: true, subagent_count: 0, message_count: 17 }

[WARN] [Stall] stream_idle_partial lastChunkAgeMs=15001 bytesTotal=704 idleDeadlineMs=300000
log_event sdk_stream_ended_no_result { had_error: true, subagent_count: 0, message_count: 8 }

[WARN] [Stall] stream_idle_partial lastChunkAgeMs=15000 bytesTotal=659 idleDeadlineMs=300000
log_event sdk_stream_ended_no_result { had_error: true, subagent_count: 0, message_count: 10 }

[WARN] [Stall] stream_idle_partial lastChunkAgeMs=15001 bytesTotal=654 idleDeadlineMs=300000
log_event sdk_stream_ended_no_result { had_error: true, subagent_count: 0, message_count: 18 }

(bytesTotal consistently 654–704 across all 4 failures — large enough for a tool_use block, small enough that no closing assistant message was delivered.)

Each stall was preceded by 3–5 repeats of:
[DEBUG] Fast mode unavailable: Fast mode requires extra usage billing · /extra-usage to enable
[DEBUG] Org fast mode: disabled (extra_usage_disabled)

Steps to Reproduce

1. Use Claude Code VSCode extension v2.1.141 on Linux.
2. Open a normal editing session — no plan mode, no special config.
3. Submit a prompt that triggers at least one Edit / Write tool_use (turns that follow a file mutation seem most likely to trigger; Read/Bash-only turns have not reproduced so far in my sample).
4. Within 5–10 turns: a turn's stream stalls at ~670 bytes; UI hangs in "thinking" for 5 minutes; tool_use has already mutated files but no final message is recorded.

Rolling back the extension to v2.1.140 makes the stall stop. 0 occurrences across ~2 days of the same workflow on v2.1.140 in the immediately preceding window.

A/B test on fast-mode (rules out a fast-mode-related hypothesis):

• extra_usage_disabled → Fast mode unavailable → stall reproduces
• extra_usage_enabled → Fast mode available → stall still reproduces with identical signature

So the "Fast mode unavailable" debug spam preceding each stall is correlated noise, not causal.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.140

Claude Code Version

2.1.119 (Claude Code) — CLI version per claude --version 2.1.141 — VSCode extension version (this is the one exhibiting the bug; the bug is in the extension, not the CLI)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

VS Code integrated terminal

Additional Information

Related issues (cross-reference):

• #54434 — SSE stream stalls without message_stop, same [Stall] stream_idle_partial log signature. Reported on v2.1.119 with no clear version boundary. If same root cause, the regression in v2.1.141 has materially worsened the frequency.
• #52151 — Unhandled case: [object Object] toast, Bedrock + long-session triggered. Same UI surface as what users see on v2.1.141 when this stream issue fires.
• #58276 — Fast-mode + auto-mode reactive-state hot loop. Ruled out as root cause by the A/B test above, though the Fast mode unavailable debug spam in my logs is likely the same separate UI-side issue.

Telemetry note: my environment has isTelemetryEnabled=false and [3P telemetry] Event dropped (no event logger initialized) confirmed in the extension logs, so these failures are NOT auto-reported. Filing manually for visibility.

Suggested triage actions:

• Diff v2.1.140 ↔ v2.1.141 changes in the SSE handling / message_stop path
• Add a webview-side error toast when sdk_stream_ended_no_result { had_error: true } fires (interim mitigation — at minimum the user should know the turn failed instead of silently spinning)
• Apply labels: regression, area:streaming, platform:vscode

I can attach a sanitized exthost log slice on request (raw log contains workspace paths).