VS Code webview shows `Unhandled case: [object Object]` and stops rendering while CLI backend keeps running

Summary

In the VS Code extension, a red banner reading Unhandled case: [object Object] appears mid-response and the conversation panel stops updating. Critically, the CLI/SDK backend continues processing the stream normally — tools are still invoked, files are still edited, external processes (e.g. Chromium spawned by @browser) still launch. Reloading the VS Code window re-renders the full conversation from the persisted session jsonl, confirming the data was correctly received and saved. Only the live webview rendering path is broken.

Environment

• Extension: anthropic.claude-code v2.1.141 (darwin-arm64)
• IDE: VS Code (latest), macOS Tahoe (Darwin 25.3.0)
• Model: claude-opus-4-7
• Extended thinking: default_on
• Permission mode: acceptEdits
• Plugins enabled (skills only, no hooks): cs-study-assistant, thesis-writing-assistant
• MCP servers configured: claude.ai Gmail, claude.ai Google Drive (claude.ai connectors). Local claude-vscode MCP server is hosted by the extension itself.

Symptoms

1. Red banner Unhandled case: [object Object] appears in the chat panel above the latest user message
2. UI shows Thinking... indefinitely or freezes mid-reply
3. The user sees no further response content, even though the model is still producing
4. Reloading the VS Code window (Developer: Reload Window) re-renders the full conversation from disk, including the response that was "missing"
5. Repeats on the next user turn in the same conversation

Evidence the backend continues working despite the banner

• After the banner appeared, I observed tools actually being invoked: Edit modified the project files, and @browser successfully launched Chromium and navigated
• Session jsonl on disk (~/.claude/projects/<project>/<sessionId>.jsonl) contains the full assistant turn that the UI failed to render
• After a reload, the previously "missing" response is fully visible in the chat panel

This strongly suggests the bug is in the webview's event handler — likely a switch statement that hits its default branch on an unrecognized event payload, throws, and halts subsequent UI updates while the underlying SDK process is unaffected.

Reproduction

Non-deterministic. Higher probability when:

• The session history contains a PDF uploaded via the UI attachment button (base64 document block persisted in the user message, replayed on every subsequent turn — request bodies grow to 2.5MB+)
• The current turn requires complex output: extended thinking + multiple tool_use blocks + tool results

But also occurs in:

• Fresh sessions with no PDF attachment
• Plain text-only conversations

The banner can appear repeatedly within the same conversation. "Simple" follow-up prompts (e.g. 请继续) sometimes succeed in rendering, but the same kind of complex request that just failed may succeed on retry — fully non-deterministic.

Additional logs

• The Output panel shows no Unhandled string — the banner originates in the webview, not the CLI stdout. The CLI logs only show normal stream events (Stream started - received first chunk, occasional [Stall] stream_idle_partial, etc.).
• DevTools Console (Help → Toggle Developer Tools) presumably contains the real object that hit the unhandled switch. (I haven't captured this yet but will attach if requested.)
• Network on my end goes through a proxy (Clash Verge, TUN mode). This contributes to occasional genuine stream stalls ([WARN] Slow first byte, Connection error, had_error: true), but those are a separate failure mode — when the proxy actually drops the stream, the jsonl shows the assistant turn ending with the synthetic "No response requested." placeholder. The Unhandled case banner described here is distinct: backend completes successfully, jsonl has the full response, only the webview is broken.

Suggested investigation

1. Catch the unhandled object in the webview's event-router switch and log it with the full object (instead of stringifying to [object Object]). Likely candidates: a new content-block type, signature/citation/thinking-variant block, or a stream-meta event the renderer doesn't handle.
2. Make the default branch non-fatal: keep dispatching subsequent events even if one event type is unrecognized, so the UI can degrade gracefully instead of freezing.
3. Surface the actual object type in the banner (e.g. Unhandled event: thinking.signature_v2) to make user reports actionable.

Workaround

For affected users:

• Treat the banner as cosmetic. Watch the file system / external processes to confirm the agent is still working.
• After the task completes, run Developer: Reload Window to re-render the conversation from the persisted jsonl.
• For critical work, run claude in the VS Code integrated terminal — the CLI's TUI renderer is unaffected by this bug.
• Avoid using the UI attachment button for PDFs in long conversations. Use @filename.pdf instead (e.g. @spec.pdf pages 1-10), which routes through the Read tool and keeps PDF data out of the user message history.