Opus 4.7 1M via Bedrock: VSCode extension stream ends with 0 events; fallback renders as "Unhandled case: [object Object]"

I am also seeing this issue using Claude Code via Bedrock

I have the same issue:
Claude Code v2.1.117
API provider: Amazon Bedrock
Model: global.anthropic.claude-opus-4-7[1m]

Adding to the frustration of this extremely annoying bug:

When this Unhandled case: [object Object] error occurs, if you close Claude Code and reopen the session, the UI truncates the entire conversation back to the moment the error happened — everything you did after the error simply vanishes from the interface.

The really painful part: the .jsonl session file on disk still contains the full history. All the messages, tool calls, edits, and reads that happened after the error are persisted correctly. But on reload:

• The UI only renders messages up to the error.
• The agent running inside the resumed session also loses all the post-error context.

So if you decided to push through the error and keep working (which is often the only practical choice mid-task), you effectively lose all that progress from the agent's perspective the moment you restart. The data is right there in the JSONL — the UI/agent just refuses to load past the error boundary.

This turns a recoverable hiccup into a hard context wipe, and it makes long planning/implementation sessions (like the one in the screenshots, where significant work was done after the error) extremely risky to resume.

Reproducing on extension 2.1.120 (current latest as of 2026-04-26) on Darwin 25.4.0 with model global.anthropic.claude-opus-4-7[1m]. Happens frequently in long tool-heavy sessions.

Quick diagnosis by grepping the shipped extension:

~/.vscode/extensions/anthropic.claude-code-2.1.120-darwin-arm64/webview/index.js

The message is thrown from function XB1 inside a switch over stream event types:

case "compaction_delta": break;
default: XB1(J)
// ...
function XB1($, Z){ throw Error(Z ?? `Unhandled case: ${$}`) }

Two problems:

