VSCode extension: "Unhandled case: [object Object]" when stream stalls >15s during extended thinking (Opus 4.7)

Summary

When using the Claude Code VSCode extension with Opus 4.7 (1M context), responses that include long extended-thinking pauses between content blocks trigger a fatal error in the webview — even though the underlying SDK stream is still alive and ultimately completes successfully. The error displayed to the user is the unhelpful Unhandled case: [object Object], indicating that the webview's error handler is also missing a case for this state and falling through to a default that prints the raw error object without serialization.

Environment

• Extension: cc_version=2.1.141.672, cc_entrypoint=claude-vscode
• VSCode (latest as of report date)
• OS: Windows 11
• Model: Opus 4.7 (1M-context variant); effectiveWindow=980000
• Fast mode: not enabled (extra-usage billing not active)

Observed sequence (from extension log)

1. User prompt sent. API stream starts ~3s later — normal.
2. Mid-stream, content emission pauses (consistent with extended-thinking reasoning between content blocks). Log shows:

``
[WARN] [Stall] stream_idle_partial lastChunkAgeMs=15002 bytesTotal=663 idleDeadlineMs=300000
``
The SDK's own idle deadline is 300s. Only ~15s have elapsed.

1. ~15s after that warning, the webview gives up:

``
sdk_stream_ended_no_result {"had_error":true,"subagent_count":0,"message_count":21}
``

1. User sees Unhandled case: [object Object] in the UI.
2. The response is generated in full server-side, but the webview discards it when it declares failure. From the user's perspective the conversation dies — no assistant reply ever appears in the UI, and the prompt must be re-sent. Meanwhile the underlying stream is still alive — additional stall warnings continue, and the stream completes successfully ~50s later:

``
[WARN] Streaming stall detected: 72.4s gap between events (stall #1)
[WARN] Streaming completed with 1 stall(s), total stall time: 72.4s
``

Two bugs in one

1. The premature failure. The webview treats a ~15s mid-stream silence as a fatal error, but the SDK's own idleDeadlineMs=300000 indicates 5 minutes is the actual timeout. With extended-thinking models, sub-minute pauses between content blocks are routine. The webview should align with the SDK's tolerance, or the SDK should emit keepalive chunks during thinking.
2. The error display itself. When this state is hit, the webview's error handler doesn't have a case for it and falls through to something like throw new Error(\Unhandled case: \${someObject}\) without serializing the object — yielding the literal string [object Object]. The user sees no useful diagnostic.

Impact

This is not just a confusing error message — it kills the response. The full reply is generated and the SDK log confirms Streaming completed, but the webview never renders it because it already gave up. From the user's point of view:

• They send a prompt.
• They wait.
• They get Unhandled case: [object Object] instead of a reply.
• The reply never appears, even after the stream actually finishes.
• Their only recourse is to re-send the prompt (which often hits the same stall again) or fall back to the CLI.

This is reproducible on every Opus 4.7 response that includes a non-trivial thinking gap, which is most non-trivial responses. Wasted tokens on every occurrence, since the generated reply is discarded.

Suggested fixes

• Short-term: at minimum, fix the error display so it serializes the underlying object and gives the user something actionable.
• Medium-term: relax the webview's idle deadline to match the SDK's (or have the SDK emit periodic keepalive markers during thinking pauses, which would also help any other client).