claude-code - 💡(How to fix) Fix [BUG] VS Code extension: red banner "Unhandled case: [object Object]" appears frequently in chat panel (claude-vscode 2.1.141.x)

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report (please file separate reports for different bugs)
• I am using the latest version of Claude Code

What's Wrong?

A red error banner reading "Unhandled case: [object Object]" appears at the top of the Claude Code chat panel during normal use. The banner offers "View output logs" and "Troubleshooting resources" links. The underlying conversation state appears intact — only the rendering layer is affected — but the banner is showing up very frequently and disrupts the session.

Surface: Claude Code VS Code extension (cc_entrypoint=claude-vscode), chat panel renderer (iframe-based webview).

Builds observed in a single session: cc_version=2.1.141.17d, cc_version=2.1.141.b00, cc_version=2.1.141.0d9 — three different build hashes appearing concurrently within one session, which is itself worth flagging (hot-update / staged-rollout AB?).

[object Object] in the message strongly suggests an object is being stringified into a template literal in a default/unhandled switch branch in the renderer — i.e., the renderer hit a case it didn't recognize and stringified the discriminator object instead of extracting a meaningful field.

What Should Happen?

The chat panel should render assistant turns — including ones containing AskUserQuestion calls, multi-line preview content, or any normal content variant — without surfacing a renderer-internal "Unhandled case" error to the user. If the renderer encounters an unexpected discriminator, it should at minimum fail soft and log a useful error (not stringify the discriminator into a banner the end user sees).

Error Messages/Logs

**Banner text shown in the chat panel:**

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


**"View output logs" content (SDK / agent-side, from the Claude output channel) — the string `Unhandled case` does NOT appear in this stream.** It contains only routine API request, tool dispatch, and streaming chunk debug lines. Sampling of notable signals (filtered from ~15 min of session output):


[DEBUG] attribution header x-anthropic-billing-header: cc_version=2.1.141.17d; cc_entrypoint=claude-vscode
[DEBUG] attribution header x-anthropic-billing-header: cc_version=2.1.141.b00; cc_entrypoint=claude-vscode
[DEBUG] attribution header x-anthropic-billing-header: cc_version=2.1.141.0d9; cc_entrypoint=claude-vscode
[WARN] Streaming stall detected: 35.1s gap between events (stall #1)
[WARN] [Stall] stream_idle_partial lastChunkAgeMs=15004 bytesTotal=659 idleDeadlineMs=300000
[DEBUG] Edit tool validation error: File has been modified since read, either by the user or by a linter.
[INFO] [Stall] tool_dispatch_end tool=Bash outcome=ok durationMs=300484


Three different `cc_version` build hashes (`.17d`, `.b00`, `.0d9`) appearing within one session is itself worth investigating.

**Webview / renderer-side console (where the actual `Unhandled case` stack should live):** attempted to capture, inaccessible to the user.

- `Developer: Open Webview Developer Tools` opens VS Code's main DevTools with `Using standard dev tools to debug iframe based webview` (from `webviewCommands.ts:33`) — i.e., VS Code falls back to standard DevTools because the Claude Code panel is an iframe-based webview.
- The frame dropdown lists multiple `vscode-webview://...` / `active-frame (index.html)` entries. Switching execution context to them and reproducing the banner did not surface any console message containing `Unhandled case`. Filtering all frames for `Unhandled` also returned no matches even after the banner re-appeared.
- This may itself be a finding: the renderer's error path appears to render the banner without writing the error to `console.error`, leaving users (and bug filers) without a captureable trace.

Steps to Reproduce

Not yet a deterministic repro — the banner appears frequently during ordinary multi-turn sessions, but the exact triggering content has been hard to pin down. What I can report:

1. Open VS Code with the Claude Code extension; chat panel against claude-opus-4-7.
2. Use the chat normally over a multi-turn session involving:
   • Sub-agent dispatch (source=agent:builtin:general-purpose), including long-running general-purpose agents (one agent ran 437s / 49 turns, another ran 1142s / 77 turns in my captured window).
   • Long-running Bash tool calls (durations of 120s and 300s observed, including some that hit the 300s deadline).
   • File Edit / Write tool calls.
3. The red Unhandled case: [object Object] banner appears at the top of the chat panel during this normal flow. Frequency is high — many times per session.

Suspected trigger candidates (none confirmed):

• Assistant turns containing AskUserQuestion tool calls whose option preview fields contain newlines, code blocks, or ASCII layouts. (I observed the banner around such turns, but later also observed it on plain Bash+text turns with no AskUserQuestion at all — so this hypothesis is weakened.)
• The multi-build session (three concurrent cc_version hashes) raising the chance that a content variant emitted by one build is unknown to another build's renderer.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

No response

Claude Code Version

VS Code extension Claude Code: cc_version=2.1.141.17d / 2.1.141.b00 / 2.1.141.0d9 (three concurrent build hashes observed in one session via x-anthropic-billing-header), cc_entrypoint=claude-vscode

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

Template note: the Terminal/Shell field is set to "Other" because this report is about the Claude Code VS Code extension chat panel renderer, not the CLI inside a terminal. The CLI-focused bug template doesn't have a precise category for this. Model "Opus" maps to claude-opus-4-7 in my session.

Hypotheses for maintainers to investigate:

1. Renderer discriminated-union fall-through. The literal [object Object] in the user-facing string strongly suggests a default/unhandled case branch in the renderer that does something like `Unhandled case: ${variant}` where variant is the full content object rather than variant.type (or equivalent discriminator). Likely candidates to audit:

   • The AskUserQuestion option / preview renderer.
   • Any newly-added content block or tool-result variant added between the three observed builds (2.1.141.0d9, 2.1.141.b00, 2.1.141.17d).
   • Any streaming-partial path that emits a placeholder content node while a stream is still in flight (the session had a 35.1s streaming stall and several stream_idle_partial warnings).

2. Concurrent build hashes within one session. Three different cc_version short hashes appearing in x-anthropic-billing-header for a single uninterrupted session suggests either staged rollout, hot-update mid-session, or some build-tagging issue. If a renderer in build A receives content shaped per a model emitted by build B, an "unhandled case" is exactly what you'd expect.

3. "View output logs" link points to the wrong destination. The banner's "View output logs" link opens the VS Code "Claude" output channel (the agent SDK side), which does not contain the Unhandled case string. The actual error is fired in the webview renderer and is not surfaced anywhere the user (or bug reporter) can reach without VS Code-level DevTools. Even with Developer: Open Webview Developer Tools, the webview is iframe-based and falls back to standard DevTools, and console.error filtering for Unhandled returned no matches — suggesting the error path renders the banner without also writing to console.error. Worth fixing both: log to console, and have the link point somewhere actually useful.

Environment specifics: macOS, Claude Code VS Code extension running against claude-opus-4-7 on the Anthropic API, ~980k effective context window. Sessions involved many concurrent general-purpose sub-agents and long-running Bash/Edit/Write tool calls.