[BUG] Claude Desktop (Windows): 22 renderer processes retained for 9 sessions in a single pane — 7 GB RSS / 15 GB commit, one renderer at 7.7 GB commit, never released on session switch

Status Open
Reported on v2.1.284
Maintainer reply None cached
Activity 1 comment · opened Oct 2, 2026

What's Wrong?

Claude Desktop on Windows keeps a Chromium renderer process alive for every session view it has ever shown, and never releases it when you switch away. With 9 active sessions, one window, one pane, no pop-outs and no side panels open, the app is running 22 Claude.exe --type=renderer processes holding 7.0 GB working set / 15.3 GB commit. One renderer alone has 2.0 GB resident and 7.7 GB committed.

The agents themselves are not the problem: the 11 bundled claude.exe CLI processes total 2.8 GB. It is the UI layer that is eating the machine.

Process breakdown after ~36 h of app uptime (Claude.exe only):

| Role | Count | Working set | Commit |
|---|---|---|---|
| renderer | 22 | 6,980 MB | 15,340 MB |
| claude-code agent (bundled CLI) | 11 | 2,817 MB | 6,222 MB |
| app shell | 1 | 493 MB | 533 MB |
| utility | 7 | 299 MB | 613 MB |
| gpu-process | 1 | 160 MB | 440 MB |

Renderer spawn pattern. Note the four heavy ones created in a two-minute burst the previous evening and the twelve created one every few minutes tonight while I was switching between sessions in the sidebar:

| client-id | spawned | working set | commit |
|---|---|---|---|
| 7 | 09-30 09:12 | 1,169 MB | 1,445 MB |
| 5 | 09-30 09:12 | 24 MB | 32 MB |
| 154 | 09-30 19:31 | 576 MB | 1,682 MB |
| 155 | 09-30 19:32 | 2,048 MB | 7,715 MB |
| 157 | 09-30 19:33 | 579 MB | 1,709 MB |
| 156 | 09-30 19:33 | 576 MB | 1,702 MB |
| 165 | 09-30 19:40 | 15 MB | 28 MB |
| 182 | 10-01 00:05 | 8 MB | 75 MB |
| 184 | 10-01 01:49 | 125 MB | 106 MB |
| 271 | 10-01 14:12 | 13 MB | 27 MB |
| 354 | 10-01 19:50 | 64 MB | 75 MB |
| 359 | 10-01 20:03 | 174 MB | 75 MB |
| 362 | 10-01 20:39 | 136 MB | 120 MB |
| 363 | 10-01 20:55 | 146 MB | 80 MB |
| 364 | 10-01 20:59 | 130 MB | 25 MB |
| 365 | 10-01 21:00 | 143 MB | 45 MB |
| 369 | 10-01 21:05 | 169 MB | 67 MB |
| 368 | 10-01 21:05 | 147 MB | 41 MB |
| 370 | 10-01 21:06 | 141 MB | 39 MB |
| 371 | 10-01 21:11 | 167 MB | 52 MB |
| 372 | 10-01 21:17 | 228 MB | 114 MB |
| 373 | 10-01 21:20 | 202 MB | 86 MB |

The app's own layout report at the time of the snapshot (via the ccd_window MCP exposed to sessions):

{"main_window":{"tab":"code","sidebar_collapsed":false,"panes":[{"index":0,"col":0,"row":0,"kind":"session","focused":true}]},"popout_windows":{"sessions":[],"other_windows":0}}

One pane. Twenty-two renderers.

System impact: 31 GB machine, 53.9 GB committed, Free & Zero Page List down to ~1 GB (it was 144 MB earlier in the day before I closed an Android emulator and a browser to make room). Windows was trimming working sets hard and the whole desktop stuttered.

What Should Happen?

Roughly one renderer per visible pane, plus the shell. Switching away from a session should tear down or at least suspend its view process. A session view that is not on screen should not hold 2 GB resident and 7.7 GB committed indefinitely.

Error Messages/Logs

No crashes, no errors. This is pure retention. Diagnostic one-liner used (Windows PowerShell):

Get-CimInstance Win32_Process -Filter "Name='claude.exe'" |
  Where-Object { $_.CommandLine -match '--type=renderer' } |
  ForEach-Object { $p = Get-Process -Id $_.ProcessId; "{0,-6} {1:MM-dd HH:mm}  WS {2,5:N0} MB  commit {3,6:N0} MB" -f $_.ProcessId, $p.StartTime, ($p.WorkingSet64/1MB), ($p.PagedMemorySize64/1MB) }

Steps to Reproduce

  1. Claude Desktop (Windows), Code tab, 8 to 10 sessions in the sidebar, all actively used.
  2. Leave the app running for a day. Work normally: click between sessions in the sidebar, let agents run.
  3. Keep a single pane, no splits, no pop-outs, no side panels.
  4. Run the PowerShell above. Observe far more --type=renderer processes than visible panes, with spawn times that track session switches, and working sets that only grow.
  5. Quit and relaunch the app. Sessions resume (agents run with --resume); renderer memory drops to ~100 to 200 MB each. This is the only mitigation I have found.

Ruled out: Remote Control. Turning it off on three sessions changed nothing (still 22 renderers).

Claude Model

Mixed (Fable 5.1 and Opus 5.5 sessions).

Is this a regression?

Unknown. Related but distinct reports: #79999 (single renderer CPU runaway, July build, stale) and #84013 (VS Code webview holds ~645 MB, closing sessions does not release it). This report is about many retained renderers for sessions that are not on screen, with idle CPU.

Claude Code Version

Desktop app 2.16120.0 (MSIX Claude_2.16120.0.0_x64), bundled Claude Code CLI 2.1.284 (%APPDATA%\Claude\claude-code\2.1.284\claude.exe).

Platform

Claude Desktop (Windows)

Operating System

Windows 11 Home 10.0.26200, 31 GB RAM, Ryzen 5 7600X.

Additional Information

I cannot attribute a specific renderer to a specific session from outside the app, so the "one renderer per visited session view" explanation is inferred from the spawn-time pattern plus the one-pane layout report. Happy to run anything else that would help pin it down, or to grab a chrome://tracing-style dump if there is a way to get one out of the desktop build.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