VSCode extension: "Unhandled case: [object Object]" banner orphans response, leaves chat stuck at "Thinking…"

Summary

Intermittent red error banner reading Unhandled case: [object Object] appears at the top of the chat panel inside the Claude Code VSCode extension. While the banner is up, the in-progress assistant turn never produces output — the message bubble just shows the "Thinking…" spinner indefinitely. Dismissing the banner with the ✕ and sending any follow-up prompt (e.g. "hello?", "continue") resumes normally, and the assistant picks up where it left off — so the conversation state is intact on the agent side; the failure is purely in the client's response delivery / render path.

The [object Object] payload is the classic JS bug where an error object is interpolated into a template literal (or String()-coerced) without .message / .toString() first, so Object.prototype.toString() returns the literal string "[object Object]". Whatever code renders the banner is receiving an Error-shaped object and stringifying it incorrectly — the underlying real error is being swallowed.

Repro (observed, not deterministic)

Trigger has been hard to pin down — appears most often during long-running sessions with frequent MCP server reconnects, also when context grows large. Roughly every 30-60 min in active use.

Impact

• Lost responses. Any tool-rich or long assistant turn in progress when the banner fires is unrecoverable from the UI — the work is done agent-side but not surfaced to the user.
• Confusion about state. Users sometimes think the agent is hung and start asking "hello?" / "continue", which re-triggers the agent and produces duplicate / overlapping work.
• Silent data loss for the bug itself. Because the actual error is stringified to [object Object], neither the user nor (presumably) telemetry knows what actually went wrong.

Workarounds we use now

1. Dismiss the banner with ✕.
2. Send a short re-prompt like continue or hello? — the agent picks up cleanly.

Both are user-side band-aids; the underlying response is still lost.

Suggested fix direction

• Wherever the banner copy is built, replace ${err} / String(err) with err?.message ?? err?.toString?.() ?? JSON.stringify(err) — at minimum the user sees what went wrong.
• Separately, the response-delivery path should probably still flush the assistant's pending output even when a non-fatal client error fires — orphaning a "Thinking…" bubble is a worse UX than showing both the error and the partial response.

Environment

• Claude Code VSCode extension (native panel, not the web client)
• Windows 11
• VS Code (recent stable)
• Heavy MCP usage (chrome-devtools, github, sentry, playwright, context7, gmail, calendar, drive, canva, notion) — several of these intermittently disconnect/reconnect during the session, which may or may not be related
• Conversation is long-running and tool-rich

Filing this on the user's behalf

Filed by the Claude assistant from inside an active session at the user's explicit request after hitting this banner several times in the same chat. "View output logs" link wasn't captured this time — adding a "click this once you see it" instruction in the banner copy would also help close that loop.

Reported via Claude Code session (Opus 4.7, 1M context) on behalf of the user.