VS Code extension: renderer V8 OOM (~4GB) from memory leak during active panel use; speech-to-text accelerates it

Summary

The VS Code extension leaks memory during active panel use, crashing the renderer with a V8 OOM at the ~4 GB heap ceiling. The window dies with renderer process gone (reason: crashed, code: 5), taking the in-progress conversation with it. Idle usage does not leak — the leak only accumulates while the panel is actively streaming/rendering. Using the built-in speech-to-text accelerates it dramatically.

Extension version: 2.1.209 (latest at time of writing)
VS Code: 1.128.1, x64 (universal build)
OS: macOS 15.7 (24G222), Intel x86_64, 64 GB RAM

Evidence

Crash dump (~/Library/Application Support/Code/Crashpad/completed/*.dmp) contains:

Ineffective mark-compacts near heap limit
electron.v8-oom.old_space.used = 4056416256   (≈4.05 GB)
--type=renderer

This is the V8 old-space ceiling, not system memory pressure — the machine has 64 GB, ~50 GB free at the time.

Idle does not leak. A window left open for 4h30 with the panel idle sat flat at 354 MB / ~4096 MB (8%), no crash.

Active use crashes in minutes. During a 34-minute window of active panel use: 9 crashes.

13:22:34  13:30:08  13:35:53  13:37:33  13:39:22
13:42:38  13:49:19  13:51:05  13:56:36

After each crash the window reloads, memory resets to baseline, and it climbs again — the classic sawtooth of a leak rather than a single oversized allocation.

Speech-to-text is a strong accelerant. Correlating start_speech_to_text in the extension log against renderer crashes: 4 of 6 uses were followed by a crash within 1–3 minutes.

🎤 13:32:44 → 💥 crash 3m09s later
🎤 13:36:08 → 💥 crash 1m25s later
🎤 13:38:06 → 💥 crash 1m16s later
🎤 13:40:33 → 💥 crash 2m05s later

14 renderer crashes in one day; 40 crash dumps over 6 days.

Hypotheses ruled out

To save triage time, these were tested and eliminated:

• Large session history — not the cause. fetchSessions reads only a fixed-size head/tail buffer per .jsonl (fh.read(buf, 0, N, 0) + fh.read(buf, 0, N, size-N)), so listing is cheap even with 159 MB of history. This part is well designed.
• One oversized session — the session open at crash time was 3 MB, not one of the large ones (28/21/14 MB).
• Base64 images in the transcript — only 1.6 MB of base64 in that session.
• Stale extension — already on the latest published version (2.1.209).

Impact

There is no user-side mitigation. VS Code does not expose --js-flags or --max-memory (confirmed in code --help), so the 4 GB renderer ceiling cannot be raised. The only workaround is to preemptively run Developer: Reload Window before the ceiling is hit — otherwise the crash interrupts work in progress.

This disproportionately affects users who chose the panel for the speech-to-text feature, since that is the fastest path to the crash. The CLI is unaffected (separate process, no renderer heap ceiling).

Repro

1. Open the Claude Code panel in VS Code.
2. Use it actively — send messages, let responses stream, and use the mic button a few times.
3. Watch the renderer's RSS climb (ps -axo pid,rss,command | grep "Code Helper (Renderer)").
4. Within minutes it reaches ~4 GB and the window dies with renderer process gone (reason: crashed, code: 5).

Happy to provide a crash dump or the raw main.log timeline if useful.