claude-code - 💡(How to fix) Fix [BUG] Scheduled task lastRunAt advances without skill execution — silent false-positive on macOS [3 comments, 4 participants]

Preflight Checklist

• I have searched existing issues and this hasn't been reported yet
• This is a single bug report
• I am using the latest version of Claude Code

What's Wrong?

Two scheduled tasks (rapport-hebdo-mail and backup-memoire-drive) show a recent and advancing lastRunAt timestamp — but their actual skill output (weekly report file, backup zip) has not been produced since 2026-04-24, across 3 consecutive weekly fire windows (2026-05-02, 2026-05-09, 2026-05-16).

This is distinct from #55378 where lastRunAt was not advancing. Here lastRunAt does advance (suggesting the scheduler recorded a fire), but the skill apparently never ran to completion — no output file, no notification, no error.

Environment

• Platform: macOS (Mac.lan, arm64)
• Claude Code version: 2.1.138
• Scheduled tasks: MCP-based (mcp__scheduled-tasks__*), cron weekly (Fridays)

Reproduction

1. Configure a scheduled task with a weekly cron expression
2. Verify the task runs successfully (output file created) for several weeks
3. Observe: after an indeterminate number of weeks, lastRunAt continues to advance at each scheduled fire window, but the skill output is no longer produced
4. No error message, no failed notification, no UI indication

Evidence

Task: rapport-hebdo-mail
Cron: weekly (Fridays)
lastRunAt: recent (2026-05-16 area)
Last actual output file: 2026-04-24 (3 Fridays ago)

Task: backup-memoire-drive  
Cron: weekly (Fridays)
lastRunAt: recent (2026-05-16 area)
Last actual backup zip: 2026-04-24 (3 Fridays ago)

What Should Happen?

• If lastRunAt advances, the skill should have executed and produced output
• If skill execution fails, lastRunAt should NOT advance, and the user should receive a failure notification
• The scheduler should never silently record a "run" that produced no output

Impact

Because lastRunAt looks healthy, there is no signal to the user that the tasks are broken. The issue was only discovered by manually checking output file timestamps — 25 days after the last real execution. A backup gap of 25 days went undetected.

Related Issues

• #55378 — similar silent-drop behavior, but lastRunAt was not advancing in that case
• #58357 — task did not fire at scheduled time (Windows)