Renderer crashes with V8 heap OOM (~4 GB cap) — regression introduced in 1.125 (runtime unchanged from 1.124)

Type: Performance Issue / Crash

Does this issue occur when all extensions are disabled? — Not yet fully confirmed.
The OOM is in the renderer process; my heaviest extension (Sapling SCM) runs in the
separate extension host, so disabling extensions may not be conclusive. However, the
regression is reproducible on the same machine and same workspace purely by changing the
VS Code version (see A/B below), which points at workbench renderer code, not an extension.

VS Code Version

• Version: 1.126.0 (also reproduced on 1.125.x)
• Commit: 7e7950df89d055b5a378379db9ee14290772148a
• Date: 2026-06-23
• Electron: 42.3.0 / Chromium: 148.0.7778.180 / Node: 24.15.0
• OS: macOS 26.5.1 (25F80), Apple M4 Pro, 48 GB RAM

Last known good: 1.124.2 (identical Electron/Chromium/Node — see "Runtime is unchanged").

Summary

The workbench renderer process's V8 JavaScript heap grows until it hits V8's ~4 GB
per-isolate ceiling, then aborts. The window dies with:

[error] CodeWindow: renderer process gone (reason: crashed, code: 5)

code: 5 is how Electron surfaces a V8 fatal OOM abort at the window level — the Crashpad
minidump confirms it is an out-of-memory (annotations below).

Physical RAM is irrelevant (48 GB free headroom); V8 caps each renderer heap at 4 GB. GPU
acceleration is disabled, so this is not a GPU/WebGL issue. Large integrated-terminal
output (e.g. ls -la on a big directory) reliably triggers the final crash, but the heap is
already sitting near 4 GB — the terminal output is the last allocation, not the root cause.

Steps to Reproduce

1. Open a large multi-root / multi-window workspace (I run ~8 windows; heavy SCM activity).
2. Work normally for a while so the main renderer heap climbs (watch it in
   Developer: Open Process Explorer — the window renderer approaches ~4000 MB).
3. Produce a burst of integrated-terminal output (e.g. ls -la ~/Library).
4. The renderer crashes; the extension host then exits cleanly ("renderer closed the MessagePort").

Repeats reliably: 20 of 20 recent Crashpad dumps carry v8-oom annotations.

Runtime is unchanged — so this is a VS Code JS regression

Per the community version tracker (ewanharris/vscode-versions), 1.124, 1.125 and 1.126 all
ship the identical runtime: Electron 42.3.0, Chromium 148.0.7778.180, Node 24.15.0.

Combined with the controlled A/B below, the increase in renderer heap consumption is in
VS Code's own workbench JavaScript shipped in 1.125, not in Chromium/V8.

Controlled A/B (same machine, same workspace, same synced settings)

A second laptop with the same synced settings/extensions does not crash — consistent with
Settings Sync not replicating open windows/folders/panels or on-disk workload, i.e. the second
machine's renderer simply never accumulates to 4 GB.

Evidence — Crashpad minidump heap annotations (renderer, main isolate)

Extracted from ~/Library/Application Support/Code/Crashpad/completed/*.dmp:

--type=renderer  (Code Helper (Renderer))
v8-oom-is-main-isolate:            true
electron.v8-oom.heap.limit:        4294967296   (4.00 GiB — V8 hard cap)
electron.v8-oom.heap.total:        4168581120   (3.88 GiB)
electron.v8-oom.heap.used:         4162167016   (3.88 GiB — at the ceiling)
electron.v8-oom.heap.external_memory: 25657430  (~24 MB)
electron.v8-oom.heap.malloced_memory: 1069084   (~1 MB)
electron.v8-oom.heap.detached_contexts: 0
electron.v8-oom.heap.native_contexts:   3
v8-oom-global-handle-count:        3072

Embedded V8 GC log at the moment of death (GC freeing nothing, efficiency → 0):

10383 ms: Mark-Compact 3993.3 (4000.5) -> 3993.3 (4000.7) MB ... allocation failure; scavenge might not succeed
10771 ms: Mark-Compact 3993.3 (4000.7) -> 3993.3 (4000.7) MB ... (current mu = 0.000) allocation failure; scavenge might not succeed

Interpretation (what to look at)

• detached_contexts: 0, native_contexts: 3 → not a leaked-webview / detached-DOM leak.
• external_memory: ~24 MB, malloced: ~1 MB → not ArrayBuffers / external buffers.
• Therefore ~3.88 GB is ordinary JS objects on the managed V8 heap in the main workbench
  renderer — a growing in-heap data structure in workbench JS. Given the terminal trigger,
  the integrated-terminal buffer/scrollback or an accumulating workbench cache are prime
  suspects. A live heap snapshot (retainer graph) is needed to name the exact structure; the
  minidump doesn't carry the object graph.

What I ruled out

• GPU / WebGL — terminal.integrated.gpuAcceleration already off; crash is JS-heap.
• Physical memory — 48 GB, crash is at V8's 4 GB per-renderer cap, not OS OOM.
• Settings / extensions config — identical (synced) on an unaffected machine.
• Chromium/Electron/Node — byte-identical across 1.124–1.126.

Ask

Please investigate what in the 1.125 workbench renderer increased steady-state / peak JS heap
usage enough to reach the 4 GB V8 ceiling. Happy to attach a .heapsnapshot and full Crashpad
dumps on request.