[BUG] Claude Desktop (Windows): sessions + dynamic workflow + warm previews exhaust RAM and freeze the whole system; memory governor only evicts idle sessions ("evicted 0 of 0")

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Claude Desktop on Windows drives a 32 GB laptop into sustained memory thrashing and whole-system freezes when several Claude Code sessions, a dynamic workflow and warm preview dev servers run at the same time, and the app's own memory governor cannot reclaim anything because it only evicts idle sessions.

Since installing Claude Desktop on 2026-10-07, %LOCALAPPDATA%\Claude\logs\main.log records [CliGovernor] memory pressure (critical) 10–78 times per day and [event-loop-stall] main process blocked for N ms stalls of 8–340 seconds, each coinciding with a critical entry. On 2026-10-13 the machine hard-froze twice (power-button reset; Windows Kernel-Power 41, bugcheck 0) while 5–7 sessions were running, and again at 13:45 with 5 sessions + one dynamic workflow + 2–3 preview dev servers (wf-preview, chat-preview). Task Manager at that moment (99% RAM, disk 100%) showed 16 separate "Node.js JavaScript Runtime" processes at 150–240 MB each plus "Claude (21)". After killing and restarting the app, all 16 node processes disappeared and system memory fell from 99% to ~40%.

Contributing behaviors visible in the log:

1. [CliGovernor] memory pressure (critical): evicted 0 of 0 idle session(s), 7 effective — when the pressure comes from active sessions/agents the governor does nothing.
2. Dynamic workflows are on by default on paid plans; after one "Always" in auto mode (skipWorkflowUsageWarning: true) they start without a prompt, with the default cap of 16 concurrent agents — far too many for a laptop that also runs an IDE and a browser.
3. [WarmLifecycle:preview] Warming up session … keeps firing while pressure is critical, and preview dev servers stay alive for the 30-minute idle timeout after the task is done.
4. The desktop UI shows no per-session memory / child-process information and has no setting for max concurrent sessions, agents or previews.

This is not the GPU-process crash from #81836 / #90374 (zero GPU process gone entries in main.log) and not #29045 (the Cowork VM was not running).

What Should Happen?

• When the app detects critical memory pressure it should stop spawning new workflow agents / subagents and stop warming previews, pause running workflows, and show a banner — instead of logging "evicted 0 of 0 idle" and carrying on.
• The default concurrent-agent cap should scale with available RAM (or default to ~4 on client machines) instead of a flat 16.
• Preview dev servers should stop when a session's turn ends, or at least be visible with a Stop control, instead of lingering for 30 minutes.
• The sidebar should show per-session RSS (CLI + children), and settings should expose max concurrent sessions / agents.
• The app's own background work should never drive the machine into multi-minute stalls or a hard freeze.

Error Messages/Logs

# main.log, 2026-10-13 morning (7 sessions)
10:46:54 [warn] [CliGovernor] memory pressure (critical): evicted 0 of 0 idle session(s), 7 effective
10:49:43 [warn] [event-loop-stall] main process blocked for 22519ms [likely sleep: duration_heuristic]
10:50:23 [warn] [event-loop-stall] main process blocked for 42218ms [likely sleep: duration_heuristic]
10:50:43 [warn] [CliGovernor] memory pressure (critical): evicted 0 of 0 idle session(s), 7 effective
10:51:04 [warn] [event-loop-stall] main process blocked for 10105ms [likely sleep: duration_heuristic]
# Windows: unexpected shutdown ~10:52 (Kernel-Power 41, bugcheck 0), boot 11:01; second one ~11:27-11:49, boot 11:50

# main.log, 2026-10-13 afternoon (workflow + previews)
13:23:34 [info] [CCD] Session local_... workflow ... started
13:24:02 [warn] [CliGovernor] memory pressure (critical): evicted 0 of 0 idle session(s), 3 effective
13:29:49 [info] [Launch] Updating active servers store { count: 2, servers: ... "wf-preview", port 27899 ... "chat-preview", port 27999 ... }
13:37:33 [warn] [CliGovernor] memory pressure (warning): evicted 0 of 0 idle session(s), 5 effective
13:41:37 [info] [WarmLifecycle:preview] Warming up session local_...
13:45:03 [warn] [CliGovernor] memory pressure (critical): evicted 0 of 0 idle session(s), 5 effective
13:45:44 [warn] [event-loop-stall] main process blocked for 3595ms (task none, total 12, cumulative 13079ms, rss 17MB)
13:46:19 [warn] [event-loop-stall] main process blocked for 4992ms (task memory:snapshot:interval=4221ms, total 21, cumulative 28287ms, rss 8MB)
13:50:27 [info] Starting app   <- user killed and restarted the app

# Daily counts since install: memory pressure (critical) / main-process stalls >= 5 s / longest stall
10-07: 34 / 3 / -
10-08: 47 / 9 / 35 s
10-09: 78 / 14 / 158 s, 205 s
10-10: 50 / 8 / 149 s
10-11: 15 / 4 / -
10-12: 48 / 27 / 340 s, 126 s
10-13: 10 (by noon) / 9 / 42 s

Steps to Reproduce

1. Windows 11 laptop with 32 GB RAM running a normal dev workload: Chrome with ~30 tabs, one JetBrains IDE, ChatGPT desktop (about 15–18 GB in use before Claude).
2. In Claude Desktop (Code tab), open 4–5 sessions on projects that have a dev server (npm run dev), and in some of them use the preview / browser pane so a dev server gets started.
3. In one session trigger a dynamic workflow (type ultracode or ask for a workflow). After a previous "Always" in auto permission mode the run starts without any prompt.
4. Watch Task Manager and %LOCALAPPDATA%\Claude\logs\main.log.

Result: Available memory drops below 2 GB, main.log logs memory pressure (critical): evicted 0 of 0 idle session(s) repeatedly, the main process logs event-loop stalls of several seconds to minutes, the whole system stops responding (hard page faults > 1,500/s), and twice the laptop had to be power-cycled. Restarting the app kills the node child processes and memory recovers immediately.

Workarounds that help: "workflowSizeGuideline": "small" plus "env": {"CLAUDE_CODE_WORKFLOW_MAX_CONCURRENT_AGENTS": "2"} in ~/.claude/settings.json, and keeping at most 2–3 running sessions.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

2.1.295 (Claude Code), bundled in Claude Desktop 2.31226.1.0 (MSIX)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

• Hardware: Lenovo ThinkBook 14 G6+ AHP (21LF), Ryzen 7 8845H, 32 GB LPDDR5 (27.8 GB usable; 4.2 GB reserved by the Radeon 780M iGPU), SK Hynix 1 TB NVMe.
• OS: Windows 11 Home 25H2, build 26200.9550.
• Permission mode: auto. Workflows were allowed once with "Always" (skipWorkflowUsageWarning: true in settings.json).
• The pagefile was a 56 GB fixed file, so Windows never raised a low-memory error; the system just thrashed (ESENT / event logs show 27–31 s write stalls during these periods).
• The desktop app does run a per-session memory governor, but its only action is evicting idle sessions, which were always 0 during these events.
• Related: #85104 looks like the macOS counterpart (WarmLifecycle spawning children with no memory backpressure); #89679 (Windows freeze-then-vanish). This report adds the Windows evidence plus the dynamic-workflow / 16-concurrent-agent and preview-dev-server angle.
• Full main.log (7 MB) and Windows event-log excerpts are available on request.