Claude Desktop leaves orphaned claude.exe CLI processes running for days after their session ends

Environment

• Claude Desktop app version: 1.20186.9 (Windows, WindowsApps package)
• Claude Code CLI version: 2.1.209
• OS: Windows 11 Home (10.0.26200)

Summary

After a Claude Code agent session (Cowork/agent-mode) finishes its work, the underlying claude.exe CLI process sometimes keeps running indefinitely — consuming several hundred MB of RAM each — even though the app's own session registry no longer considers that session active. Over a few days of normal parallel-session usage, these orphaned processes accumulate and cause noticeable system-wide memory pressure/slowdown.

Steps to observe

1. Use Claude Desktop's agent-mode/Cowork feature across several sessions/worktrees over a few days (in our case, ~19 claude/node processes accumulated over 2 days of normal use).
2. List real CLI session processes (excludes Electron helper processes like --type=renderer/gpu-process/utility/crashpad-handler, which are normal app overhead):

``powershell
Get-CimInstance Win32_Process -Filter "Name='claude.exe'" | Where-Object { $_.CommandLine -match 'stream-json' } |
Select-Object ProcessId, CommandLine
``

1. Compare against the app's own live session list (internal session-management surface) for which sessions are actually reported as running.

Observed (2026-07-16, ~8:45 PM local)

• 6 real CLI processes were running under the parent Electron process.
• Only 1 corresponded to a session the app itself reported as actively running.
• The other 5 processes had start timestamps from 2026-07-14, 2 days earlier — their sessions had already ended (in several cases the associated PR was already merged), yet the OS processes were still resident, together consuming roughly 1 GB of RAM.
• System memory: 15.8 GB total, only 5.1 GB free at the time — a meaningful fraction of the pressure traced directly to these orphaned processes.

Expected behavior

When a session ends (or is no longer tracked as active by the app's own session registry), its backing claude.exe process should be reaped by the supervisor promptly — not persist indefinitely with no indication to the user that it's still consuming resources.

Actual behavior

Orphaned CLI processes persisted for at least 2 days with no visible warning, and no setting or hook exists to reliably detect "this process's session has ended" from outside the app (confirmed: no Stop-hook field, env var, or PID reference distinguishes an ended/background session from an active interactive one).

Impact

On a machine that regularly runs multiple parallel worktree sessions (a documented, encouraged workflow), this leak compounds over days and degrades general system performance, requiring a manual Task Manager sweep to recover.

Suggested fix

Have the supervisor periodically reconcile live child claude.exe processes against its own session-active registry, and terminate/reap ones with no corresponding active session — rather than relying solely on the idle timeout (which, per current docs, didn't apply here or wasn't triggered for these processes).