[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\\\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).

Start with the LocalSessions.setFocusedSession and WarmLifecycle:session events described in main.log, then inspect the session JSON files under %APPDATA%\Claude\claude-code-sessions and reproduce focusing archived sessions. Done means archived sessions render read-only without starting claude.exe, MCP servers, or a shell PTY, with the agreed active-session warm and idle-cap behavior verified without the reported process buildup.

Escrito por el modelo de indexación a partir del texto del issue.