Multiple concurrent Claude Code CLI sessions correlate with Windows Explorer shell crashes

What's Wrong?

Running many concurrent Claude Code CLI sessions (observed 13–14 claude.exe processes at once) on a Windows 11 machine correlates in time with Windows Explorer (shell) crashing repeatedly 3 times within 4 minutes (System Event Log, Event ID 1002, source "Application Hang", application userinit.exe, message: "The shell stopped unexpectedly and C:\Windows\system32\userinit.exe was restarted"). The machine becomes unresponsive during this; the user had to close applications one by one before the system stabilized.

What Should Happen?

Claude Code CLI sessions (especially idle/background ones) should not contribute to system-wide instability severe enough to crash the OS shell. Per-session RAM/resource usage should stay within reasonable bounds; if resource pressure occurs, the system should degrade gracefully rather than destabilize the shell.

Steps to Reproduce

1. Run 10+ concurrent Claude Code CLI sessions on Windows 11, each handling background/multi-agent tasks continuously for several hours.
2. Monitor system RAM — it climbs as session count increases.
3. At peak load, check Event Viewer → Windows Logs → Application, filter Event ID 1002 — observe userinit.exe "Application Hang"/shell restart occurring repeatedly in a short time window.

Is this a regression?

Not sure (no historical baseline available for comparison).

Claude Code Version

2.1.220

Platform

Not sure — reporter could not determine from the environment whether this is Claude Pro/Max (claude.ai) or API-key based usage.

Operating System

Windows 11 Pro (10.0.26200)

Terminal/Shell

Windows Terminal

Error Messages/Logs

Log Name: Application
Event ID: 1002
Source: Application Hang
Message: The shell stopped unexpectedly and C:\Windows\system32\userinit.exe was restarted.
Timestamps (same freeze episode): 16:29:40, 16:29:51, 16:33:32 (2026-08-09)

Additional Information

• A custom RAM auto-remediation mechanism (working-set trim + cache cleanup when RAM > 85%) was deployed on our side on 2026-08-06 — this reduced full-system "Hard Reset" events (Event ID 41) from 14/10 days to 0/3 days. However the shell-crash issue reported here is a different failure mode (Explorer/userinit, not a full hard reset) and still occurs under heavy load with many concurrent CLI sessions.
• No direct stack trace/crash dump from the claude.exe process itself — the current link is a time/load correlation, not proven causation. Reporting this so the engineering team can assess whether running many concurrent Claude Code CLI sessions places unusual pressure on the system (memory, handles, GDI objects, etc.) that could destabilize the shell.
• Additional evidence gathered the same day while investigating this issue: captured a real crash dump from an unrelated background PowerShell WinForms tray app (not part of Claude Code) — System.Management.Automation.PipelineStoppedException: The pipeline has been stopped at System.Windows.Forms.Form.OnShown(EventArgs e). The code already had a try/catch around the Add_Shown handler but still crashed — suggesting the pipeline was stopped externally, consistent with the "overall system resource pressure interrupting a child PowerShell process mid-execution" hypothesis, the same category of symptom as the Explorer/userinit crash above. No watchdog/script was found actively killing that process, pointing toward a systemic cause rather than that app's own logic bug.
• Related side-finding: while investigating, found another PowerShell process (not started by this reporting agent) independently running diagnostics on the exact same issue — reinforcing the concern in the companion report (Vietnamese IME focus-jump bug) that multiple Claude Code CLI sessions are operating independently, sometimes duplicating work without coordination.

---
Report prepared by a Claude Code CLI agent on the user's PC, based on Event Log evidence and direct observation, at the user's request (2026-08-09). Causation between concurrent Claude Code sessions and the shell crash is not proven — only a time/load correlation is claimed.