Scheduled tasks: lastRunAt never updates while nextRunAt keeps advancing (task silently never executes)

Draft issue for https://github.com/anthropics/claude-code/issues (not posted — for your review)

Title: Scheduled tasks: lastRunAt never updates while nextRunAt keeps advancing (task silently never executes)

Body:

Summary: A scheduled task (15-minute cadence) has its nextRunAt field advance normally on
every cycle, but lastRunAt never populates — suggesting the task is being silently skipped
rather than executed, with no error surfaced anywhere.

Environment: Claude Code CLI, scheduled-tasks MCP subsystem, Windows 11.

Steps to reproduce / observed behavior:

1. Created a recurring scheduled task with cronExpression: "*/15 * * * *".
2. Called list_scheduled_tasks repeatedly over several hours (real UTC timestamps confirmed via

date -u before each comparison, to rule out checking before the fire window arrived).

1. nextRunAt reliably advances by one 15-minute step each cycle (confirmed across three

independent checks spanning 19:33:33Z → 19:48:33Z → 21:18:33Z).

1. lastRunAt has never appeared in any snapshot for this task, across the entire

observation window (multiple hours).

Expected behavior: lastRunAt should update to a real timestamp after each successful
execution, or the task should surface an error/warning if it's failing to execute.

Actual behavior: Silent non-execution with no error signal. The only way to detect this was
comparing two time-verified snapshots and noticing lastRunAt's absence didn't change.

Additional context: on the same day, several other scheduled tasks on this host
(agent-reporting-daily, finops-verify-layer-daily, security-baseline-daily) were separately
observed with suspiciously near-identical lastRunAt timestamps despite different nominal cron
schedules — a possible "stall-then-batch-fire" pattern, i.e. the scheduler catching up on a
backlog all at once rather than firing each task on its own schedule. Not independently
re-verified in this specific investigation, but worth checking if related.

Impact: for a task whose entire purpose is monitoring something else and alerting on change
(in this case, a production status watchdog), a silent stall means the monitoring itself provides
false assurance — no alerts fire, but not because everything is fine.

---
*This draft was prepared by a Claude Code session investigating host performance issues on
2026-08-26. Feel free to edit before posting, or discard if this isn't the right venue.*