[BUG] VSCode webview crash "Error rendering content: disposing of store" — AggregateError from DisposableStore during long agent sessions

Preflight Checklist

• [x] I have searched existing issues
• [x] Single bug report
• [x] 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.

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

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

1. (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)