Unhandled case: [object Object] on stream end with had_error: true after long sessions

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/58989
2. https://github.com/anthropics/claude-code/issues/58897
3. https://github.com/anthropics/claude-code/issues/52151

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

[Edited 2026-05-14] Correction: the Bash-latency attribution below turned out to be at most a secondary cause — see my follow-up comment with the actual log data (13 of 23 stalls were bytesTotal=0 first-byte stalls, not Bash). Leaving the original text below for thread continuity.

---

Same signature on Windows 11 + Git Bash — and I think I can name the stall trigger.

Reproduced this with a near-identical log signature (stream_idle_partial lastChunkAgeMs=15011 bytesTotal=654), v2.1.141, Opus 4.7 1M, VS Code on Windows 11.

What I can add: in my case the 15s stall is not driven by long sessions or large MCP results — it's driven by Bash tool latency, and that latency traces directly to the Git Bash shell snapshot. This connects this issue to #46015.

The chain:

1. On Windows, /etc/profile.d/git-prompt.sh sources git-completion.bash — 142 functions, ~92KB — into every shell.
2. Claude Code snapshots that whole interactive environment → an 87KB snapshot file that every Bash tool call has to spawn + eval. A Unicode-character cwd path adds more spawn friction.
3. Result: individual Bash calls take ~15–20s (tool_dispatch_end tool=Bash durationMs=19630). During that window no stream chunks flow → the 15s stream_idle_partial watchdog fires → had_error: true → the webview parser hits QB1 → Unhandled case: [object Object].

So #46015 (snapshot bloat) and this issue aren't separate — the snapshot bloat is a trigger for the stall described here.

Local workaround that removes the trigger — strip git-completion only when running under Claude Code (CLAUDECODE=1 is set in CC shells), so normal terminals keep completion. In ~/.bashrc:

if [ -n "$CLAUDECODE" ]; then
    for _fn in $(declare -F | awk '{print $3}' | grep -E '^_.*git'); do
        unset -f "$_fn" 2>/dev/null
    done
    unset _fn
    complete -r 2>/dev/null || true
fi

This drops the snapshot from ~87KB to ~580 bytes (144 functions → 1) and Bash calls back under a second — no more stalls. Normal terminals are untouched.

Proper fix is server/extension-side (others have noted this): the webview parser shouldn't throw on a stalled/truncated stream — it should degrade or offer Retry. But independently, Claude Code building its shell snapshot from a non-interactive shell (or skipping completion functions) would eliminate this whole trigger class on Windows.

same issue here

Correction to my comment above — the Bash-latency attribution was wrong (or at most secondary).

After pulling my own VS Code extension logs, the data contradicts what I claimed. Being transparent since this thread is getting traction:

What the logs actually show — of 23 stalls in one session, 13 were stream_idle_partial ... bytesTotal=0 — the stream opens and receives zero bytes for 15s+. One line reads [WARN] Slow first byte: no stream chunk 30.0s after request sent. That's not Bash blocking event flow — it's the API stream itself hanging before any data arrives.

These bytesTotal=0 stalls correlate with large context (my message_count climbed 160 → 218 in the session) on Opus 4.7 1M — slow time-to-first-token exceeding the 15s watchdog. So the OP's original framing ("after long sessions / large results") was right; my "it's Bash, not long sessions" claim was not.

Where Bash latency does fit — as a secondary contributor. Slow Bash calls also create event-flow gaps, and on Windows the Git Bash shell snapshot (~87KB of git-completion functions) made each call ~15-20s. The ~/.bashrc workaround above does fix that — Bash dropped from ~21s to ~1.3s in my logs. But the crashes continued anyway, driven by the bytesTotal=0 first-byte stalls. That's the proof Bash latency wasn't the primary driver.

Net — the stall behind this crash is multi-causal: slow time-to-first-token on large contexts is dominant, slow Bash is minor. Chasing individual triggers won't fully solve it. The only robust fix is the one in #58897/#58994: the webview's QB1 helper must not throw on a stalled/unrecognized stream event — log and continue instead. I'm running a local patch that neutralizes the QB1 throw, and the webview no longer crashes regardless of what causes the stall.

Same issue here on Windows, VS Code extension, May 14 2026.

Logs match the pattern exactly:

[WARN] [Stall] stream_idle_partial lastChunkAgeMs=15002 bytesTotal=660
log_event sdk_stream_ended_no_result {"had_error":true,"subagent_count":0,"message_count":320}
[WARN] [Stall] stream_idle_partial lastChunkAgeMs=15001 bytesTotal=696
[WARN] Streaming stall detected: 68.7s gap between events (stall #1)

UI shows the red "Unhandled case: [object Object]" bar and Thinking... never resolves. Typing continue works maybe half the time; Developer: Reload Window is more reliable but I lose the in-flight turn.

Repros consistently in long review/refactor sessions with multiple Read MCP calls. Happy to share more logs if useful.

Reproducing this on Windows / VS Code extension 2.1.141 with a notably short session — message_count: 22, autocompact level=ok, effectiveWindow=980000. So the trigger isn't strictly long sessions.

Environment

• Claude Code VS Code extension: 2.1.141
• Model: claude-opus-4-7 (1M context profile)
• thinkingLevel: default_on
• Platform: Windows
• Permission mode: auto

Trigger
Invoked the Impeccable /critique skill on a specific page in my project. Several Read tool calls succeeded, then the next streaming request stalled and died.

Log excerpt
12:09:23.003 [DEBUG] Stream started - received first chunk
12:09:38.006 [WARN] [Stall] stream_idle_partial lastChunkAgeMs=15004 bytesTotal=671 idleDeadlineMs=300000
12:09:53.043 [event] sdk_stream_ended_no_result {"had_error":true,"subagent_count":0,"message_count":22}
12:10:05.534 [WARN] [Stall] stream_idle_partial lastChunkAgeMs=15002 bytesTotal=707
12:10:20.533 [WARN] [Stall] stream_idle_partial lastChunkAgeMs=30000 bytesTotal=707
12:10:30.714 [WARN] Streaming stall detected: 67.7s gap between events (stall #1)
UI rendered "Unhandled case: [object Object]". Session became unresponsive; typing "continue" did not recover.

Notes that may help narrow it down

• subagent_count: 0 — no Task/subagent involvement.
• The stall begins on the request after a sequence of Read tool calls — the request that would emit the skill's main output.
• Extended thinking is on. Haven't yet tested with thinking off as a control.

Update: Rolled back the VS Code extension to 2.1.140 bug completely gone. Same project (Next.js + Supabase + ~20 MCP servers), same long-session workflow (review/refactor across multiple files), no more Unhandled case: [object Object], no stream_idle_partial warnings, no stalled Thinking....

Nothing else changed in my environment between the broken state and the fix — just the extension version.

Something shipped between 2.1.140 and 2.1.141 broke long-session stream handling. Hope this helps narrow it down.

Reproducing on VS Code extension 2.1.141 + Opus 4.7 (1M context) on Windows 11 today (2026-05-14). Three additive data points beyond what's already in this thread, and one correlated condition that may help narrow the trigger.

Data points

1. Highest message_count seen so far: my session hit it at message_count: 453 (vs the 22 / 41 / 320 already reported). Together with @alec-harden's 22-message repro, this strengthens the "not strictly long-session" framing — the bug just gets more probable on long sessions, not gated by them.
2. Fired 3× in one session, ~10 min apart. Each fire was followed by a clean /resume with no work loss — the underlying agent continued executing tools (commits, file edits, memory writes) to disk while the chat UI was wedged. So it's a renderer-only failure, not an agent-loop failure. Useful for narrowing the responsible code path to the webview-side stream consumer.
3. The smoking gun from Claude VSCode.log matched the pattern exactly:

``
21:45:50 [WARN] [Stall] stream_idle_partial lastChunkAgeMs=15008 bytesTotal=675 idleDeadlineMs=300000
21:46:05 log_event sdk_stream_ended_no_result {"had_error":true,"subagent_count":0,"message_count":453}
21:46:14 [WARN] Streaming stall detected: 39.0s gap between events (stall #1)
`
Notably zero hits for Unhandled case or [object Object] *anywhere* in the extension-host log — the banner is constructed at a UX boundary that swallows the structured payload, so the host log alone never shows you the discriminator that wasn't matched. Anyone debugging this in source: instrument the webview-side stream-event switch's default` arm to dump the unmatched object first.

Correlated condition (worth checking on the maintainer side)

In my session, /remote-control was toggled on 30 minutes before the first crash:

2626:  21:15:50  Received message from webview: {"type":"toggle_remote_control","enable":true}

…and never received a corresponding success/handshake confirmation in the log. No banner appeared above the textbox locally. But the phone app did register a connected session — and showed messages syncing through to the agent-fanout point in the conversation, then stopped. After that point, none of the post-fanout messages reached the phone.

That's a textbook half-state: extension-host thinks the remote bridge isn't fully established (no banner), phone-side thinks it is (sees the session). When the streaming response then has to fan out to both the local UI and the remote bridge, the bridge's discriminated-union dispatcher hits a case it has no arm for → falls into the same default: that produces Unhandled case: [object Object].

The 3 crash timestamps in my session correlate with the 3 highest-volume tool batches (a 5-way agent fanout + two large multi-file Edit batches). Each new batch added more pressure to the bridge fanout. If the maintainer team can repro by enabling remote-control + running a long agent-heavy session, this might be a faster repro path than waiting for natural network stalls. I've filed the half-state separately so this thread stays focused on the unhandled-case symptom.

Workaround confirmation

@dcloutier2025's report that rolling back to 2.1.140 eliminates the issue lines up with my experience too — I had no occurrences of this banner across multiple long sessions on the prior extension version. Strongly looks like a 2.1.141-specific regression in either the webview stream consumer or the remote-bridge serializer.

Adding a macOS data point, every prior report in this thread is Windows 11.

Reproducing on macOS (Darwin 24.6.0) with the Claude Code VS Code extension. Symptom matches exactly: red "Unhandled case: [object Object]" banner, "Thinking…" never resolves, sometimes recoverable by typing continue, more reliably by Developer: Reload Window (losing the in-flight turn). Hitting this multiple times per day in normal coding sessions.

Important: the 2.1.140 rollback does not fix it on macOS. I was on 2.1.141, rolled back to 2.1.140 (which @dcloutier2025 reported as clean on Windows), and the banner still fires with the same signature. So either:

the regression range goes back further than 2.1.140 on macOS, or
there's a macOS-specific stream-consumer path that's broken in both versions, or
@dcloutier2025's Windows fix is coincidental (sessions happened to avoid the trigger after the downgrade).
Either way, this isn't a clean "rollback to N-1" workaround across platforms. Combined with the macOS repro, it also weakens the Windows-specific theories (Git Bash snapshot, etc.) as the primary cause — the underlying QB1/webview throw on unrecognized stream events looks platform-agnostic.

Happy to grab a Claude VSCode.log excerpt next time it fires.

AI USAGE: was written by Claude code and slightly edit by me.

+1 seeing this repeatedly. Using Ubuntu 24.04.4 LTS

Posting a working local fix — feel free to paste this whole comment into Claude Code and have it apply the patch for you.

Following up on my earlier comments: I've been running a local patch for a day now and the webview no longer crashes, regardless of what causes the underlying stall.

The root cause is one helper in the bundled webview parser. In the extension's webview/index.js there's an assert-never helper that throws on any stream event it doesn't recognize — a network stall, a truncated chunk, or a new server event type. That single throw takes down the entire webview render, even though the CLI backend keeps working fine.

The fix is to make it log-and-continue instead of throw. Find this exact string in webview/index.js:

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

Replace it with:

function QB1($,Z){console.warn("skipped unhandled stream case:",Z??$);return}

That's the whole fix. The UI now skips the unknown event instead of dying.

Notes for anyone applying this:

• The file is inside your installed extension: ~/.vscode/extensions/anthropic.claude-code-<version>/webview/index.js.
• The extension bundle resets this on every update, so you'll need to re-apply after upgrades (I run it from a SessionStart hook so it re-applies automatically).
• It's a safe idempotent find/replace — if the throwing version isn't present, nothing happens.
• Reload the VS Code window after applying.

This is symptom-agnostic — it doesn't matter whether your stall comes from slow first-byte on a big context, slow Bash, or anything else. The real bug is the webview throwing instead of degrading, and this fixes that directly. Ideally the maintainers ship the same change server/extension-side so nobody has to patch their install.

This is a duplicate of #58897, which was fixed as of version 2.1.142.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.