1. Non-forward-compatible switch: the default branch throws on any unknown event type instead of no-oping. Any new stream event the server introduces (or any event that survives the sdk_stream_ended_no_result fallback path in a shape the switch doesn't recognise) crashes the webview handler.
2. Error message loses all info: ${$} stringifies the event object as [object Object], so the notification is uninformative. Should be JSON.stringify($) at minimum, ideally with the event type extracted.

Suggested fix: the default branch should log-and-ignore (with the full event JSON) rather than throw. That preserves forward compatibility when new event types land, and when a genuine bug does occur the notification actually tells you what event was unhandled.

Still repros on 2.1.120 — bumping so it's visible against the latest release.

i'm running into the same issue. basically i cannot use opus 4.7 with bedrock at the moment.

This bug is super annoying and i have to type multiple times "please continue" in VS code extension. That's crazy.

Still reproducing on v2.1.131

Same issue persisting with AWS Bedrock Opus 4.7 on Cursor v3.3.12

Reproducing on 2.1.128.b51 (VSCode stable, macOS 15.x arm64, Bedrock us.anthropic.claude-opus-4-7 1M context). Adding one data point for this specific bundle and notes from a local patch test.

Confirmation on 2.1.128

Same symptom and same log trail as the OP. In one day on a normal-sized project I saw 11 sdk_stream_ended_no_result events with had_error: true, each paired with Stream completed without receiving message_start event - triggering non-streaming fallback. Context at failure was not the culprit (~242K tokens, effectiveWindow=980000).

The throw function is still there in 2.1.128 — same shape as @aumanjoa found in 2.1.120, just with a different mangled name (GB1 instead of XB1). Two call sites, both in webview/index.js:

1. QB1.processStreamEvent — default: GB1($) after the six known message_* / content_block_* cases.
2. b20 (content-block-delta dispatcher) — default: GB1(J) after text_delta, citations_delta, input_json_delta, thinking_delta, signature_delta, compaction_delta.

Local patch test (confirms diagnosis)

I replaced the GB1 body from

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

to

function GB1($, Z) {
  try { console.warn("[patched-local] Unhandled case:", $, Z); } catch (e) {}
  return;
}

After reloading the VSCode window:

• Red toast no longer appears.
• Session no longer freezes — the non-streaming fallback produces its result and the UI continues rendering normally.
• Underlying Bedrock stream-drops still happen at the same rate; the patch only masks the UI consequences.
• A warning lands in the webview devtools console when it happens (useful for counting occurrences).

So both behaviors the community has asked for are achievable with a one-function change:

• Forward-compat default branch (log-and-continue instead of throw).
• Preserve the information if it ever does matter — JSON.stringify(value) or value?.type ?? "unknown" in the message, per @aumanjoa's suggestion.

Extra observation

@pllanos-entropy's note about the .jsonl file keeping full history while the UI truncates to the error point is confirmed on my side too. When a session froze mid-tool-dispatch, the disk session had another ~40 messages past the UI boundary on reload — so the lost-context cost is even higher than the toast suggests.

Seeing the same issue since yesterday on the VSCode extension.

Environment:

Claude Code: 2.1.132
VSCode extension: anthropic.claude-code 2.1.132
Model: global.anthropic.claude-opus-4-7[1m]
Provider: AWS Bedrock
OS: Linux 6.8.0-111-generic (Ubuntu)
Crash occurs irregularly and at one time it occurred during the first interaction in a session. Same "Unhandled case: [object Object]" error text.

For anyone wanting to mitigate locally while this is fixed upstream — here's a version-agnostic patch script that works across 2.1.120 / 2.1.128 / 2.1.131 / 2.1.132 and should survive through whatever the next minified function name is. macOS and Linux covered; Cursor users just point EXT_ROOT at their own extensions dir.

Patch (run once, then Reload Window)

#!/usr/bin/env bash
# claude-code-unhandled-case-patch.sh
set -euo pipefail

# Adjust if you use Cursor, VSCode Insiders, etc.
EXT_ROOT="${EXT_ROOT:-$HOME/.vscode/extensions}"

EXT_DIR=$(ls -dt "$EXT_ROOT"/anthropic.claude-code-* 2>/dev/null | head -1 || true)
if [ -z "$EXT_DIR" ]; then
  echo "ERROR: no anthropic.claude-code-* extension found under $EXT_ROOT" >&2
  exit 1
fi
TARGET="$EXT_DIR/webview/index.js"
BACKUP="$TARGET.backup"

[ -f "$TARGET" ] || { echo "ERROR: $TARGET not found"; exit 1; }
[ -f "$BACKUP" ] || cp "$TARGET" "$BACKUP"

python3 - "$TARGET" <<'PY'
import re, sys
path = sys.argv[1]
src = open(path).read()

if "[cc-unhandled-case-patch]" in src:
    print(f"already patched: {path}")
    sys.exit(0)

pattern = r'function (\w+)\(\$,Z\)\{throw Error\(Z\?\?`Unhandled case: \$\{\$\}`\)\}'
def repl(m):
    fn = m.group(1)
    return (f'function {fn}($,Z){{try{{console.warn("[cc-unhandled-case-patch]",'
            f'$?.type??$,$,Z)}}catch(e){{}}return}}')
new, n = re.subn(pattern, repl, src)
if n == 0:
    print("ERROR: throw signature not found — minified names may have changed. "
          "Grep for `Unhandled case` in the bundle and adapt the pattern.",
          file=sys.stderr)
    sys.exit(2)
open(path, "w").write(new)
print(f"patched {n} site(s) in {path}")
PY

echo
echo "Done. Now run '⌘⇧P → Developer: Reload Window' for EACH open VSCode window."
echo "  Extension dir : $EXT_DIR"
echo "  Backup file   : $BACKUP"

Revert

EXT_DIR=$(ls -dt "$HOME/.vscode/extensions"/anthropic.claude-code-* | head -1)
cp "$EXT_DIR/webview/index.js.backup" "$EXT_DIR/webview/index.js"
# Then Reload Window

What it does (and does not) fix

• Fixes: the Unhandled case: [object Object] red toast and the session freeze that comes with it. Tested on 2.1.128; regex is generic to the minified signature so it should match current-gen builds until Anthropic refactors the function.
• Does not fix: the underlying Bedrock stream drops (they still happen; the non-streaming fallback handles them silently after the patch).
• Does not fix: the "UI truncates to error point on reload" data-loss issue @pllanos-entropy flagged — that's a separate bug.

Caveats

• Extension auto-updates will wipe it. The script is idempotent and safe to re-run after each update; if the function signature changes the patch will fail loudly rather than corrupt the bundle.
• Cursor / other VSCode forks: set EXT_ROOT to that editor's extensions directory (e.g. ~/.cursor/extensions).
• Linux: same path assumptions; no platform-specific code.
• This is a workaround for the symptom, not a replacement for Anthropic's fix. Paste it only if you're comfortable modifying a local extension file.

Version 2.1.141 continues to experience persistent issues.

VS Code Extension 2.1.141. Super annoying.

<img width="240" height="199" alt="Image" src="https://github.com/user-attachments/assets/40d737ca-d4ba-48c7-96fb-e1322d6b6208" />

<img width="692" height="170" alt="Image" src="https://github.com/user-attachments/assets/36c63f9f-9a80-440f-83c1-3ce6d04013ab" />

I have the same issue

This issue is occurring using Claude directly without Bedrock too.

Have the same issue.
VSCODE:

Version: 1.120.0 (user setup)
Commit: 0958016b2af9f09bb4257e0df4a95e2f90590f9f
Date: 2026-05-12T20:17:22Z
Electron: 39.8.8
ElectronBuildId: 13870025
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

Claude Code for VS Code:

Identifier: anthropic.claude-code
Version: 2.1.141
Last Updated: 2 hours ago
Size: 226.77MB

This is an issue with VS Code Extension Version: 2.1.141.
I downgraded to VS Code Extension Version: 2.1.140 and restarted VS Code (unchecked auto update in the extension) and it works again for me. Still testing but try downgrading.

The fix is to: go in VSCode Claude Code Extension, Downgrade it to 2.1.140, uncheck auto update the extension and restart VS Code.

Same issue:
Claude Code for VSCODE
Version: 2.1.141

Same issue:
Claude Code for VSCODE
Version: 2.1.141

Come on team we need this fixed. I'm on Claude Code Max and can't have these trivial errors
V2.1.141

<img width="345" height="73" alt="Image" src="https://github.com/user-attachments/assets/90798b3a-358c-44d4-99b6-580a82573777" />

Same issue:
Claude Code for VSCODE
Version: 2.1.141

same. how to fix that?

Experiencing the same error here
claude code 2.1.141

@ziago @yevhenlisovenko @Fl0rencess720 @goneale @Mr-KIDBK @sperokubo check my comment: https://github.com/anthropics/claude-code/issues/52151#issuecomment-4448083216

The fix is to: go in VSCode Claude Code Extension, Downgrade it to 2.1.140, uncheck auto update the extension and restart VS Code.

Same issue:
Claude Code for VSCODE
Version: 2.1.141

The fix works also when downgrading to 2.1.139

Same issue

Same Unhandled case: [object Object] UI error, but with a different repro than OP — worth flagging since it's not a long-session issue here.

Env: VS Code extension 2.1.141, Windows 11, OAuth (claude.ai), model claude-opus-4-7[1m] with claude-haiku-4-5 sub-agents. No VPN/proxy.

Repro: brand-new sessions, fails within the first few turns (message_count ~100–125, not 556).

Log pattern — streaming stalls after the first chunk:

• [DEBUG] Stream started - received first chunk
• [WARN] [Stall] stream_idle_partial lastChunkAgeMs=15000 bytesTotal=702
• [WARN] Streaming stall detected: 39.7s gap between events
• [INFO] sdk_stream_ended_no_result {"had_error":true,"message_count":125}

Often correlated with a malformed tool-input from the Explore sub-agent right before the stall:

• [ERROR] SyntaxError: JSON Parse error: Unexpected token '.'
• [DEBUG] Read tool input error: required parameter ​file_path​ is missing

Repros more often when a turn dispatches Explore (many parallel Glob/Grep/Read via Haiku). Load-correlated, not deterministic — retry sometimes works.

UI fix suggestion regardless of root cause: stringify the fallback error properly (error?.message ?? error?.toString()) so users see something actionable instead of [object Object].

Since today, I have the same looking error on Windows 11, Sonnet 4.6 or Opus 4.7), direct API (not Bedrock), session of ~70 turns

