[VS Code] Conversation webview renderer holds ~645MB RSS; /compact and closing sessions don't release it

[Alex-Fleet]

Environment

• Claude Code VS Code extension 2.1.216 (darwin-arm64)
• macOS, 8GB physical RAM
• 4 parallel Claude Code sessions open in VS Code

Observed

• One Code Helper (Renderer) process (a webview renderer) reached ~645MB RSS with ~47% CPU while the window appeared idle.
• Six renderer processes in total used ~1.3GB RSS.
• This memory pressure pushed the machine to ~3.76GB/4GB swap, making the system near-unresponsive.
• /compact reduced the token context in the claude process but did not reduce the renderer RSS. Closing session tabs also did not reliably release the renderer memory.

Questions / requests

1. Is the conversation panel expected to keep this much rendered DOM in the webview for long sessions? Would virtualized rendering (only visible + nearby messages in the DOM) be feasible?
2. Could /compact (or closing a session) explicitly tear down and re-create the webview from the trimmed transcript?
3. If neither is easy, a setting to cap webview memory would help.

Happy to provide more measurements (e.g. renderer RSS vs transcript size across a range of session lengths) if that helps.

[drewthomas00]

Seeing the same thing on Linux with a newer build. Adding per-tier measurements in case they help narrow it down.

Environment: extension 2.1.227 + CLI 2.1.227, VS Code (Code - OSS) 1.131.0, Linux 6.18, 62 GB RAM, 4–8 parallel sessions.

I sampled the whole VS Code process tree every 60 s for ~5 hours (296 samples), recording PSS per tier. (PSS rather than RSS: RSS counts each shared Electron mapping once per process, which substantially overstates a 30-process tree.)

One webview renderer accounts for most of the growth

tier	start	peak	net growth
renderer	924 MB	5317 MB	+3612 MB
claude processes (4→8 sessions)	1030 MB	2234 MB	+1136 MB (tab count, see below)
extension host + other Node utilities	1063 MB	2388 MB	+84 MB net
tsserver	369 MB	1784 MB	+164 MB net
gpu, main, language servers, misc	441 MB	543 MB	+95 MB
tree total	3829 MB	9634 MB	+5092 MB (~1 GB/hour)

Net growth is last sample minus first over the full window; the raw dataset is linked at the bottom.

And nearly all of the renderer tier is a single process. Snapshot captured automatically as the tree crossed my alert threshold, a minute before the sampled peak:

# total 9024 MB PSS / 11746 MB RSS, 31 procs, 8 Claude sessions
 4195427 KB pss   4307272 KB rss  renderer   pid=3369519   <- the webview
  498048 KB pss    571256 KB rss  node utility
  392186 KB pss    490308 KB rss  extension host
  351536 KB pss    414928 KB rss  tsserver
  343366 KB pss    462472 KB rss  claude
     ...
  281986 KB pss    401984 KB rss  renderer   (an editor window's own renderer)

(Excerpt — the full file is examples/snapshot-incident-v1.txt, lightly annotated here: that version of the sampler labeled both Node utilities exthost; the 498 MB one has no inspect port and is VS Code's shared-process tier, the 392 MB one is the actual extension host.)

Over 4 GB in one process, while the next largest in the tree is 486 MB. The growth is a monotonically rising floor with a GC sawtooth on top — it does collect, it just never comes back down.

The other tiers look healthy, which is the useful part

• Extension host: +84 MB net over 5 hours, oscillating between 1009 and 2388 MB with GC reclaiming it every time. Whatever the webview is holding, the host side of the same conversation data is not holding it.
• tsserver: peaked at 1784 MB, back down to 533 MB by the end. Ordinary sawtooth.
• claude processes are flat per session: ~299 MB/session averaged across the 4-tab samples, ~267 MB/session across the 8-tab samples. That tier scales with tab count, not with time, so the accumulation isn't in the CLI.

Identifying the process

It is an extra renderer beyond the editor windows' own — those are separate processes that stay in the 250–320 MB range for the whole window — created within half a second of an extension-host restart, and started with no --max-old-space-size. That is consistent with the out-of-process iframe for the conversation webview.

It's live accumulation, not load-on-resume

Two observations point the same way. Process size is strongly sublinear in transcript size: a fresh session's claude process is 238 MB, while one resuming a 224 MB transcript is 295 MB. And opening sessions barely moves the webview: the three session-open events in the window account for ~0.5 GB of the renderer's +3.6 GB, with the rest accruing while sessions were simply running. The webview isn't large because the transcripts are large; it's large because of what streamed through it.

Confirming what doesn't release it

/compact and closing session tabs both behave as you describe (closing tabs also matches #16508). One to add:

• claudeCode.focusView has no effect on memory. It applies immediately, with no reload needed, but it only hides tool calls from the view — the messages stay in webview state. It's a display filter rather than eviction.

The available workaround has a side effect that rules it out

Developer: Reload Webviews (workbench.action.webview.reloadWebviewAction) does free the renderer heap without touching the extension host or the claude processes, so open sessions survive it. But it pauses every running agent, which makes it unusable for the parallel-session workflow that produces the growth in the first place.

If full message virtualization is a large piece of work, a narrower option might be a "tear down and rebuild this conversation's webview from extension-host state" path, since the host side is measurably not leaking (+84 MB net above).

---

The sampler is here if it's useful for reproducing this, or for others on the thread: https://github.com/drewthomas00/vscode-memory-watch — examples/history-incident-v1.csv is the raw 296-sample dataset behind these numbers.

Happy to run any specific measurement; I have it sampling continuously and can share per-tier curves or a snapshot at peak.