Windows: Claude Desktop leaves orphaned renderer/Node-utility/CLI-engine processes after tasks complete; app won't relaunch after close without a full Windows restart

Summary

Two related process-lifecycle issues on Windows, both currently active:

1. Claude Desktop leaves a large number of orphaned renderer / Node utility-service / CLI-engine processes running after conversations and background tasks complete. They are never cleaned up, and RAM usage climbs continuously even shortly after a fresh restart of both Windows and the app.
2. After closing Claude Desktop, relaunching it via the taskbar/desktop icon does nothing — the app does not reopen. Only a full Windows restart brings it back. This has reportedly been raised and addressed before, but has recurred. The same "won't relaunch, needs a full Windows restart" pattern is also observed with other child processes the app spawns (Node.js and PowerShell windows/popups).

Environment

• OS: Windows 11 Home Single Language, build 10.0.26200
• Claude Desktop app: Claude_1.24012.9.0_x64__pzs8sxrjxfjjc (Microsoft Store / WindowsApps package)
• Claude Code CLI: 2.1.219 (see version-mismatch finding below)
• Total physical RAM: 15.7 GB

Issue 1 — orphaned process accumulation

Observed 51 claude.exe processes alive simultaneously, ~53 minutes after the machine and the app were both freshly restarted (all 51 processes were under 53 minutes old — none older, confirming this accumulated from a clean start, not long-term drift).

Breakdown by process type (via Get-CimInstance Win32_Process):

| Count | Type | Notes |
|---|---|---|
| 1 | main app process | expected baseline |
| 1 | --type=gpu-process | expected baseline |
| 1 | --type=crashpad-handler | expected baseline |
| 1 | --type=utility --utility-sub-type=network.mojom.NetworkService | expected baseline |
| 1 | --type=utility --utility-sub-type=audio.mojom.AudioService | expected baseline |
| 1 | --type=utility --utility-sub-type=video_capture.mojom.VideoCaptureService | expected baseline |
| 19 | --type=renderer | far beyond what a single open window should account for |
| 16 | --type=utility --utility-sub-type=node.mojom.NodeService | Electron Node.js utility processes — appear to be spawned per conversation/task and not torn down on completion |
| 9 | claude-code\<version>\claude.exe --output-format stream-json --input-format stream-json ... | the actual CLI engine processes |

Total resident memory across all 51 processes: ~7.1 GB (45% of total system RAM), on a machine where the built-in RAM-pressure handling could not intervene because none of the processes were old enough to be considered safely closeable.

Version-mismatch finding (likely root cause signal): of the 9 CLI engine processes, 8 were running claude-code\2.1.219\claude.exe and 1 was still running the previous version, claude-code\2.1.217\claude.exe. This indicates an in-session auto-update to 2.1.219 occurred without terminating the pre-update engine process for at least one active conversation/task, leaving it running indefinitely alongside the new version.

Hypothesis: each conversation or background task (subagent dispatch, parallel tool run, etc.) spawns its own renderer + Node utility-service + CLI-engine trio, and these are not being terminated when the conversation/task finishes — only a full app restart clears them.

Issue 2 — app fails to relaunch after close; requires full Windows restart

After fully closing Claude Desktop (via the app itself or Task Manager), clicking the icon to reopen it does nothing — no window, no visible process, no error. The only way to get the app running again is a full Windows restart. This same symptom — a process that won't relaunch after being closed until Windows is restarted — is also seen with Node.js and PowerShell windows/popups that Claude Desktop spawns as children (e.g., hook/tool-invoked processes).

This suggests something is left in a stuck/locked state on close (e.g., a single-instance mutex/lock, a named pipe, or a leftover handle) that prevents a clean relaunch, and that this affects not just the main app but the child process types it spawns.

Noted: this specific relaunch problem has apparently been reported before and was thought to be fixed, but it has recurred.

Reproduction

1. Fresh Windows restart, then start Claude Desktop.
2. Use the app normally for under an hour, including some background/parallel task or subagent activity.
3. Check Get-Process claude / Task Manager — process count and total memory climb well beyond what a single open window should require, and stay elevated even when idle.
4. Separately: close the app fully, then try to reopen it via its icon — it does not reopen until Windows itself is restarted.

Impact

RAM exhaustion within roughly an hour of a clean restart, with no user-facing way to reclaim it short of restarting the whole app (for issue 1) or the whole OS (for issue 2).