[BUG] Cowork scheduled-task system silently dropping fires (recurring crons skipped on weekends, now bleeding into weeknights)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Note: This bug is about Cowork mode in the Claude desktop app (the scheduled-task system, mcp__scheduled-tasks__*), not the Claude Code CLI. Filing here because that's where Cowork bugs are tracked. Several template fields below (Claude Code Version, Terminal/Shell) are not applicable.

Summary

The Cowork scheduled-task system is silently dropping fires on a recurring basis. Affected runs never execute, no error is surfaced, and no notification is sent. The pattern was originally weekend-only across three consecutive weekends (4/19, 4/25, 4/26 — Eastern Time). It has since extended into weeknights (4/30 and 5/1).

This appears to be at the scheduler service layer. The same pattern affects tasks across different cron expressions, different times of day, and different connector dependencies. It is not a task-configuration issue and not a connector auth issue.

Why this matters

The scheduled tasks I have configured power my morning routine (daily briefing, daily reader digest, market intelligence scan, etc.). When fires drop silently overnight, the morning routine breaks. On 4/26 I had to manually generate the morning emails to recover.

Worse, the in-system safety nets I built to detect this are themselves dependent on the scheduler:

1. gmail-auth-monitor (every 4 hours, alerts via Slack DM on Gmail disconnect) depends on the same scheduler. On weekends where the scheduler skips fires, the alerter cannot fire either.
2. cron-self-heal (daily 5 AM) restores cleared cron expressions. It does not re-fire missed runs and has been skipped during outage windows.
3. weekly-system-review (Sunday 7 PM) is itself one of the dropped fires.

So when the scheduler drops fires, the user-facing notification path is silent.

What Should Happen?

Scheduled tasks should fire at their configured times. Specifically:

• Recurring cron tasks should execute at every scheduled fire window. lastRunAt should advance through each window, and nextRunAt should reflect the next upcoming window.
• One-time fireAt tasks should execute at or shortly after their scheduled timestamp.
• If a fire cannot occur for any reason (service degradation, queue backpressure, connector failure), the user should be notified through a channel that does not depend on the same scheduler.

Error Messages/Logs

No error messages or logs are surfaced. That is part of the problem — the failures are silent. Below is the evidence of dropped fires from `mcp__scheduled-tasks__list_scheduled_tasks` output.

--- Weeknight failures (post-original-report) ---

Task: fletch-tasks-calendar-sync
Cron: 0 23 * * * (every day at 11:00 PM ET)
lastRunAt: 2026-04-30T03:02:23.952Z (Wed 4/29 11:02 PM ET)
nextRunAt: 2026-05-02T03:01:33.000Z
Result: The Thursday 4/30 11:00 PM ET fire was skipped.

Task: market-intelligence-scan
Cron: 30 4 * * * (every day at 4:30 AM ET)
lastRunAt: 2026-04-30T08:40:50.478Z (Thu 4/30 4:40 AM ET)
nextRunAt: 2026-05-02T08:39:59.000Z
Result: The Friday 5/1 4:30 AM ET fire was skipped.

Other tasks in the same 3 to 5 AM ET window did fire on 5/1 morning, so this is not a full scheduler outage. Specific runs are being silently dropped.

--- Weekend pattern (3 consecutive weekends) ---

Sun 4/19/2026: nightly-vault-log, nightly-session-logger, fletch-tasks-calendar-sync, daily-meeting-briefing, daily-reader-digest, daily-spam-review, daily-contact-enrichment, market-intelligence-scan, task-radar-daily all skipped.

Sat 4/25/2026: same set + weekly-system-review (Sun 7 PM) skipped.

Sun 4/26/2026: same set + cron-self-heal (5 AM Sun) skipped. Morning emails were manually generated as Gmail drafts to recover the routine.

Steps to Reproduce

Note: This is not a deterministic reproduction. It is an observed pattern across multiple weeks of scheduled-task data on my account. Reproducing it likely requires looking at scheduler service logs across the windows above.

1. In Cowork mode, configure a set of recurring scheduled tasks across various cron expressions (mix of daily, every-4-hours, weekly).
2. Observe lastRunAt and nextRunAt across multiple consecutive fire windows via mcp__scheduled-tasks__list_scheduled_tasks.
3. Specific runs are silently skipped: lastRunAt does not advance through the missed window, and nextRunAt jumps forward to the following window.
4. The task remains enabled: true and reports as healthy. No error or notification is surfaced.

Fire dates and task IDs where this has been confirmed are listed in the Error Messages/Logs section above.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

N/A

Claude Code Version

N/A — this bug is about Cowork mode in the Claude desktop app, not Claude Code CLI.

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

Affected task IDs (full list)

nightly-vault-log
nightly-session-logger
fletch-tasks-calendar-sync
daily-meeting-briefing
daily-reader-digest
daily-spam-review
daily-contact-enrichment
market-intelligence-scan
task-radar-daily
weekly-system-review
cron-self-heal
gmail-auth-monitor

What would help

1. Confirmation this is being investigated at the platform level.
2. Visibility into whether this affects other users or is account-scoped.
3. A reliable detection path from outside the Cowork environment, since in-system alerting cannot be the source of truth when the scheduler itself is the failure mode.
4. Any known workaround on my side.

Mitigation in progress

In parallel I am moving the most critical recurring tasks (the morning email pipeline) to Google Apps Script time-triggers calling the Claude API directly, so they are independent of the Cowork scheduler. I would still like Cowork scheduled tasks to be reliable for everything else.

Happy to share full task configs, additional lastRunAt / nextRunAt snapshots, or anything else useful for diagnosis.