Skip to content

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

New issue
New issue
Closed as duplicate
Closed as duplicate
Unhandled case: [object Object] on stream end with had_error: true after long sessions#59013
Labels
bugSomething isn't workingduplicateThis issue or pull request already existsplatform:vscodeIssue specifically occurs in VS Codeplatform:windowsIssue specifically occurs on Windows

Description

@Maseschine
Maseschine
opened on May 14, 2026

What happened

Mid-response in a long-running VS Code conversation, the UI shows
"Unhandled case: [object Object]" in a red error bar. The session
becomes unresponsive (Thinking... never resolves). Sometimes typing
"continue" recovers, sometimes not — it's a gamble.

Reproduction (consistent pattern in logs)

  1. Long-running conversation (40+ messages, multiple large MCP
    tool results — 90KB+ persisted read-results in my case)
  2. Tool call completes successfully
  3. Follow-up API request sent
  4. Stream starts, delivers a few hundred bytes
  5. Stream stalls for 15s with no further chunks
  6. sdk_stream_ended_no_result fires with had_error: true
  7. UI surfaces "Unhandled case: [object Object]"

Log excerpt

[Stall] tool_dispatch_end tool=mcp__JARVISVault__list_directory outcome=ok durationMs=4
[API REQUEST] /v1/messages source=sdk
Stream started - received first chunk
[WARN] [Stall] stream_idle_partial lastChunkAgeMs=15010 bytesTotal=669
log_event sdk_stream_ended_no_result {"had_error":true,"message_count":41}

Expected

Either:

  • Automatic retry of the failed stream, OR
  • A user-facing error with a "Retry" / "Resume" button, OR
  • At minimum, a meaningful error message instead of [object Object]

Environment

  • Extension version: 2.1.141.672 (also reproduced on 2.1.141.752)
  • VS Code on Windows 11
  • Model: Opus 4.7 (1M context)
  • MCP servers active: ~20 (heavy MCP usage)

Impact

In long content-heavy sessions (vault analysis, document audits, etc.)
this fires multiple times per hour. The workflow becomes a gamble of
"does retry work this time".

Activity

  1. github-actions
    added
    bugSomething isn't working
    duplicateThis issue or pull request already exists
    platform:windowsIssue specifically occurs on Windows
    platform:vscodeIssue specifically occurs in VS Code
    on May 14, 2026

  2. github-actions commented on May 14, 2026

    @github-actions
    github-actionsBot
    on May 14, 2026 – with GitHub Actions

    Found 3 possible duplicate issues:

    1. [BUG] Stream stall + sdk_stream_ended_no_result after update to 2.1.141 #58989
    2. VSCode extension v2.1.141: "Unhandled case: [object Object]" banner from assertNever on unknown streaming-event types #58897
    3. Opus 4.7 1M via Bedrock: VSCode extension stream ends with 0 events; fallback renders as "Unhandled case: [object Object]" #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

  3. arielmoatti commented on May 14, 2026

    @arielmoatti
    arielmoatti
    on May 14, 2026

    [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.

  4. captain-cognt commented on May 14, 2026

    @captain-cognt
    captain-cognt
    on May 14, 2026

    same issue here

  5. arielmoatti commented on May 14, 2026

    @arielmoatti
    arielmoatti
    on May 14, 2026

    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.

  6. dcloutier2025 commented on May 14, 2026

    @dcloutier2025
    dcloutier2025
    on May 14, 2026

    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.

  7. alec-harden commented on May 14, 2026

    @alec-harden
    alec-harden
    on May 14, 2026

    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.

  8. dcloutier2025 commented on May 14, 2026

    @dcloutier2025
    dcloutier2025
    on May 14, 2026

    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.

  9. Abdallah01 commented on May 14, 2026

    @Abdallah01
    Abdallah01
    on May 14, 2026

    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.

  10. Shargil commented on May 14, 2026

    @Shargil
    Shargil
    on May 14, 2026

    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.

  11. jrlomas commented on May 14, 2026

    @jrlomas
    jrlomas
    on May 14, 2026

    +1 seeing this repeatedly. Using Ubuntu 24.04.4 LTS

  12. arielmoatti commented on May 14, 2026

    @arielmoatti
    arielmoatti
    on May 14, 2026

    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.

  13. claude commented on May 15, 2026

    @claude
    claudeBot
    on May 15, 2026 – with Claude
    Contributor

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

  14. claude
    closed this as a duplicateof VSCode extension v2.1.141: "Unhandled case: [object Object]" banner from assertNever on unknown streaming-event types #58897 on May 15, 2026

  15. github-actions commented on Jul 4, 2026

    @github-actions
    github-actionsBot
    on Jul 4, 2026 – with GitHub Actions

    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.

  16. github-actions
    locked as resolved and limited conversation to collaborators on Jul 4, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingduplicateThis issue or pull request already existsplatform:vscodeIssue specifically occurs in VS Codeplatform:windowsIssue specifically occurs on Windows

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions