[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

• [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?

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").

1. Wait for the response to begin streaming.
2. 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.