Same thing, from VSCode addon, just from today onward I kept getting this error.

same here, VS Code plugin

Confirming 2.1.141 broken, 2.1.140 fixes it on Windows 11 + claude.ai OAuth (not Bedrock).

Environment: VS Code 1.120.0 / Windows 11 (10.0.26200) / claude.ai OAuth / claude-opus-4-7[1m] with claude-haiku-4-5 sub-agents / org fast mode on.

Matches @neoDD69's Windows-11 / OAuth sub-pattern. One severity bump: this morning on 2.1.141 the banner fired on every prompt, not intermittently — Reload Window cleared it for one or two prompts before it returned. Confirms the bug is not Bedrock-only.

Stalls predate the regression — narrows the suspect surface. Per-session counts from this machine, last three days, same account:

| Session | extension | stream_idle_partial | Streaming stall detected | sdk_stream_ended_no_result | Banner |
| --- | --- | ---: | ---: | ---: | --- |
| 2026-05-12 19:18 | 2.1.140 | 34 | 9 | 0 | no |
| 2026-05-13 09:02 | 2.1.140 | 111 | 22 | 1 | no |
| 2026-05-13 15:12 | 2.1.140 | 26 | 7 | 0 | no |
| 2026-05-14 10:07–11:55 (4 sessions) | 2.1.141 | 38 | 10 | 5 | last session: every prompt |
| 2026-05-14 12:35 (spans downgrade) | 2.1.141 → 2.1.140 | 5 | 3 | 1 | yes pre-downgrade, none post |

