Claude Desktop’s Orphaned Scheduled Tasks Are an Agent Control-Plane Bug, Not a Fan-Noise Bug
The easiest way to underestimate desktop agents is to watch the UI instead of the process table. A scheduled task looks harmless when it is a little item in a sidebar. It looks different when the machine wakes up with more than a thousand processes, a load average north of reasonable, and a fleet of orphaned claude children quietly turning a laptop into infrastructure.
A new Claude Code issue reports exactly that class of failure in Claude Desktop scheduled tasks and local-agent-mode sessions. The reported numbers are not subtle: roughly 1,334 processes, 12,722 threads, system load around 130, repeated task timeouts, and a Claude desktop app 12-hour power score around 3,106 — about 43x the next app. The user says dozens of claude child processes remained overnight at roughly 5–6% CPU each, with several accumulating 15 to 34 hours of CPU time.
That is not a fan-noise bug. It is a control-plane bug.
The reported setup was macOS Tahoe 26.5.1 on Apple Silicon with 36 GB RAM, Claude Desktop scheduled tasks, local agent mode, Cowork VM, and Claude Code runtime 2.1.181. The user had about 25 enabled scheduled tasks, including cron and one-time jobs. Some fired every 30 minutes or hourly. Several used local agent mode and MCP servers. Logs reportedly contained around 895 scheduled-task spawn events, more than 11,000 timeout lines, and about 900 error lines. Cowork VM logs allegedly repeated keepalive, already-connected, and SDK-install loops.
Restarting the app reduced the reported process count from 1,334 to about 898, and healthy child processes dropped near zero CPU. That before/after matters because it points away from “the user was running a heavy task” and toward lifecycle ownership: children were launched, but not reliably finished, cancelled, or reaped.
Background automation is a job runner now
The duplicate history makes the issue more than one noisy laptop. The linked reports include earlier claims of 50–75+ orphan subprocesses consuming 1.6–3 GB memory, roughly 114 zombie claude processes consuming around 17 GB RAM after 24 hours, and local-agent-mode spawn_task sessions busy-looping at 94–99% CPU for more than 44 hours. Those reports span scheduled tasks, desktop subprocess runners, local-agent mode, and Cowork/spawn-task surfaces. That pattern is the story.
Once an app can launch autonomous work on a schedule, it has crossed into job-runner territory. Job runners need boring machinery: concurrency limits, wall-clock deadlines, output-stall watchdogs, process groups, cancellation propagation, health checks, backoff, child reaping, and operator-visible state. Without those, every “small” scheduled agent becomes a durable resource leak waiting for the right timeout path.
Agents make the failure mode worse because they bring dependencies. A scheduled task may open MCP server connections, browser sessions, local VMs, repository checkouts, credential handles, and network retries. If the parent thinks the task timed out but the child keeps spinning, the blast radius is not just CPU. The process may still hold credentials, keep a filesystem handle open, consume tokens, prevent sleep, or continue acting against a workspace the user assumes is idle.
The energy-tab detail is important for product trust. “Preventing Sleep: Yes” plus orphaned agents changes the operational contract. A desktop app that looks like a productivity tool becomes a background service with uptime, power, and cost implications. If it cannot explain what is running and why, users will eventually treat it like unmanaged infrastructure. They will be right.
What practitioners should do before trusting scheduled agents
If you are using Claude Desktop scheduled tasks today, keep the task count low until you have observed cleanup over multiple cycles. Avoid high-frequency cron jobs that run every 30 minutes unless you have checked Activity Monitor or ps after several executions. Watch for orphaned claude processes, unexpected CPU, rising thread counts, and tasks that time out but leave children alive. Restart the app if process counts climb, but do not mistake restart-as-cleanup for a reliable operating model.
Do not run scheduled desktop agents with broad permissions or production credentials on a laptop you do not monitor. If a task needs reliability, use a real scheduler with logs, resource limits, alerts, and explicit credential scoping. Desktop scheduling is convenient for personal automation. It is not automatically a production orchestrator because the model on the other end is impressive.
For teams evaluating Claude Code against Codex, Cursor, or other agents, add lifecycle tests to the checklist. What happens when a task completes normally? When it times out? When an MCP server hangs? When a child process wedges? When the app restarts? When the machine sleeps and wakes? When the network drops? When logs rotate? When credentials expire? The answers matter more than another polished demo of an agent editing a file.
For vendors, the product requirement is almost embarrassingly old-fashioned: show me what is running, what authority it has, how long it has been running, how much it is costing, and how to kill it safely. The user should not need to reverse-engineer process trees to understand their automation. A scheduler without visible state is not a feature. It is a leak with a calendar.
The hidden operations bill of desktop agents is arriving early. Launching agents is easy. Owning their lifecycle is the product.
Sources: Anthropic Claude Code issue #69851, Claude Code changelog, Claude Code security documentation