macOS: scheduled-task sessions wedge mid tool-call (~30s in, WebSearch/WebFetch), stay "running" for days, and pin global concurrency slots until the whole schedule starves

## Environment

- Claude Desktop (macOS): 1.32352.1 (note: an auto-update had been staged by ShipIt but the app was not relaunched during the incident window)
- Bundled Claude Code runtime: 2.1.229 (`~/Library/Application Support/Claude/claude-code/2.1.229`)
- macOS: Darwin 25.6.0 (26.6.2), Apple Silicon
- Feature: Desktop scheduled tasks (local agent mode) — ~30 tasks, a mix of daily/weekly crons and one-time `fireAt` tasks

## Summary

Sessions spawned by scheduled tasks sometimes die **~30 seconds in — the transcript ends mid `WebSearch`/`WebFetch` tool call with no final assistant message** — but the session stays marked "running" indefinitely (observed up to 5 days). Each wedged session permanently holds one slot of the scheduler's global concurrency cap. With 2–3 wedged at once, every other task is refused (`recordedSkips` reason `global_limit`, retried ~every 60s) and the **entire schedule starves for days**.

This is distinct from #88982 (session *completes normally* but the process never exits → resource leak): here the session never completes at all — the agent loop dies mid tool-call and nothing reaps it. The downstream effect (frozen sessions pinning scheduler concurrency slots) matches what #87263 reports on Windows via a different trigger.

## Evidence (4 instances, Aug 19–23)

| Session | Created | Last activity | Observed state |
|---|---|---|---|
| one-time task A | 2026-08-19T12:30:54Z | 12:31:23Z (**29s**) | still "running" on Aug 24 (5 days); transcript ends mid-`WebFetch` |
| one-time task B | 2026-08-20T20:23:15Z | 20:23:45Z (**30s**) | still "running" on Aug 24; transcript ends mid-`WebSearch`/`WebFetch` |
| daily task, run 1 | 2026-08-19T09:03Z | — | stayed alive until 08-23T19:03Z (~4 days) |
| daily task, run 2 | 2026-08-20T08:20Z | — | stayed alive until 08-23T19:03Z (~3 days); a third run (created 08-23T11:12Z) wedged again, idle from 11:23Z |

Scheduler state (`~/Library/Application Support/Claude/claude-code-sessions/*/*/scheduled-tasks.json` → `recordedSkips`): near-continuous `global_limit` refusals from 2026-08-21T00:02Z through 08-24, thousands of skip events at the ~60s retry cadence. Concrete casualties: a daily 09:30 task missed 3 consecutive days, a nightly task missed 2 nights, a weekly Saturday task ran ~48h late, and a 3-hourly task stopped firing entirely.

## Workaround (verified)

Archiving the wedged session (session management → archive, which stops the session's process) **releases the slot immediately**: within 60–90 seconds of archiving the three wedged sessions, the starved queue began draining (two tasks fired at 07:10:55Z, a third at 07:11:55Z) and cleared serially. No app restart was needed.

## Suggested fixes

1. A session whose agent loop dies mid tool-call should be terminated/reaped, not left "running" holding a slot.
2. A per-run timeout or liveness watchdog for scheduled-task sessions (no transcript activity for N minutes → reap and release the slot).
3. Surface the concurrency cap and the `global_limit` / `per_task_limit` skip reasons in the UI (today they are only discoverable by reading `recordedSkips` directly), and consider making the cap configurable.

Related: #88982 (macOS, completes-but-never-exits leak) · #87263 (Windows, frozen sessions pin scheduler slots) · #68106 (older slot-exhaustion via permission hangs).

Start with the scheduled-tasks.json files under ~/Library/Application Support/Claude/claude-code-sessions/*/*/ and inspect the recordedSkips entries alongside the session state. Reproduce or trace a scheduled task that ends mid-WebSearch/WebFetch while remaining running, then compare archiving the session with normal completion. Done means wedged runs are reaped and their global concurrency slots are released without manual archiving.

由索引模型根据 Issue 内容生成。