[BUG] [Windows] Local Routines leak orphaned claude.exe processes over time — RAM grows unbounded and app reports phantom active sessions blocking clean shutdown

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?

Using a Local Routine (Desktop scheduled task) in the Code tab of Claude Desktop on Windows, triggered hourly. After leaving the app running for an extended period, memory usage grows continuously and is never reclaimed until the app is fully closed and relaunched.

Measured via PowerShell after ~1.5 days (36 hours) of uptime with an hourly-triggered Local Routine:

Get-Process claude | Measure-Object WorkingSet64 -Sum | Select-Object Count, @{n='TotalMB';e={[math]::Round($_.Sum/1MB,1)}}

Result: 34 separate claude.exe processes, ~7.5 GB (7506 MB) combined working set. This is consistent with roughly one orphaned process left behind per Routine run (36 expected hourly triggers over 1.5 days vs. 34 observed processes).

Separately: when attempting to close the Claude Desktop app, it displays a warning that 8 sessions are currently running and blocks/warns before closing — even though the Local Routine had already been disabled beforehand and there was no visible active session, chat, or Routine run in progress at the time. This suggests the app's internal "active session" count is not being decremented when a Routine run actually finishes.

<img width="679" height="178" alt="Image" src="https://github.com/user-attachments/assets/b635d372-cfa9-4a08-925d-8dc1a5d207a0" />

What Should Happen?

• When a Routine run completes, its worker process should fully exit and release its memory back to the OS.
• Steady-state memory usage should stay roughly constant regardless of how many Routine runs have fired over time.
• The app's "sessions running" count (used in the close-confirmation dialog) should reflect actual active sessions, and should not block/warn about closing when no Routine is currently executing and nothing is visibly active.

Error Messages/Logs

On close, a dialog reports that 8 sessions are running and asks for confirmation before closing, despite the automatic Routine being disabled and no active session visible in the sidebar. Attaching a screenshot of this dialog (exact wording not transcribed here).

Steps to Reproduce

1. Open Claude Desktop (Windows) → Code tab → Routines.
2. Create a new Local routine (Desktop scheduled task) with an hourly trigger.
3. Leave the Claude Desktop app open and running, without closing it, for an extended period (~1.5 days / 36 hours in my case).
4. At any point, run in PowerShell:

Get-Process claude | Measure-Object WorkingSet64 -Sum | Select-Object Count, @{n='TotalMB';e={[math]::Round($_.Sum/1MB,1)}}
Observe that process Count and TotalMB climb steadily and never decrease on their own (34 processes / 7506 MB after ~1.5 days).

1. Disable the Local routine so no further runs are scheduled, and confirm no session is currently active in the app's sidebar.
2. Attempt to close the Claude Desktop app. It reports 8 sessions still running and warns before closing, despite no visible active session.
3. Force-close the app and relaunch it. Get-Process claude returns to a normal baseline, confirming the accumulated processes were not doing any actual work.

Note: reproduction requires extended runtime (hours to days), not immediate.

Claude Model

Opus

Is this a regression?

I don't know

Last Working Version

I don't know

Claude Code Version

Claude 1.17377.2 (e0ea9e) 2026-07-01T05:51:58.000Z

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Possibly related to anthropics/claude-code#62107, which reports a similar accumulation of orphaned claude.exe processes from Cowork scheduled tasks on Windows. Since Cowork Scheduled Tasks and Local Routines reportedly share the same local execution engine, this may be the same underlying root cause surfacing on a different product surface (Routines tab vs. Cowork).

Notably, my numbers closely match a ~1:1 leak rate: hourly trigger × 1.5 days ≈ 36 expected runs vs. 34 observed leaked processes.

Happy to provide additional diagnostics (Task Manager screenshots, more Get-Process samples over time, etc.) if useful.