Stalls and even sdk_stream_ended_no_result events were already ambient on 2.1.140 (e.g. 2026-05-13 09:02 had a stream-end event and no banner). So 2.1.141 didn't introduce the upstream stalls — it introduced the rendering/recovery path that turns them into the throw site @aumanjoa and @klatu201 dissected. That puts the regression in the webview/fallback handler in 2.1.141, not in stream stability.

Workaround verified on Windows. @Antiklesys's downgrade to 2.1.140 plus disabling Auto Update on the extension cog. Multiple clean prompts since the downgrade, with stalls still occurring in the log but no banner.

Adding a data point that may broaden the reproduction conditions:

I'm hitting this on claude-opus-4-7[1m] in the VS Code extension on macOS (Darwin 25.4.0), but not only in long sessions:

• It triggers in sessions that have consumed as little as ~10% of context.
• It has never happened to me in a session that actually reached auto-compact.
• Multiple times per day (4+).
• Developer: Reload Window clears it, but it recurs shortly after.

So the "hundreds of turns / message_count: 556" framing in the original report may not be the full picture — turn count / context fill doesn't seem to be the gating factor in my case.

Small correction to my previous comment — checked the actual numbers on two sessions that just hit this: 12% and 15% of context consumed when it happened. Still well below auto-compact.

Same here. Confirming this is not Bedrock-only — reproducing on direct claude.ai with no Bedrock in the stack.

• Extension: 2.1.141
• VS Code on macOS (Darwin 25.4.0)
• Model: claude-opus-4-7[1m]
• Provider: claude.ai (Max), direct API

