[BUG] Desktop (Windows): clicking a session in the sidebar spawns its full CLI + MCP + shell stack, even for archived sessions; browsing 10 sessions ≈ 8 GB / 20+ python processes for 15–30 min

What's Wrong?

In Claude Code Desktop, focusing a session in the sidebar (LocalSessions.setFocusedSession) immediately "warms" it: the app spawns a full claude.exe (~340 MB), every user-scope stdio MCP server configured for that machine, a shell PTY, and then keeps all of it alive for the 900 s session idle timeout (1800 s for the preview lifecycle). This happens for archived sessions too, when the user only wants to read an old transcript.

On my machine each warm costs roughly: claude.exe 340 MB + Serena MCP (2 × python.exe, ~120 MB) + TypeScript language server started by Serena for TS repos (4 × node.exe, ~280 MB) + powershell.exe PTY + conhost (~80 MB) ≈ 800 MB.

Today I clicked through 10 sessions in about 90 seconds (8 of them archived since July/August). The app spawned 10 CLI stacks: 10 claude.exe, 20 python.exe, ~40 node.exe, 10+ powershell.exe, roughly 7–8 GB, on top of the ~2.5 GB Electron baseline. The machine crawled until the idle timeouts paused them 15 minutes later. There were no orphans; everything was reaped at the 900 s pause except the PTYs (separate issue).

A CliGovernor with a process cap and LRU eviction exists in the bundle, but it did not prevent 10 concurrent warms.

What Should Happen?

• Focusing an archived session should render the transcript read-only without spawning a CLI or MCP servers. Warm lazily on the first user input (or on un-archive).
• For active sessions, consider warming lazily on first input or hover-intent rather than on every focus, and/or a much shorter idle timeout for sessions that were warmed but never received input.
• Cap concurrent warm-but-idle CLIs (or expose the cap / warm behaviour as a setting), and surface memory pressure to the user.

Error Messages/Logs

%LOCALAPPDATA%\Claude\logs\main.log (times local, one focus → one warm → one PTY; ten in 28 s):

11:51:01 [CCD] LocalSessions.setFocusedSession: sessionId=local_c28c…
11:51:01 [CCD] Warming session local_c28c…
11:51:02 LocalSessions.startShellPty: sessionId=local_c28c…, cols=80, rows=24
11:51:09 [CCD] Warming session local_46ff…
11:51:09 [CCD] LocalSessions.setFocusedSession: sessionId=local_46ff…
11:51:10 LocalSessions.startShellPty: sessionId=local_46ff…
11:51:15 [CCD] Warming session local_edf7…
11:51:17 [CCD] Warming session local_78f9…
11:51:20 [CCD] Warming session local_9869…
11:51:21 [CCD] Warming session local_0549…
11:51:27 [CCD] Warming session local_5ad8…
11:51:28 [CCD] Warming session local_88e0…
11:51:28 [CCD] Warming session local_339d…
11:51:34 [warn] [event-loop-stall] main process blocked for 4687ms (... rss 429MB)
...
12:06:18 [WarmLifecycle:session] Idle timeout reached, disconnecting local_edf7…
12:06:18 [CCD] Pausing session local_edf7… (idle_timeout)
(… same for the other nine between 12:06 and 12:08 …)

Serena MCP logs (one per warmed session) confirm each warm started an MCP server and a TypeScript language server for the session's repo: 7 of the 10 pointed at the same repo, so 7 tsserver instances indexed the same codebase simultaneously.

8 of the 10 warmed sessions had isArchived: true in %APPDATA%\Claude\claude-code-sessions\<acct>\<org>\local_*.json.

Steps to Reproduce

1. Windows 11, Claude Desktop (MSIX) with the Code tab, at least one user-scope stdio MCP server configured in ~/.claude.json (I use Serena; any MCP server amplifies the cost).
2. Have ~10 sessions in the sidebar, several archived, in a custom group so they are visible.
3. Click through them one after another within a minute, just to look at them.
4. Watch Task Manager / Get-Process claude,python,node,powershell: one claude.exe + MCP servers + powershell.exe per clicked session, all still alive 10 minutes later. Memory grows by ~0.8 GB per click.

Claude Code Version

Desktop app 1.49585.0.0 (MSIX, Microsoft Store channel); bundled Claude Code 2.1.260 ([CCD] Initialized with version 2.1.260).

Platform

Claude.ai subscription (OAuth) via the desktop app.

Operating System

Windows 11 Pro 10.0.26200, 8 logical cores, 31.5 GB RAM.

Terminal/Shell

Desktop app (Code tab); session shell PTY is Windows PowerShell 5.1.

Additional Information

• Not a regression I can date: 26 launches since 2026-08-21 show 0 warms in the first 3 minutes; the burst correlates 1:1 with setFocusedSession events, not with launch.
• Related: shell PTYs started by the warm are not stopped at the idle pause (filed separately).