VS Code extension: "Unhandled case: [object Object]" when the API stream stalls (CLI/TUI mode unaffected) #59067

Summary

In the VS Code extension, conversations intermittently crash with this UI error:

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

On the same machine, the CLI (interactive TUI mode) — same version, same network, same proxy — never hits this. It happens across multiple projects, on both brand-new conversations and long ones.

Environment

• Claude Code VS Code extension: anthropic.claude-code-2.1.141-darwin-arm64
• Claude Code CLI: 2.1.141
• VS Code: 1.120.0
• OS: macOS (Darwin 25.4.0), Apple Silicon (arm64)
• Network: API accessed through a local HTTP/SOCKS proxy (http(s)_proxy / all_proxy → 127.0.0.1)

What the logs show

The extension's claude backend logs the API stream stalling, then ending with no result. Two separate occurrences:

Occurrence 1 — brand-new conversation (message_count: 2):

[WARN] [Stall] stream_idle_partial lastChunkAgeMs=15001 bytesTotal=673 idleDeadlineMs=300000
[WARN] Streaming stall detected: 43.0s gap between events (stall #1)
[WARN] Streaming completed with 1 stall(s), total stall time: 43.0s
log_event "sdk_stream_ended_no_result" {"had_error":true,"subagent_count":0,"message_count":2}

Occurrence 2 — long conversation (message_count: 47), right after a built-in sub-agent finished:

[WARN] [Stall] stream_idle_partial lastChunkAgeMs=15000 bytesTotal=654 idleDeadlineMs=300000
log_event "sdk_stream_ended_no_result" {"had_error":true,"subagent_count":0,"message_count":47}
[WARN] Streaming stall detected: 40.2s gap between events (stall #1)
[WARN] Streaming completed with 1 stall(s), total stall time: 40.2s

Notable: on every stall, bytesTotal is tiny and remarkably consistent (654 / 673 / 675 / 705 bytes) — the stream seems to freeze right after headers / the first SSE chunk, with 30–43s gaps between events.

Why the CLI is unaffected (process comparison)

The extension drives the backend in headless stream-json mode; the CLI runs interactive TUI mode:

Both processes have identical proxy environment variables. The difference is the run mode — and sdk_stream_ended_no_result is specific to the headless/SDK path; the TUI mode has no such concept.

Likely root cause

1. Unhandled case: [object Object] — the webview UI receives an error-state object it has no switch/case branch for, and stringifies it.
2. Upstream: the API stream stalls → the headless stream-json path produces sdk_stream_ended_no_result + had_error: true → that error state reaches the webview UI unhandled.

Network instability (proxy) is a plausible trigger, but the CLI tolerates the exact same network and proxy without crashing, so the gap is in how the extension's headless mode + webview UI handle a stalled / incomplete stream.

Suggested fixes

• The webview UI should render stream-interruption errors gracefully (e.g. "stream interrupted — retrying / please retry") instead of Unhandled case: [object Object].
• The headless stream-json path should retry or recover gracefully on stream stall / sdk_stream_ended_no_result, rather than surfacing an unhandled error object to the UI.

Minor, possibly related

On every session start the backend logs, at ERROR level:

[ERROR] MCP server "claude-vscode" Failed to fetch tools: MCP error -32601: Method not found

(tools/list on the built-in claude-vscode MCP server.) It retries once and the session continues, so it appears benign — but it's logged as ERROR on a version-matched extension/CLI pair (2.1.141).