[BUG] macOS: Cowork scheduled-tasks / local-agent-mode leak orphaned `claude` processes until app restart

Environment

• Surface: Claude desktop app (macOS), Cowork scheduled tasks + local agent mode (+ Cowork VM)
• Embedded Claude Code runtime: 2.1.181
• OS: macOS Tahoe 26.5.1 (Apple Silicon, 36 GB RAM)
• ~25 enabled scheduled tasks (cron + one-time); several high-frequency (every 30 min / hourly); several use local agent mode and MCP servers

What's wrong

Over a single overnight period, scheduler / local-agent-mode sessions spawned claude (embedded Claude Code) child processes that never exited. Dozens accumulated, each ~5-6% CPU continuously, several with 15 to 34 hours of accumulated CPU time. System load reached ~130; process count ~1,334 with ~12,700 threads. The Mac ran hot all night.

Quitting and reopening the Claude desktop app cleared every orphaned process and the machine cooled immediately. The processes were the Claude Code binary owned by the user (not malware).

Expected

When a scheduled-task / local-agent-mode session ends, the orchestrator should terminate that session's claude process and its entire MCP subprocess tree, and sessions should not accumulate across firings.

Actual

Sessions appear to hang and remain resident, accumulating until the app is restarted.

Evidence

• Activity Monitor pre-restart: 1,334 processes / 12,722 threads; dozens of claude processes at ~5-6% CPU; several with 15 to 34h CPU time.
• Energy tab: Claude desktop app "12 hr Power" approx 3,106 (about 43x the next app); "Preventing Sleep: Yes".
• After app restart: ~898 processes; remaining claude processes are healthy children of the freshly spawned orchestrator (near-zero CPU); the prior orphans are gone.
• main.log: many [CCDScheduledTasks] Spawning new session for scheduled task ...; ~895 spawn events; 11,000+ timeout lines; ~900 error lines.
• Cowork VM logs: repeated [Keepalive] Already running / VM already connected / Installing SDK loops.

Compounding factor not noted in the related issues

While running, the desktop app holds a continuous power assertion: NoIdleSleepAssertion named "Electron" (visible via pmset -g assertions). So the host never idle-sleeps while these orphaned sessions accumulate. The result is sustained overnight CPU, heat and energy draw rather than a machine that quiesces when unattended. This is what turned a process leak into "ran hot all night".

Steps to reproduce (likely)

1. Configure many scheduled tasks, including high-frequency ones (every 30 min) that use local agent mode + MCP servers.
2. Leave the desktop app running overnight.
3. Observe accumulating claude processes and rising system load; confirm they clear on app restart.

Related issues (cross-referencing the cluster)

This looks like the macOS counterpart of a known, partly-closed cluster, so filing it distinctly rather than as a comment on a Windows-scoped thread:

• #68394 (Windows, local-agent-mode sessions + MCP fleets not reaped) — same class, different OS.
• #62107 (Windows, Cowork scheduled tasks leave processes alive after completion) — closest mechanism.
• #33947 (macOS canonical, CLOSED) — orphaned MCP/subagent processes (PPID=1).
• #66280 (macOS, Task-subagent MCP leak, OPEN) — different trigger (Task subagents, not scheduled tasks).

Filing as a fresh macOS report because the canonical macOS issue (#33947) is closed and no open issue covers macOS Cowork scheduled-tasks + local-agent-mode. Happy to consolidate if maintainers prefer.

Questions

• Should scheduler-spawned sessions self-terminate (job-object-style containment / tree-kill on session end)? Is there a known leak when sessions time out?
• Can concurrent scheduled-task sessions be capped, and orphaned sessions auto-reaped?
• Should the NoIdleSleepAssertion be released when no session is actively running, so the host can idle-sleep overnight?