Cowork scheduled tasks on Windows leave claude.exe processes alive after completion, causing memory accumulation

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?

Note: this report is about Claude Cowork (research preview, Windows desktop), not the Claude Code CLI. Filing here because Cowork is built on Claude Code / Agent SDK infrastructure and there's no dedicated Cowork repo.

On Windows, Cowork scheduled tasks appear to leave their claude.exe worker processes alive after the task prompt finishes. Over time these accumulate and consume significant RAM and committed memory. Manually killing all claude.exe processes fully reclaims the memory, confirming none of them are still doing useful work.

After ~24 hours of operation with several active schedules I observed:

• 16 claude.exe processes alive simultaneously
• ~4.3 GB total working set across those processes
• Process start times spanning the previous 24 hours, no gaps corresponding to task completions
• Killing every claude.exe reclaimed ~7.7 GB committed and ~3 GB physical RAM in one shot
• Same leak does not occur from interactive chat sessions — only scheduled-task invocations

Diagnostic detail: each claude.exe and its descendants (Node MCP host, child shells) live in a Windows Job Object with LimitFlags = 0x3C00 (DIE_ON_UNHANDLED_EXCEPTION | BREAKAWAY_OK | SILENT_BREAKAWAY_OK | KILL_ON_JOB_CLOSE). The KILL_ON_JOB_CLOSE flag means the OS would reap the whole job once the job handle is released — so the leak is upstream of the OS: something in Cowork's scheduled-task lifecycle is keeping the worker claude.exe (and therefore the job handle) alive after the task prompt has returned.

What Should Happen?

When a Cowork scheduled task finishes executing its prompt, the claude.exe worker process that was spawned for that task should exit and release its memory back to the OS. The steady-state claude.exe process count and total memory footprint should remain roughly constant regardless of how many scheduled tasks have fired over the previous day.

Error Messages/Logs

No error is surfaced by Cowork — the leak is silent. The only observable signal is external: the `claude.exe` process count grows over time and total working-set/committed memory climbs into the multiple-GB range.

Observed snapshot from `Get-Process claude`:
- 16 processes alive at once after ~24 h
- Earliest process start time matched the start of the day; newest matched the most recent scheduled-task invocation
- After killing all `claude.exe` processes and letting Cowork relaunch normally: 10 fresh processes, ~2.2 GB total — i.e. 16 - 10 = 6 truly orphaned workers carrying ~2 GB of dead weight.

Steps to Reproduce

1. On a Windows machine running Cowork, configure several scheduled tasks at different cron intervals — for example one every 30 minutes, one hourly during business hours, one daily early-morning, and one weekly. Five to ten tasks is enough to show the pattern clearly.
2. Let the machine run uninterrupted for 12 to 24 hours.
3. Periodically run Get-Process claude in PowerShell and track the process count and total working-set memory:

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

1. Observe that the process count grows monotonically over time and total memory climbs. Expected: roughly flat. Observed: linear growth in both.
2. Confirm the leak is on Cowork's side, not the OS, by killing every claude.exe process (Get-Process claude | Stop-Process -Force) — the memory is reclaimed immediately and the next normal Cowork launch returns to a small steady-state footprint.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

Claude for Windows build 1.8555.2 (a476c3)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

PowerShell

Additional Information

Current workaround

A daily scheduled kill of all claude.exe processes restores normal memory usage. Not ideal as a long-term solution because it briefly interrupts any in-progress interactive session and forces a relaunch.

Suggested investigation

• Verify the scheduled-task runner is awaiting the completion handler and exiting the worker claude.exe after the task prompt returns.
• Check whether errors during MCP server teardown (e.g., a connector tool failing to disconnect cleanly, or an MCP child still doing I/O) prevent the worker from exiting and leave the process spinning idle. Several of my scheduled tasks talk to MCP servers (Microsoft 365, CRM, local desktop shell) and the leak rate seems proportional to how many tasks invoke MCP tools.
• Consider an idle-timeout safety net: if a scheduled-task worker has been alive for more than N minutes past its prompt completion, terminate it.

Impact

For users running several Cowork scheduled tasks on a workstation, this silently consumes several GB of RAM per day. On lower-spec laptops this is enough to noticeably degrade overall responsiveness within a day or two of normal use.