[BUG] v2.1.141: "Unhandled case: [object Object]" banner + permanent "Thinking…" stall in VS Code webview on image-bearing follow-up (Opus 4.7 1M)

Summary

After updating to v2.1.141, the Claude Code VS Code extension webview surfaces an Unhandled case: [object Object] red banner mid-conversation and the chat panel stops rendering responses. The "Thinking…" indicator stays forever for the in-flight turn, while the extension host backend continues to operate normally (further API requests still flow out and complete).

This likely overlaps with #58897, #58984, #58994, #58989, #52151 — opening a separate report so the maintainers have an additional data point with reproduction and version specifics, especially the mid-stream / image-bearing follow-up trigger pattern.

Environment

| | |
|---|---|
| OS | Windows 11 Pro, build 26200 |
| VS Code | 1.120.0 (commit 0958016b2af9f09bb4257e0df4a95e2f90590f9f, x64) |
| Extension | anthropic.claude-code 2.1.141 (also have 2.1.140 installed) |
| Model | claude-opus-4-7[1m] (Opus 4.7, 1M context window) |
| Entrypoint | cc_entrypoint=claude-vscode |
| Auth | Claude.ai OAuth (not Bedrock / not Vertex) |
| Working dir | UNC path \wsl.localhost\Ubuntu\… (Windows-side workspace pointing at WSL2) |

Reproduction

1. Long-running chat in the VS Code webview panel (Opus 4.7 1M).
2. Many successful turns including image attachments.
3. Sent another follow-up that included a pasted PNG (1901×867) plus a one-line text message.
4. The webview renders a red banner above the conversation:

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

1. The newly-sent user message is visible in the transcript but the assistant reply shows "Thinking…" indefinitely.
2. Developer: Reload Window restores the panel and the chat can be resumed.

The failure was not on the first message of the chat — many image-bearing turns went through normally before this one failed. Reload Window is the only recovery.

What the logs show

Anthropic.claude-code/Claude VSCode.log for the broken session (sessionId = f0bfd2e3-…) shows ~20 healthy running → idle transitions across the day, including the failing turn (which still flipped back to idle after a few tens of seconds). No [ERROR] entry in the extension-host log correlates with the moment the banner appeared.

This is consistent with the theory in #58897 that the error originates in the webview renderer (an assertNever / unhandled discriminated-union case on a stream-event variant it doesn't recognize), not in the host process — the host happily keeps processing.

Session state transitions for the broken chat:

2026-05-14 11:01:07  running
2026-05-14 11:09:30  idle      ✓ normal
2026-05-14 15:19:17  running
2026-05-14 15:22:19  idle      ✓ normal
…  (~15 more normal running/idle cycles)  …
2026-05-14 15:48:44  running   ← turn that stalled; banner appears around here
2026-05-14 15:49:32  idle      ← host marks idle, but UI stays "Thinking…"

Host-side activity in the window the banner appears (request IDs / tool-use IDs anonymized):

[DEBUG] [API REQUEST] /v1/messages x-client-request-id=<req-id> source=sdk
[DEBUG] Stream started - received first chunk
[INFO]  [Stall] tool_dispatch_end tool=Bash toolUseId=toolu_<id> outcome=ok ...
[DEBUG] [API REQUEST] /v1/messages x-client-request-id=<req-id> source=sdk
[DEBUG] Stream started - received first chunk

i.e. streams are opening and producing chunks while the webview is frozen.

Why this might add signal on top of the existing reports

• Trigger is mid-conversation on Opus 4.7 1M, not on session open or the very first turn — many image-bearing turns succeeded in the same chat first.
• The failure correlates with sending an image-bearing follow-up specifically. Pure-text turns in earlier portions of the chat were fine.
• The host log shows the API streams arriving normally (Stream started - received first chunk) — confirming the error is downstream of the host, almost certainly in the webview stream-event parser.

Workaround

Developer: Reload Window. No persistent data loss, but the in-flight assistant turn is dropped.

Cross-references

• #58897 — assertNever from unknown streaming-event types (closest theoretical match)
• #58984 — webview stops rendering, CLI keeps running (matches my host-log behaviour exactly)
• #58994 — webview stream parser not forward-compatible on content_block_delta types
• #58989 — sdk_stream_ended_no_result after 2.1.141
• #52151 — same banner on Opus 4.7 1M via Bedrock (April)