VS Code extension: side panel shows `Unhandled case: [object Object]` after task completes

Summary

The VS Code extension's side panel intermittently displays the error message Unhandled case: [object Object] in place of a task result. The underlying task appears to run to completion (logs show normal running → idle transitions with hasUnseenCompletion: true), but the webview UI fails to render the result, throwing this generic error instead.

The user can no longer see the assistant's output for that task even though work was performed. This happens repeatedly across different tasks/sessions, not tied to a specific prompt.

Environment

| | |
|---|---|
| Extension | Anthropic.claude-code 2.1.141 (also reproduces on 2.1.140 — webview/index.js is byte-identical between the two) |
| VS Code | 1.120.0 (commit 0958016b2af9f09bb4257e0df4a95e2f90590f9f, x64) |
| OS | Windows 11 Home, 10.0.26200 |

Steps to reproduce

Not deterministic, but happens regularly during normal use of the side panel. In the latest occurrence:

1. Open the Claude Code side panel in VS Code.
2. Start a task (in this case auto-titled "Develop brand voice content").
3. The task runs through the normal running / idle cycle several times (visible in Claude VSCode.log).
4. After the task transitions to idle with hasUnseenCompletion: true, the result area of the panel shows:

``
Unhandled case: [object Object]
View output logs · Troubleshooting resources
``

The chat input remains usable, but the result of the completed task is no longer visible.

Expected behavior

The webview should render whatever result the task produced, or — if it receives a stream chunk type / state variant it does not recognise — fall back gracefully (e.g. render the chunk as text, log to the output channel, or display a non-fatal warning) instead of throwing.

Actual behavior

A generic Unhandled case: ${$} is thrown from the side panel renderer with the whole object as the discriminant, so it stringifies to [object Object] and the user gets no useful information.

Diagnostic

The error originates from a helper bundled in webview/index.js:

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

It's used as the default: branch in several switch statements over discriminated unions. Two call sites visible in the minified bundle:

// content block type switch
this.contentBlocks = void 0; break; default: QB1($)

// message stream event switch — note `compaction_delta` IS handled,
// so the unhandled cases are adjacent stream-event types
case "compaction_delta": break; default: QB1(J)

Two problems with this pattern:

1. The discriminant passed to QB1 is the whole object, not its .type field. Template-literal interpolation falls back to Object.prototype.toString and renders [object Object], giving the user (and the bug triage) zero information about which case was missed.
2. It throws. A newly-introduced stream chunk type on the SDK side will hard-error the renderer for every user on an older extension build, instead of being safely ignored. This makes the bundle fragile to any additive server-side change (new tool-use sub-variant, new content block kind, new stream event, etc.).

Suggested fix

• In QB1, log JSON.stringify($) or $?.type ?? $ instead of ${$}, so the error message is actionable.
• Make QB1 non-throwing for stream-event / content-block switches in the webview: log + skip the chunk instead of crashing the renderer.

Logs

Claude VSCode.log for the affected window (Windows path):

C:\Users\HP\AppData\Roaming\Code\logs\20260514T094126\window7\exthost\Anthropic.claude-code\Claude VSCode.log

Relevant excerpt — task transitions show it ran and reached completion before the UI failed to render:

2026-05-14 22:54:50.589 [info] ... rename_session ... title:"Develop brand voice content"
2026-05-14 22:54:50.591 [info] ... update_session_state ... state:"running"
...
2026-05-14 23:08:42.209 [info] ... update_session_state ... state:"idle"
2026-05-14 23:08:42.209 [info] ... rename_tab ... hasUnseenCompletion:true

No [ERROR] line correlates with the displayed Unhandled case — confirming the throw happens in the webview/renderer, not in the extension host or the agent process. Happy to share more log context on request.