Seriously? same here +1

I upgraded to macosx Tahoe 26.5 and right after that, this issue started coming today. This is kinda deal-breaker for me.
vscode: 1.120.0 (Universal)
claude code extension: 2.1.141
Model: claude-opus-4-7 (1m)
Provider: claude.ai (Max)

Thanks to @FunkeDope! I downgraded the claude code extension to 2.1.140 and the issue seems to be resolved.

Reverting to the previous ext version in VSCode (Click Uninstall>Install Specific Version) resolves the issue for now at least, just fyi.

+1 — confirming this reproduces outside the Bedrock setup described
in the original report.

Environment

• Claude Code for VS Code: 2.1.141 (darwin-arm64)
• macOS: 15.3 (Darwin 24.3.0), Apple Silicon
• Plan: Claude Max (not Bedrock — direct Anthropic API via OAuth)
• Model: claude-opus-4-7[1m] (1M context variant, shown as "Default" in /model selector)

Symptoms (identical to the original report)

• "Unhandled case: [object Object]" banner appears in the webview after

long Thought blocks (>60s) combined with multiple tool calls in the
same turn (Read + Fetch + Agent).

• Session is silently cut. No way to recover within the same conversation.
• Additionally, a false "You've hit your usage limit" banner is shown

while actual usage is well below limits (Session 13%, Weekly 34%,
Weekly Sonnet 1%).

<img width="490" height="122" alt="Image" src="https://github.com/user-attachments/assets/05d2e27b-5c00-4a46-9af8-dd1329e1ec22" />

I have frequently been able to recover forward progress by dismissing the error, then prompting the Claude Code for VS Code extension (2.1.141) within VS Code (1.120.0 on Tahoe 26.3.1 (a)) with "ping to restart after VSCode glitch"

<img width="570" height="129" alt="Image" src="https://github.com/user-attachments/assets/6b3c02d7-6981-48c1-b991-9de723344c87" />

Working local fix for the Unhandled case: [object Object] crash — paste this whole comment into Claude Code and let it apply the patch for you.

This thread covers a lot of triggers (Bedrock 0-event streams, stalls, etc.), but the crash you actually see always comes from the same place: one helper in the bundled webview parser throws on any stream event it doesn't recognize, and that single throw takes down the whole webview render — while the CLI backend keeps working fine.

You can neutralize the crash regardless of what triggered it. 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 re-apply after upgrades (I run it from a SessionStart hook so it re-applies automatically).
• Safe idempotent find/replace — if the throwing version isn't present, nothing happens.
• Reload the VS Code window after applying.

Important: this fixes the crash, not whatever stalls/ends your stream in the first place — that's a separate server/extension bug. But it turns a session-killing red banner into a skipped event, so you stop losing in-flight work. I've been running it for a couple of days with no recurrence. Ideally the maintainers ship the same log-and-continue change so nobody has to patch their install. Also posted on #59013.

Further data points after another day of seeing this:

• It now occurs at as low as 4% context consumed — so context fill is definitively not the trigger.
• For me this is a regression: never happened before, started yesterday (2026-05-14) and now occurs constantly.

So in my environment the gating factor seems to be something that changed recently, not session length or context size. Possibly a recent extension/CLI update — happy to provide version info if useful.

Version info as offered: Claude Code 2.1.142 on macOS Darwin 25.4.0, VS Code extension, model claude-opus-4-7[1m].

Version info as offered: Claude Code 2.1.142 on macOS Darwin 25.4.0, VS Code extension, model claude-opus-4-7[1m].

so 2.1.142 has the same bug still? Should we all stay on 2.2.140???

Been happening every 3 prompts here since yesterday for me

I have the same issue since yesterday morning!

Guys, the problem is the same on VS Code in Windows 11. I confirm that downgrading to version 2.1.140 makes the problem disappear.

Closing, I am not getting this symptom anymore, and no one has reported in a while either