[BUG] Scheduler silently stops firing all scheduled tasks after a few hours of app uptime; only an app restart recovers (Windows)

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?

Scheduled tasks fire reliably ONLY in the catch-up burst that runs immediately after the app launches. Within hours of launch the scheduler stops firing entirely, and every subsequent slot is silently skipped — with the app open, the machine awake, and no error surfaced anywhere. Restarting the app is the only thing that makes tasks run again.

Missed slots are skipped, not queued: nextRunAt advances past them as if they had run.

Diagnostic signature: listing scheduled tasks shows every task's lastRunAt clustered within a few minutes of each other — the launch burst — regardless of each task's own cron schedule. nextRunAt keeps rolling forward normally, so nothing in the UI indicates anything is wrong.

Clearest occurrence (2026-07-31 to 08-02). The app was restarted at ~8:11 AM and the launch burst fired every overdue task. One three-times-daily task ran to completion successfully (93 turns) and went idle — a clean, healthy run with no hang. The scheduler then fired nothing at all for the next ~30 hours, across eight distinct recurring tasks with different schedules. Because no session was stuck and the app stayed open the whole time, this isolates the failure to the scheduler/timer itself rather than to zombie sessions or a closed app.

Related secondary behavior (possibly the same root cause): a task run that hangs on a tool call never times out, stays in "running" state indefinitely, and blocks all subsequent fires until the session is manually archived. Observed twice, 2026-07-28 and 2026-07-29.

Previously reported and closed without a fix: #55631 (closest match — Windows, scheduler stops firing after ~24-30h uptime; closed as not planned, stale), #47899 (hung "Running" sessions causing a permanent skip-cascade; closed as not planned, stale), #66976 (closed as duplicate), #44128, #36131. None are currently open, which is why this is filed fresh rather than as a comment.

What Should Happen?

With the app open, a task with cron 0 6,14,22 * * * should fire at ~6:04 AM, ~2:04 PM and ~10:04 PM every day, indefinitely, regardless of how long the app has been running.

Actual: it fires only if an app launch happens to occur near one of those times. Otherwise the slot passes silently — no run, no error, no notification, and no indication in the UI that anything was missed.

Error Messages/Logs

Steps to Reproduce

Step 1 — On Windows, create several recurring scheduled tasks with cron schedules spread across the day. Mine included 0 6,14,22 * * *, 30 7 * * *, 0 3,15 * * *, 0 5,13,21 * * * and 12 9,19 * * * — eight tasks in total.

Step 2 — Launch the Claude desktop app. Observe the catch-up burst: all overdue tasks fire within a few minutes of each other and complete normally.

Step 3 — Leave the app open and the machine awake. Do not restart the app.

Step 4 — Wait for the next scheduled slot, hours later.

Step 5 — Observed: the slot passes with no run. List the scheduled tasks; lastRunAt for every task is still the launch-burst timestamp, while nextRunAt has rolled forward past the skipped slot.

Step 6 — Every subsequent slot is skipped the same way for as long as the app stays open. Observed up to ~30 hours and 8+ consecutive missed slots.

Step 7 — Restart the app. The catch-up burst fires again and tasks run normally, restarting the cycle.

The machine was confirmed awake for the entire period: the Windows Kernel-Power event log shows no sleep/wake events at all (none since 2026-05-12), so this is not a suspend/resume issue.

Claude Model

None

Is this a regression?

I don't know

Last Working Version

_No response_

Claude Code Version

1.24012.9.0 (Claude desktop app for Windows, MSIX package Claude_1.24012.9.0_x64__pzs8sxrjxfjjc)

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Environment: Windows 10 Pro 22H2 (build 19045). This is the packaged Claude desktop app, not the npm CLI — claude --version is not on PATH for this install, so the version above is taken from the installed MSIX package. There is no terminal involved, hence "Other" for Terminal/Shell.

Scope: eight distinct recurring tasks with different cron schedules were affected simultaneously, so this is not specific to one task's prompt, tooling, or connectors.

Impact: these are unattended daily production workflows meant to accumulate a rolling backlog of output for review. Because the schedule effectively runs once per app restart instead of three times a day, the backlog never accumulates and the work has to be redone by hand. Unattended scheduling is the entire value of the feature, and at present it cannot be relied on.

Current workaround: fully quit and reopen the app each morning so the launch catch-up burst runs that day's tasks. Any session left stuck in "running" must be manually archived first, or it blocks the queue.

Suggested fixes:

1. A heartbeat/watchdog that detects a dead scheduler timer and restarts it, rather than relying on app launch to re-initialize it.
2. 2. A timeout on task runs so a hung session cannot block the queue indefinitely (this is what #47899 asked for).
3. 3. Surface skipped slots in the UI — currently nextRunAt silently advances and there is no way for a user to tell that anything was missed without manually comparing lastRunAt values across tasks.