Extension chat webview causes renderer OOM crash (code 5) after large agent turns

Summary

The VS Code extension's chat webview appears to trigger renderer-process OOM crashes (CodeWindow: renderer process gone (reason: crashed, code: 5)) after large agent turns. Reproduced 6 times in ~30 minutes in one session, with crash frequency accelerating. Every crash correlates with the chat webview having just finished rendering a large turn output.

Environment

• VS Code: 1.139.0 (commit 2242ebbb54efeeb0129e08e919e7e8d43033cd83), arm64, macOS Darwin 27.0.0
• Extension: anthropic.claude-code, auto-updated mid-session through versions 2.1.251 → 2.1.263 → 2.1.266 → 2.1.280 → 2.1.282
• Remote workspace via Remote-SSH (ssh-remote+<host>)
• ~6 VS Code windows/extension hosts total across the session (2 physically open at time of investigation; the rest are prior crash-restart cycles of the same 1-2 windows)

Crash timeline (from main.log)

2026-09-25 13:42:05.876 [error] CodeWindow: renderer process gone (reason: crashed, code: 5)
2026-09-25 13:47:09.003 [error] CodeWindow: renderer process gone (reason: crashed, code: 5)   (+5m4s)
2026-09-25 13:59:48.250 [error] CodeWindow: renderer process gone (reason: crashed, code: 5)   (+12m39s)
2026-09-25 14:03:22.324 [error] CodeWindow: renderer process gone (reason: crashed, code: 5)   (+3m34s)
2026-09-25 14:07:07.463 [error] CodeWindow: renderer process gone (reason: crashed, code: 5)   (+3m45s)
2026-09-25 14:10:40.982 [error] CodeWindow: renderer process gone (reason: crashed, code: 5)   (+3m33s)

Evidence: crash correlates with turn size, not general idle time

From each window's exthost/Anthropic.claude-code/Claude VSCode.log, the last [engine] turn ... end line before each crash:

| Crash time | Turn output size | API call duration | Gap turn-end → crash |
|---|---|---|---|
| 13:42:05 | out=309173 tokens | api=3986680ms (~66 min) | 47s |
| 14:10:40 | out=27287 tokens | api=347145ms (~5.8 min) | 0.5s |
| 14:07:07 | out=7261 tokens (turn 13 of a growing session) | api=94910ms | — |

Larger single-turn outputs correlate with faster/more severe crashes, and even a growing multi-turn session with modest per-turn output eventually crashes (suggesting cumulative transcript size in the webview DOM matters, not just single-turn size).

Evidence: V8 heap exhaustion in the renderer, not a system-wide OOM

log show (macOS unified log) around each crash shows the renderer's V8 heap failing to allocate right up to the crash, captured by chrome_crashpad_handler:

Scavenge (during sweeping) 3993.2 (4035.0) -> 3966.6 (4038.2) MB, pooled: 0.0 MB ... allocation failure
Scavenge (during sweeping) 3998.2 (4040.0) -> 3971.5 (4043.2) MB, pooled: 0.0 MB ... allocation failure

System-wide free memory / swap were not under pressure at the time (memory_pressure: 89% free, 0 swap used) — this is a per-process V8 heap ceiling being hit, localized to the renderer.

Evidence: sudden explosive growth right before crash, not a slow leak

Process-level sampling (ps, 20s interval) of the crashing renderer PID immediately before the 14:10:40 crash:

14:10:13  RSS=676224 KB   CPU=6.9%
14:10:34  RSS=5918512 KB  CPU=229.1%     <- +5.2GB in 21s
14:10:40  (crash)

The paired extension host process for the same window climbed in lockstep (RSS 2.3GB→2.7GB, CPU 18%→61%) over the same window, consistent with a large payload being marshalled from the extension host to the webview and then rendered.

Evidence: stale extension instances not being disposed across in-session auto-updates

Repeated resource-load errors for extension versions that were no longer installed on disk at the time (only 2.1.280/2.1.282 present):

[error] vscode-file: Failed to load resource /Users/<user>/.vscode/extensions/anthropic.claude-code-2.1.251-darwin-arm64/resources/claude-logo.svg net::ERR_FILE_NOT_FOUND
[error] vscode-file: Failed to load resource /Users/<user>/.vscode/extensions/anthropic.claude-code-2.1.263-darwin-arm64/resources/claude-logo.svg net::ERR_FILE_NOT_FOUND
[error] vscode-file: Failed to load resource /Users/<user>/.vscode/extensions/anthropic.claude-code-2.1.266-darwin-arm64/resources/claude-logo.svg net::ERR_FILE_NOT_FOUND

This suggests old webview panel instances from earlier in-session extension auto-updates are kept alive (still trying to resolve their original resource paths) instead of being disposed, raising the renderer's memory baseline before any large-turn spike even happens.

Shutdown-time teardown errors in exthost.log also repeatedly trace into the Claude Code extension:

[error] Error: Channel has been closed
    at J5.closeChannel (/Users/<user>/.vscode/extensions/anthropic.claude-code-2.1.282-darwin-arm64/extension.js:385:45810)
    at J5.closeAllChannels (.../extension.js:385:47399)
    at J5.shutdown (.../extension.js:385:47137)

Suggested areas to investigate

1. Chat webview rendering path for very large turn outputs (tens/hundreds of thousands of tokens) — likely rendering the full transcript into the DOM without virtualization/chunking.
2. Webview/panel disposal on extension auto-update mid-session — old instances appear to remain referenced instead of being torn down.
3. Whether cumulative session transcript size (across many turns) is retained in the webview even when individual turns are small.

Impact

VS Code (and by extension, its integrated terminal) becomes unusable for the affected window — reported to the user generically as "terminal crashed" since the terminal panel lives in the same renderer that gets killed.