VS Code extension: streams end with sdk_stream_ended_no_result after first chunk, on one machine only

Summary

The Claude Code VS Code extension repeatedly ends streams prematurely on a single Windows 11 machine. The request reaches the API and the first chunk is received, but then the stream sits idle for 15–30 seconds and the SDK reports sdk_stream_ended_no_result with had_error: true. Partial output renders in the UI, but the final completion event never arrives within the deadline.

The standalone CLI binary (claude --print) of the same version, on the same machine, on the same network, with the same auth, does not reproduce the issue. The bug is localized to the extension's stream handling.

Reproducibility

• Observed ~6 times across 2026-05-14 and 2026-05-15
• Reproduces across multiple chat sessions, including brand-new sessions with minimal context
• Only on this specific machine — does not reproduce on sibling Windows machine (MSI) or macOS machine running same CLI version

Empirical isolation

While a stalling session was still open in VS Code, I ran from a separate Windows Terminal on the same machine:

claude --print "say hi"

→ Clean response, no stall, no error. Same binary 2.1.142, same network, same auth. Only difference: did not pass through the extension.

Symptoms (from VS Code Output panel)

[DEBUG] attribution header x-anthropic-billing-header: cc_version=2.1.141.672; cc_entrypoint=claude-vscode
[DEBUG] Dynamic tool loading: 0/141 deferred tools included
[DEBUG] Stream started - received first chunk
[WARN] [Stall] stream_idle_partial lastChunkAgeMs=15000 bytesTotal=656 idleDeadlineMs=300000
[info] {"type":"log_event","eventName":"sdk_stream_ended_no_result","eventData":{"had_error":true,"subagent_count":0,"message_count":176}}
[WARN] Streaming stall detected: 32.3s gap between events (stall #1)

In some failures an additional UI message appears: Unhandled case: [object Object], suggesting an unhandled branch in the stream-event reducer.

Why "context too heavy" is not the cause

The "heavy context" hypothesis (large MCP tool registry + auto-loaded memory) would produce elevated time-to-first-token. Logs show the opposite: the first chunk is received (Stream started - received first chunk), then the connection stalls after receiving partial data. bytesTotal=656 is far below any reasonable payload.

Suspected trigger

Failures correlate temporally with MCP server reconnect events. The system reminders during failing sessions show claude.ai Figma and claude.ai HADES MCP repeatedly disconnecting and reconnecting. The hypothesis is that a tool-registry refresh that arrives mid-stream is not cleanly handled by the extension's stream state machine.

Environment

MCP servers active at the time of failure: claude.ai HADES MCP, claude.ai Adobe for creativity, claude.ai Canva, claude.ai Figma, and one local Tailscale-only MCP.

Steps to reproduce (best effort)

1. Open a workspace in VS Code with several MCP servers configured (5 in this case)
2. Start a new chat in the Claude Code panel
3. Submit any prompt
4. Observe in some sessions: stream begins, partial output is rendered, then SDK marks sdk_stream_ended_no_result with had_error: true after ~15–32 seconds of idle

Failure is intermittent but high enough to occur 6× in two days of normal use. I have not been able to identify a single deterministic repro step; it appears tied to MCP reconnect timing.

Workaround

Use the standalone CLI in a terminal alongside VS Code. Same auth, same MCP servers, no stalls.

Fixes attempted (none fully resolved the underlying defect)

1. Developer: Reload Window — sometimes provides temporary relief; failure recurs after later MCP reconnects
2. Developer: Restart Extension Host — same as above
3. Disabling hardware acceleration — not yet tested fully

What would help diagnose

Happy to run any extension-side diagnostic command, increase log verbosity, or capture the full output channel including the Unhandled case trace. Please advise.

Screenshots

1. Output panel during a stalled request — the Fast mode unavailable, Stream started - received first chunk, stream_idle_partial, sdk_stream_ended_no_result, and Streaming stall detected lines appear in sequence within ~30 seconds of submitting a prompt:

2. UI banner shown to the user when the stream-event reducer hits the unhandled branch — the red Unhandled case: [object Object] notification with "View output logs · Troubleshooting resources" link appears in the chat panel: