VS Code toast "Unhandled case: [object Object]" trashes streaming response — webview switch-default throws on unknown stream-event/delta type

🐞 Symptom

Recurring VS Code error toast: "Unhandled case: [object Object]" with View output logs · Troubleshooting resources buttons. Appears unpredictably while Claude is generating a response.

❗ Severity — response loss, not just an annoying popup

The toast doesn't just interrupt visually — it destroys the in-progress assistant reply. Because the throw happens inside the stream-event/delta handler, the stream aborts mid-flight. The user is left with:

• A truncated or completely empty response in the conversation panel
• No way to resume — the partial response can't be salvaged
• Often the next user message reaches an assistant that has lost context for what it was doing

In multi-step work this is genuinely disruptive: the user has to re-prompt and Claude has to re-derive what it was doing. Across one work session yesterday it trashed three substantive responses and ate ~20 minutes of conversation context, including a complete recap message that had to be recovered from memory files in a follow-up session.

🖥️ Environment

• Claude Code VS Code extension: v2.1.141 (Windows x64) — confirmed up-to-date via Extensions panel
• OS: Windows 11 Enterprise 10.0.26200
• Active model: Claude Opus 4.7 (1M context)

🔎 Root cause (located in the installed bundle)

The string Unhandled case appears exactly once in the extension's webview bundle: webview/index.js line 1439:

function QB1($, Z) {
  throw Error(Z ?? `Unhandled case: ${$}`)
}

QB1 is the default: branch of two switch statements in the streaming pipeline:

• b20(...) — content_block_delta.delta.type handler (text_delta, citations_delta, input_json_delta, thinking_delta, signature_delta, compaction_delta, ...).
• XB1.processStreamEvent(...) — top-level stream-event .type handler (message_start, message_delta, content_block_start, content_block_delta, content_block_stop, message_stop).

When the API streams a type the switch has no case: for, QB1 throws. The $ parameter (the unknown event/delta object) is interpolated directly into a template string, producing [object Object]. The throw is caught upstream and surfaced as a vscode.window.showErrorMessage(...) toast — Dev Tools Console shows no stack trace.

💡 Most likely scenario

Client-vs-server version skew: the API is emitting newer event or delta types than the installed client was coded to handle. Candidates: new thinking-related deltas, citation/cache variants, tool-use partial-input shapes, or new top-level stream events shipped with recent model releases.

🛠️ Suggested fix

1. Soft-fail instead of throw. The streaming pipeline shouldn't fault on an unknown event/delta type — unknown types should be safely ignored (or rendered as fallback text) so the rest of the response still arrives intact. Forward-compatibility matters here because clients lag server feature rollouts.
2. If a hard-fail is necessary, at minimum JSON.stringify($) so the toast reads Unhandled case: {"type":"new_delta_type",...} instead of [object Object]. The current message is undiagnosable for users.
3. Add an output-channel entry alongside the toast with full context (stream offset, prior events, unknown type), so users and support have something to act on.

🚧 Diagnostic impact

The wording suggests an unrecoverable client error and led to two sessions misdiagnosing it as MCP server churn before grepping the installed bundle for the literal string located the actual call site. The error surface needs to point at the real cause.