claude-code - 💡(How to fix) Fix [BUG] VSCode Webview emits `sdk_stream_ended_no_result` while extension-host SDK still receives stream chunks; UI shows "Unhandled case: [object Object]"

Preflight Checklist

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

What's Wrong?

Summary

In the Claude Code VS Code extension, long/slow-streaming assistant responses are killed by the webview before the SDK is actually done. The user-visible symptom is an "Unhandled case: [object Object]" error and the in-progress response disappearing from the chat. Tool calls already dispatched do complete, but the response text never renders.

The extension-host log shows the API stream is still active — bytes keep arriving after the webview has emitted sdk_stream_ended_no_result.

Environment

• Extension: Anthropic.claude-code v2.1.141.672
• VS Code: 1.120.0
• OS: macOS Darwin 25.2.0
• Account: Claude Enterprise (correlation noted — issue did not appear on personal Pro account on the same machine and extension version)
• Repro stable: yes, multiple times within a single session

What Should Happen?

Expected

The response renders to completion using the SDK's own idleDeadlineMs (300000ms / 5 minutes), not the webview's tighter threshold.

Actual

The webview gives up after roughly 30–40 seconds of low chunk throughput post-first-chunk, even while:

• The SDK is still receiving stream chunks (bytesTotal continues to grow for minutes after the "ended" event).
• The SDK's own idleDeadlineMs=300000 has not expired.
• [Stall] stream_idle_partial warnings continue firing on the extension-host side.

The webview then displays "Unhandled case: [object Object]" — the catch-all formatter for the resulting failure envelope.

Error Messages/Logs

## Log fingerprint

From `~/Library/Application Support/Code/logs/<session>/window<n>/exthost/Anthropic.claude-code/Claude VSCode.log`:

    [DEBUG] [API REQUEST] /v1/messages source=sdk
    [DEBUG] Stream started - received first chunk          # T+0
    [WARN] [Stall] stream_idle_partial lastChunkAgeMs=15000 bytesTotal=648
    log_event: sdk_stream_ended_no_result had_error:true   # T+30-40s, from webview
    [WARN] [Stall] stream_idle_partial bytesTotal=684      # T+45s — bytes still growing!
    [WARN] [Stall] stream_idle_partial bytesTotal=716      # T+60s — SDK still active
    ... continues for several minutes

Confirmed across three separate errors in the same session at message_count
93, 99, and 103 — identical pattern each time.

Steps to Reproduce

Steps to reproduce

1. Start a chat in the Claude Code VS Code extension.
2. Ask Opus 4.7 for a moderately involved response that triggers thinking or produces several tool calls and a longer text response (e.g. "write me an implementation plan for X with code samples").
3. Wait for the response to begin streaming.
4. Once chunk throughput drops (long thinking pause, or model producing slowly), the webview emits sdk_stream_ended_no_result and the in-progress response vanishes.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

v2.1.141.672

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Diagnostic notes

• Tool calls already dispatched complete successfully (memory files were written on disk by Edit/Write calls that occurred earlier in the same response that then disappeared from the UI).
• Earlier hypothesis that MCP server churn caused the error is wrong — MCP reconnects observed in the log are a consequence (next-message session restart), not a cause.
• Editor's renderer DevTools Console shows no Unhandled case entry — error is in the chat webview's renderer context.

Workaround

Using the claude CLI in a terminal sidesteps the issue entirely (no webview = no 30–40s threshold).

Suggested fix direction

Either remove the webview-side stream-progress timeout and trust the SDK's idleDeadlineMs, or align the webview's threshold with the SDK's. Whichever case produces "Unhandled case: [object Object]" should also format the actual underlying error.