claude-code - 💡(How to fix) Fix Scheduled tasks stop firing autonomously after 12-24 hours; manual reboot triggers catch-up burst that swallows queued runs [2 comments, 2 participants]

Preflight Checklist

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

What's Wrong?

Note: This bug is in the Cowork desktop app's scheduler, not the Claude Code CLI. Filing here per the issue tracker referenced in Cowork docs.

Summary

The Cowork scheduler stops firing tasks autonomously after roughly 8-12 hours of app uptime. After that, a Windows reboot is required for any scheduled task to fire. On relaunch, the scheduler emits a "catch-up burst" in which every queued run from the silent window fires within ~5 minutes — and that burst is then counted against the day's natural cron times, so today's regularly scheduled fires get skipped.

On 2026-05-08 a new variant appeared: 5 overnight runs hard-failed with FailedToOpenSocket instead of stalling silently, after which the silent-stall pattern resumed for the rest of the day.

Actual behavior

[Day N, ~T+0h]     Cowork app launched
[Day N, T+0..12h]  Scheduled tasks fire on cron times as expected
[Day N, T+12h+]    Scheduler silently stops firing — no errors, no logs visible to the user
[Day N+1, reboot]  App relaunches; queued runs all fire within ~5 minutes
                   (e.g. 7:06 daily-brief, 8:05 daily-crypto-brief, 9:05 ulc-brief
                    all fire at ~7:42 in a single burst)
[Day N+1]          Today's 7:06 / 8:05 / 9:05 cron slots are skipped — the burst
                   appears to satisfy them

5/8 variant prelude:

[overnight 5/7 → 5/8]
  hourly-email-triage  (slot 1)  -> FailedToOpenSocket
  hourly-email-triage  (slot 2)  -> FailedToOpenSocket
  crypto-price-alerts  (slot 1)  -> FailedToOpenSocket
  hourly-email-triage  (slot 3)  -> FailedToOpenSocket
  crypto-price-alerts  (slot 2)  -> FailedToOpenSocket
[5/8 morning onward]   silent stall pattern resumes

5/10 confirmation: A one-time fireAt task scheduled for Sunday 5/10 9:00 AM CT did not fire. Verified at 11:02 AM CT — task still pending, no automatic execution. Same silent-stall pattern. That makes 7 consecutive days of the same failure (Mon-Sun, May 4-10, 2026).

Impact

• Critical scheduled work is missed: financial/crypto price alerts, business deadline reminders, and health protocol reminders all depend on these tasks firing on time.
• The user has to manually reboot Windows at least once daily to keep the scheduler healthy.
• Trust in the scheduler is eroded — having to manually verify after every reboot whether expected runs actually fired or were swallowed by a catch-up burst defeats the purpose of automation.

Workaround

Daily Windows reboot + manual verification of the "Scheduled" panel against expected cron times.

What Should Happen?

• Tasks should fire on their configured cron schedule for as long as the Cowork app is running, with no time-based degradation.
• If the app is closed for some interval, on next launch the scheduler should NOT fire every missed run as a burst. Acceptable policies, in order of preference:
  • (a) Fire only the most recent missed instance per task and log the rest as skipped.
  • (b) Fire none of the missed runs and log them as skipped.
  • (c) Offer a configurable per-task catchUpPolicy (e.g. latest, none, all) so the user can opt into bursts where they're actually wanted.
• Transient transport errors like FailedToOpenSocket should be retried with exponential backoff (e.g. 3 retries over ~30s) rather than failing the run outright.

Suggested fix priorities:

1. Keep the scheduler thread alive past the 8-12 hour mark. Whatever resource (socket, timer, IPC channel) is degrading after ~half a day needs to be either kept healthy or transparently re-established. The fact that a hard reboot is the only reliable fix suggests the scheduler isn't recovering on its own from whatever state it ends up in.
2. Implement a catch-up policy that doesn't eat current-day fires. At minimum, missed runs should not be counted against today's cron slots. Default to "fire only latest missed" or "fire none and log skipped"; ideally expose a per-task config.
3. Backoff-retry on FailedToOpenSocket (and similar transient transport errors) before marking a run as failed.

Error Messages/Logs

Steps to Reproduce

1. Open the Cowork desktop app on Windows.
2. Create several scheduled tasks via the scheduler skill — mix of cron-based recurring tasks (e.g. 0 9 * * * for a daily 9 AM task, 2 * * * * for hourly at :02) and one-time fireAt timestamps several hours into the future. ~20-30 tasks is a representative load.
3. Leave the Cowork app running continuously for 12+ hours.
4. Observe the "Scheduled" panel: tasks fire on time for the first ~8-12 hours.
5. After that window, tasks stop firing autonomously — no error, no notification, no log entry visible to the user.
6. Reboot Windows (or quit and relaunch the Cowork app).
7. Within ~5 minutes of relaunch, every queued run from the silent window fires in a tight burst — visible as completed status entries with timestamps clustered together rather than spread across natural cron times.
8. Observe that today's regularly scheduled cron slots that should fire AFTER the burst are skipped — the burst run appears to satisfy them.

To reproduce the 5/8 variant (FailedToOpenSocket hard failures):

• Same setup as above, leave running overnight. Some morning, several consecutive scheduled runs fail with FailedToOpenSocket before the silent-stall pattern resumes. Observed 5 such failures in a single overnight window (3x hourly-email-triage, 2x crypto-price-alerts) on 2026-05-08.

Affected tasks observed:

• hourly-email-triage — cron 2 * * * *
• crypto-price-alerts — every 2 hours
• daily-brief — 7:06 AM daily
• daily-crypto-brief — 8:05 AM daily
• update-the-ulc_project_brief_for_cowork — 9:05 AM daily
• eod-triage — 4:10 PM Mon-Fri
• weekly-market-context-sunday — Sun 6:10 PM
• Various one-time fireAt tasks

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

No response

Claude Code Version

N/A — this is a Cowork desktop app bug (Windows), not the Claude Code CLI. Cowork app version visible in Settings → About.

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

No response