claude-code - 💡(How to fix) Fix [BUG] VSCode webview crash "Error rendering content: disposing of store" — AggregateError from DisposableStore during long agent sessions

Preflight Checklist

• I have searched existing issues
• Single bug report
• Using latest version

⚠️ This is the same bug as #19074 (wrongly auto-closed)

#19074 was auto-closed as a duplicate of #13603 by a bot, but #13603 is a completely different bug ("yes and don't ask again" permission prompt triggering a white screen). The dedup is incorrect — #19074 had the exact same error message as this report ("Error rendering content: Encountered errors while disposing of store..."), but was closed without analysis and the thread is now locked, so I cannot reopen or comment there. This issue provides the full root cause that was missing from #19074.

Environment

• Claude Code VSCode extension: 2.1.142 (darwin-arm64), also present in 2.1.143
• VSCode: stable channel
• macOS: Darwin 25.3.0, Apple Silicon
• Model: Opus 4.7 (1M context)
• Session context: ~2-hour active session, 14+ streaming stalls (longest 215s), 200+ messages, custom agent batch-editing markdown files

Symptom

A red banner appears mid-response:

Error rendering content: disposing of store

Something went wrong. Re-launch the extension to continue.

Backend continues processing normally — file Edits are applied atomically (confirmed in extension log), Stream chunks keep flowing. UI is frozen. Session title later auto-changes to "Resume interrupted work session", indicating the extension's own recovery path was triggered.

Root cause (analyzed from webview bundle)

The webview's j5() disposable-list disposer (a VSCode lifecycle pattern bundled into the webview) catches multiple sub-dispose() errors and rethrows as AggregateError(errors, "Encountered errors while disposing of store"). This bubbles to a React ErrorBoundary (class Yk) whose fallback UI renders error.message. User sees the truncated message "disposing of store".

Source locations in webview/index.js (extension 2.1.143):

• Disposer + AggregateError throw: byte offset ~265470
• ErrorBoundary class Yk + fallback: byte offset ~4480000

Webview does NOT use Redux/Zustand (useStore/zustand/createStore zero hits in bundle). The "store" is VSCode's DisposableStore lifecycle util, not a state container.

Upstream mechanism (VSCode native)

The exact error string "Encountered errors while disposing of store" originates from VSCode's own vs/base/common/lifecycle.ts. The same error shape was discussed upstream in:

• microsoft/vscode#138804 — Error: Encountered errors while disposing of store. Errors: [TypeError: d.dispose is not a function, ...] (2022-01)
• microsoft/vscode#136150 — same mechanism, earlier (2021-12)

This means the bundled VSCode disposable machinery is doing the right thing (reporting that some sub-disposables failed) — but Claude Code's webview is not catching the resulting AggregateError at the React boundary, so it escalates into a full UI crash instead of a silent recovery.

Related (same generation, different paths)

Webview render crashes that appeared in the same release window:

• #59526 — VSCode renderer disconnects during long multi-step tasks (filed the same minute as this incident)
• #58984 — Webview "Unhandled case: [object Object]" + backend keeps working (has the best root-cause writeup; closed as duplicate)
• #59022, #59015, #59131, #59220, #52151 — same family, different trigger paths (SSE event parsing, markdownlint diagnostics, etc.)

These are all symptoms of the same underlying weakness: the webview's ErrorBoundary surface lacks defensive wrapping around lifecycle/cleanup paths. Suggest looking at the family holistically rather than patching each trigger individually.

Reproduction (probabilistic)

• Long session (200+ messages)
• Custom agent doing rapid sequential Edit calls on large markdown files
• Multiple streaming stalls ([Stall] stream_idle_partial) in log
• Total session duration > 1 hour

Suggested fix

1. Wrap each individual dispose() in the webview's React cleanup paths to swallow + log instead of throw, so unrelated component cleanups don't aggregate-fail.
2. ErrorBoundary should include error.cause and error.errors (AggregateError sub-errors) in console.error and ideally in the UI banner, so devs/users can identify which component crashed.
3. Don't truncate error.message in the UI — show the full string ("Encountered errors while disposing of store"), or prefix with a stable error code so this can be tracked.
4. (Process) Revisit the auto-dedup heuristic that closed #19074 against #13603 — these have completely different error messages.

Workarounds (confirmed)

• Developer: Reload Window — recovers from session jsonl, ~30s
• For critical long sessions, fall back to claude CLI in VSCode integrated terminal (TUI does not have this bug)