Renderer repeatedly crashes with V8 "Reached heap limit" OOM, correlates with diff tab open/close

Status Fixed / completed

Reported on v2.1.234

Maintainer reply None cached

Activity 3 comments · opened Aug 18, 2026 · closed Aug 18, 2026

Description

The VS Code renderer process crashes repeatedly (reason: 'crashed', code: '5'), showing the "The window terminated unexpectedly" dialog. This happened 15 times in a single evening session (18:10-20:59, roughly every 10-20 minutes).

Inspecting the Crashpad .dmp files directly (via strings) shows the crash is a V8 JS heap OOM, not an OS-level kill:

v8-oom-location
Reached heap limit
Script OOM (Reached heap limit).

Checked across 4 independent crash dumps from the same session - all show the same signature. No corresponding kernel/runningboardd/jetsam/sandboxd kill messages appear in the unified log at the crash timestamps, and main.log only shows:

Extension host with pid <pid> exited with code: 0, signal: unknown.
CodeWindow: renderer process gone (reason: crashed, code: 5)

with nothing in the Claude Code extension host log (Claude VSCode.log) near the crash time - no errors/warnings logged before it happens.

Environment

VS Code: 1.133.0 (Electron 42.8.0)
Extension: anthropic.claude-code 2.1.234 (darwin-arm64), latest as of writing
OS: macOS (Apple Silicon)

Suspected trigger

Based on usage pattern across multiple sessions, the crashes correlate with opening/closing diff view tabs produced by the extension (reviewing edits Claude makes). Suspect something in the diff webview or the associated JS objects isn't being released, causing the renderer's V8 heap to grow unbounded across a session until it hits the heap limit and crashes.

Steps to reproduce (best guess, not fully isolated)

Use Claude Code extension for an extended session, having it open/close several diff tabs for file edits.
After roughly 10-20 minutes of this, the renderer crashes with the heap-limit OOM above.

Crash timestamps (single session, 2026-08-18)

18:10, 18:53, 18:56, 19:00, 19:03, 19:07, 19:25, 19:31, 19:43, 19:46, 19:56, 20:34, 20:42, 20:51, 20:59

Ask

Is there a known memory leak tied to the diff view / diff tab lifecycle?
Any recommended workaround (e.g., a setting to reduce retained diff state, or limit concurrent diff webviews) short of restarting VS Code every ~15 minutes?

---
Screenshot of the crash dialog attached below (drag-and-dropped manually).

View original on GitHub ↗

3 Comments

rhythmii · 1 month ago

rhythmii · 28 days ago

Still reproducing — now confirmed on 2.1.274 as well

Original report was on VS Code 1.133.0 / extension 2.1.234. Still happening on VS Code 1.138.0 with extension 2.1.272 → 2.1.273 → 2.1.274 (macOS, arm64).

Timeline (last ~24h)

Renderer crashes (CodeWindow: renderer process gone (reason: crashed, code: 5)), each confirmed via Crashpad .dmp as a v8-oom signature (Script OOM (Reached heap limit) / Ineffective mark-compacts near heap limit):

2026-09-16: 18:00, 18:09, 18:21, 18:30 (extension 2.1.272/273)
2026-09-17: 09:31, 09:36, 09:42, 09:49, 10:59, 13:11

I upgraded to 2.1.274 mid-session this morning (~09:40). The 10:59 and 13:11 crashes both happened after that upgrade, on 2.1.274 — so whatever changed in 2.1.274 hasn't fixed the underlying leak for this workload.

Crash-loop pattern

The tightest cluster (09:31 → 09:36 → 09:42 → 09:49, ~5–7 min apart) lined up with the "Reopen" flow bringing the Claude Code chat panel back each time. Checking the workspace's state.vscdb, the thing being restored on reopen is specifically the Claude Code webview panel (viewType: mainThreadWebview-claudeVSCodePanel) — the panel that renders the chat/diff UI — not a plain diff editor tab. Restoring it immediately re-triggers the leak, turning a single OOM into a fast repeat-crash loop. Deleting the memento/workbench.parts.editor key for the workspace (same effect as checking "Don't restore editors" on the crash dialog) stops that specific loop, but it's a workaround for the loop, not a fix for the leak itself.

Already tried, no effect on frequency

"js-flags": "--max-old-space-size=8192" (8GB heap) in argv.json — still hits the limit. So this isn't just "default heap too small."

2.1.274 changelog

Adds "a visible warning when memory usage is critical, with steps to free memory or restart safely" — looks like UX around the symptom, not a stated fix for the leak.

Happy to share specific .dmp files, renderer logs, or a heap snapshot if that helps narrow down what's being retained in the panel's webview (or extension host) across the diff/chat lifecycle.

rhythmii · 27 days ago

This issue was closed shortly after being filed, but the reporter's latest comment indicates the underlying bug is still present and unresolved:

Still reproducing on the latest extension version (2.1.274), across 2.1.272 → 2.1.273 → 2.1.274.
Raising the V8 heap limit to 8GB (--max-old-space-size=8192) did not reduce crash frequency, ruling out "default heap too small" as the cause.
New finding: VS Code's "Reopen" flow restoring the Claude Code webview panel (mainThreadWebview-claudeVSCodePanel) appears to immediately re-trigger the leak, turning a single OOM into a fast repeat-crash loop.
The 2.1.274 changelog only adds a low-memory warning UI, not a fix for the leak itself.

Given there's an active, reproducible memory leak with supporting crash-dump evidence and a concrete new lead (webview panel restore lifecycle), requesting this issue be reopened for further investigation.

---
_Generated by Claude Code_