Scheduled tasks stop executing fleet-wide — nextRunAt advances while lastRunAt freezes silently (~44h, restart does not fix)

Summary

The scheduled-tasks execution layer (tasks created via create_scheduled_task, listed via list_scheduled_tasks, stored under ~/.claude/scheduled-tasks/<taskId>/SKILL.md) has stopped firing every enabled task, fleet-wide, for ~44.4 hours and counting as of this report (last refreshed 2026-08-10T09:03:28Z). nextRunAt keeps mechanically advancing on schedule, but lastRunAt is frozen at each task's last real execution — the tasks are not actually running.

This is on macOS (Darwin 25.6.0), via Claude Code CLI.

Failure signature

For a healthy task, lastRunAt should advance to a new timestamp each time nextRunAt is reached. Instead:

• nextRunAt advances normally and looks current at every check.
• lastRunAt stays pinned to the timestamp of the last time the task genuinely executed.
• No error, warning, or other surfaced signal anywhere (task list, task output, session) indicates anything is wrong — the only way to detect it is to compare lastRunAt against wall-clock time across repeated checks.

This is a dangerous failure mode specifically because nextRunAt — the field that looks like a liveness signal — is useless for detecting it. It advances identically whether the task fired or not.

Timeline (all times UTC)

• 2026-08-08 ~12:42 — first observed: an enabled recurring task's lastRunAt stops advancing. Initially indistinguishable from a one-off miss.
• 2026-08-08 13:53 — a one-shot, no-tool probe task (single fixed reply, no file/tool access) is scheduled for exactly this time as a clean falsifier — a one-shot task cannot mask a miss by "rolling forward" the way a recurring task's nextRunAt can.
• 2026-08-09 ~22:02–22:10 — four separate enabled tasks (differing cadences: hourly, 3-hourly ×2, 6-hourly) suddenly show lastRunAt values within ~8 minutes of each other, and three of those four within the same second down to the millisecond. This looked like recovery at first glance.
• 2026-08-09, between the above and the next check — an app restart was performed (unrelated troubleshooting step, already in progress) around this window.
• 2026-08-10 ~04:37, ~08:55, and again ~09:03 — rechecked the same four tasks three separate times. All four show the exact same lastRunAt values as the original 22:02–22:10 check, byte-for-byte, unchanged, across all three rechecks spanning 6 to 11 hours later. Given their distinct cadences (hourly, 3h, 3h, 6h), a genuinely-recovered scheduler would have produced at least one new timestamp on at least one of them by now. It has not, across four independent checks. This confirms the 22:02–22:10 cluster was a single synchronized replay/backfill artifact (most plausibly tied to the app restart) rather than the scheduler resuming real independent execution.
• As of this report (2026-08-10T09:03:28Z): still fully frozen, no further movement since the false-recovery burst, ~11 hours ago now.

Evidence: task-by-task state as of 2026-08-10T09:03:28Z

| Task cadence | Last genuine fire (lastRunAt) | Elapsed since | Expected fires missed |
|---|---|---|---|
| Hourly | 2026-08-09T22:02:58.873Z | ~11.0h | ~11 |
| 6-hourly | 2026-08-09T22:02:58.866Z | ~11.0h | ~1–2 |
| 3-hourly (A) | 2026-08-09T22:02:58.858Z | ~11.0h | ~3 |
| 3-hourly (B) | 2026-08-09T22:10:56.316Z | ~10.9h | ~3 |
| 30-minute | 2026-08-08T07:10:37.589Z | ~49.9h | ~99 |
| One-shot, no-tool probe (fireAt 2026-08-08T13:53:00Z) | never fired | ~43.2h past scheduled fire | 1 of 1 |

The one-shot no-tool probe is the cleanest signal in this table: it requires no tool calls, no file access, nothing but returning a fixed string, and it has still never executed 43 hours past its scheduled time. There is no plausible permissions or environment explanation for a task that does nothing but reply with a literal string failing to run — this points at the dispatch/execution layer itself, not at anything task-specific.

What's been tried

• App restart: performed once during the outage window. Result: produced the synchronized lastRunAt burst described above (multiple unrelated tasks stamping near-identical timestamps within the same second), then reverted to complete silence. This reads as the restart flushing/replaying some queued or cached state exactly once, not as the scheduler resuming normal operation. This is a confirmed non-remedy — please don't suggest restart-and-see as a next step; it's already been tried and the before/after lastRunAt comparison above shows it didn't help.

Impact

Every workflow relying on mcp__scheduled-tasks for recurring, unattended execution (health checks, periodic digests, watch loops) has been silently non-functional for ~44 hours. Because the failure is silent (no error surfaced anywhere) and nextRunAt looks normal, this is easy to miss without actively cross-checking lastRunAt against wall-clock time — which is not something the tool surfaces as a warning on its own.

Ask

• Confirm whether this is a known incident on the scheduled-tasks execution backend.
• If there's a way to force a genuine (not replayed) execution to test recovery, that would help distinguish "still fully down" from "recovering slowly."
• Consider surfacing a warning (in list_scheduled_tasks output, or elsewhere) when lastRunAt has fallen far behind what nextRunAt's cadence implies it should be — right now this class of failure is invisible unless someone happens to diff two snapshots by hand, which is how this was caught.

Happy to provide more detail (exact task IDs, full historical snapshots at each checkpoint) if useful — omitted here since they're specific to our internal task names.