VS Code extension renderer leaks to JS-heap OOM (code: 5) on local macOS — detached_contexts

Renderer process memory leak → JS heap OOM crash (code: 5) during normal use

Summary

The Claude Code for VS Code extension (v2.1.177) leaks memory in the renderer process during normal use. The renderer's heap grows monotonically (no GC recovery) until it hits V8's heap limit and Electron kills the renderer with a JavaScript OOM (Reached heap limit). To the user this appears as VS Code repeatedly crashing with renderer process gone (reason: crashed, code: 5).

This was reproduced 15 times in one day on the affected machine and isolated to this extension by elimination (see below).

Environment

| | |
|---|---|
| VS Code | 1.124.2 |
| Electron | 42.2.0 |
| OS | macOS 26.5 (Apple M3 Max) |
| Extension | anthropic.claude-code 2.1.177 (latest on Marketplace) |
| Hardware acceleration | reproduced both ON and OFF (disable-hardware-acceleration: true) |
| System RAM | 97% free throughout — NOT a system-memory-pressure issue |

Crash signature (from Crashpad minidumps)

process type: renderer
JavaScript OOM (Reached heap limit)
electron.v8-oom.heap.detached_contexts   <-- context leak fingerprint
electron.v8-oom.heap.native_contexts
electron.v8-oom.old_space.size / old_space.used

The detached_contexts annotation points to webview JS contexts being detached but retained (not garbage-collected), accumulating until OOM.

Reproduction

1. Open a workspace and use the Claude Code panel normally — stream responses, scroll output, continue a session over several minutes.
2. Watch the renderer process RSS (Code Helper (Renderer)).
3. The renderer climbs steadily and never releases; after enough use it OOM-crashes the renderer (code: 5). Crash recurs every few minutes of active use.

Captured memory traces (renderer RSS, sampled every 2s)

Run A — full extension set: renderer 0.8 GB → 6.95 GB in ~90s, then crash.

21:55:53  renderer=820MB
21:56:06  renderer=5092MB
21:56:22  renderer=6859MB
21:56:27  renderer=6950MB
21:56:29  renderer=57MB     <-- renderer crashed/restarted

Run B — ISOLATION (only Claude enabled; APC, vscode-animations, ChatGPT, Gemini, drawio all --disable-extension): renderer 0.6 GB → 6.8 GB, then crash. Same result with everything else off.

22:08:21  renderer=4531MB
22:08:42  renderer=5795MB
22:08:54  renderer=6813MB
22:08:58  renderer=0MB      <-- renderer crashed

Run B rules out other webview/UI extensions and confirms the leak tracks the Claude Code webview.

What was ruled out

• System RAM — stayed 97% free the entire time; not memory pressure.
• GPU / hardware acceleration — reproduced with disable-hardware-acceleration: true (renderer flags --disable-gpu-compositing, gpu-process --use-gl=disabled). It is a JS-heap OOM, not a GPU fault.
• Other extensions (APC/Customize UI, vscode-animations, ChatGPT, Gemini, drawio) — disabled in Run B; leak persisted.

Expected

Renderer memory should plateau / be reclaimed by GC during a long session; the webview should release detached contexts.

Actual

Renderer memory grows unbounded during use and OOM-crashes the renderer (code: 5), losing editor state.

Workarounds currently in use

• Developer: Reload Window resets the renderer to ~0.6 GB (temporary).
• Starting fresh conversations instead of long-running threads slows the growth.

Happy to provide the full minidumps and per-2s memory logs.

Possibly related (cross-reference for triage)

• #64741 — Extension host memory leak in Remote-WSL leads to renderer OOM crash (same product, but Remote-WSL / extension-host; this report is local macOS and the leak is in the renderer/webview).
• #56379 — Desktop app renderer crashes (exitCode 5) on large sessions (same renderer-OOM signature, but Desktop app surface rather than the VS Code extension).
• #65624 — macOS renderer v8-oom crash loop (Desktop app).