Scheduled tasks silently skip their fire window, with host machine and scheduler engine both demonstrably active

A forward-looking nextRunAt doesn't show a task is healthy. It's also what you'd see if the scheduler moved past a missed slot without logging anything. So the registry can't tell "will run" apart from "skipped and moved on".

It's worth lining the missed slots up against the hourly-mail-check runs. If each gap falls while another task was still running, that suggests the slot was dropped rather than queued behind it. dispatcher-cross-lane-sync is the easiest one to test this on, since it has two fixed times a day.

We run into this daily at RunVouch. A scheduler can't report a slot it never looked at, so the only reliable signal is a check outside the scheduler that expects each task at its cadence.

We build RunVouch for that check: https://runvouch.com

Independent data point on this: I have a minimal reproduction task — a single scheduled task that requires zero permissions (it only writes one timestamp line to a fixed local file, nothing else). It's been continuously enabled: true on a 5-minute cadence since creation on 2026-09-09 (13 days, ~3,700 expected fire windows). nextRunAt has advanced correctly on every check. totalRuns has stayed at 0 the entire time — not a single execution, ever.

Since this task needs no permission approval, it rules out any explanation involving a stuck/unanswered permission prompt. Platform: Windows, Claude Code desktop app.

A fourth failure signature, added 23 Sep: total registry loss, recurring and larger than the first occurrence

We previously reported (internally, not yet in this issue) a full scheduled-task registry loss on 15–16 September: the registry went from a normal count of ~2-digit tasks to 0 between 15 Sep 20:13 UTC and 16 Sep ~03:4x UTC, while every task's SKILL.md file remained intact on disk. We treated that as a one-off. It has now recurred, and at larger scale: a fresh list_scheduled_tasks call on 23 September, 04:12:32 UTC returned only 1 registered task, and that one had itself been manually re-created seconds earlier in the same session — so the effective count immediately before that was 0. A full registry dump taken the day before (22 September) had shown 84 registered tasks. Nothing on disk explains this: 220 task folders with intact SKILL.md files remain present under the local scheduled-tasks directory, unchanged. This is the same failure class as the 15–16 Sep incident (registry entries vanish while the underlying task definitions survive on disk), but the drop this time (84 → ~0) is larger than the first occurrence (~2-digit → 0). We still have no root cause for either occurrence — flagging the recurrence and the larger magnitude, not proposing a cause.

A fifth, distinct failure signature, added 23 Sep: a task disappears from the registry shortly after completing a successful run

This is different from every signature above — those all describe a task failing to fire, hanging, or (in the registry-loss case) an apparently simultaneous wipe of the whole registry. This new signature is a task that worked correctly — fired, ran, completed with status succeeded per list_task_runs — and was then found missing entirely from list_scheduled_tasks (taskDeleted: true in the run-history lookup) a short time later, well outside the 15–16 Sep / 23 Sep bulk-wipe windows described above. Measured via list_task_runs for each task ID (all timestamps UTC):

| Task ID | Last successful run (start–end) | Time between that run and the 04:12:32 UTC registry check | Registry state at check time |
|---|---|---|---|
| registry-radar-daily | 23 Sep 03:22:23–03:33:19 | ~39 min | missing (taskDeleted: true) |
| dispatcher-command-check | 23 Sep 03:10:11–03:19:10 | ~53 min | missing (taskDeleted: true) |
| proactive-followup-watchdog | 22 Sep 07:15:49–07:20:08 | ~21 hours | missing (taskDeleted: true) |
| km2-business-hours-sender | 22 Sep 14:22:54–14:23:40 | ~14 hours | missing (taskDeleted: true) |

The first two rows are the tightest cases: both tasks completed a normal, successful run under an hour before the registry was found empty. We cannot tell from the client side whether this is the same underlying mechanism as the 84→~0 bulk registry loss (i.e., these four tasks were simply caught in that same wipe, and their "last successful run" timestamps are a coincidence of proximity) or a separate mechanism entirely (individual task deregistration, independent of the bulk-wipe events). We are not asserting either explanation — noting both as open possibilities for your triage.

Environment unchanged from the original report: Windows 11 Home, Claude Code desktop app, Europe/Sofia (UTC+3).

Recurrence with concrete external-facing business impact — this is now a repeat, escalating pattern, not an isolated incident

Following up on the two failure signatures added earlier today (recurring bulk registry loss, and tasks disappearing shortly after a successful run): we want to flag that this is not a theoretical or purely internal concern anymore. It has now caused a real, time-sensitive external communication to go unhandled.

Timeline of today's concrete impact:

• A scheduled task whose job is to track a hard external deadline (a regulatory compliance deadline with a fixed date, unrelated to Claude/Anthropic) was silently deregistered in the same bulk registry loss reported earlier today (84 → ~0 tasks).
• Because that specific task no longer existed in the registry, nobody — human or automated — was watching its associated inbox thread.
• An external party sent a substantive, actionable reply into that thread at approximately 06:41 UTC.
• That reply was not surfaced or acted on until approximately 13:00 UTC — roughly 6 hours later — when it was found only by chance during unrelated manual troubleshooting of the registry loss itself, not by any automated process.
• The compliance deadline in question is 2 days out from today, so the delay did not (this time) cause a missed deadline — but it easily could have, and for a different deadline on a different day it would have.

Why we're adding this rather than opening a new issue: this is a direct, measurable consequence of the exact failure class already described above (task deregistration without a trace, independent of whether the task itself is otherwise healthy). We are not asserting a new root cause — we are documenting that the "silent" part of "silently skip/deregister" is not a cosmetic detail: it means there is no signal anywhere (log, notification, registry state) that a lane of work has gone dark, until a human happens to check by hand.

This is also not a first occurrence for us as reporters. We have now had two full-registry-loss events in 8 days (15–16 Sep and 23 Sep), plus the two additional signatures reported earlier today. Each time, recovery has depended on a human noticing the symptom and manually re-diagnosing from scratch, because the failure leaves no trace of itself in any log or state file we have access to.

What would materially help us (and presumably other users hitting the same class of bug), ranked by how much it would have prevented today's specific incident:

1. Any server-side or client-visible audit trail of task deregistration events (even just a timestamp + task ID + reason, however terse) — right now a deregistered task simply stops existing, with nothing left behind to explain when or why.
2. A push notification / alert (not just silent registry state) when a task that was previously enabled: true disappears entirely, as distinct from a task that fires but fails.
3. Any acknowledgement from the Anthropic team that this is being actively looked at — the issue has been open with recurring reports and zero team engagement so far, only community replies.

Environment unchanged: Windows 11 Home, Claude Code desktop app, Europe/Sofia (UTC+3).

Possibly related, same platform: Windows 11, Claude Desktop 2.7032.0.0 (Microsoft Store/MSIX install), Cowork scheduled tasks. My symptom is a harder failure than intermittent skipping, and it reproduces 100% of the time.

Symptom: Every scheduled task fails to run, both on schedule and with Run Now. Run Now immediately shows a toast: "Failed to run scheduled task. You can try again." No run is recorded in the task history.

Repro:

1. Create any task, including a trivial one with no tools, connectors or folder (zz-test-a-notools). Creation succeeds, and main.log shows [ScheduledTasks] Saved scheduled task.
2. Click Run Now. The toast appears.

What the logs show:

• The renderer DevTools console logs [DESKTOP_API] Scheduled task run request received {"scheduledTaskId":"zz-test-a-notools"} and then nothing else at any log level.
• The Network tab shows no request at all when Run Now is clicked.
• main.log, tailed live during the click, shows no new lines. The request never reaches the main process.
• For cron fires, main.log shows [ScheduledTasks] VM not ready (tick 1), requesting startVM for: <task> (cron 0 6 * * 1-4). The VM then starts cleanly (Startup complete, total time: 13555ms, API reachability: REACHABLE), but the task is never dispatched afterward and no run appears.

Ruled out:

• The Sep 8 Windows update drive-mount bug. cowork_vm_node.log shows host drive share "c" not mounted: Plan9 mount failed on Sep 15, but the VM now boots and mounts the drive normally, and interactive Cowork sessions work fine.
• Documents/OneDrive redirection. Tasks are stored at C:\Users\<user>\Claude\Scheduled, and task files are created without errors.
• Task content. A no-tools test task fails identically to real tasks.
• App state. A full restart, including killing all claude.exe processes, didn't help.

Possibly relevant: the tasks were created through mcp__scheduled-tasks__create_scheduled_task in a Cowork chat, not from the Scheduled panel. CycleHealth also reports msix_fs_virtualized: true.

Full main.log and cowork_vm_node.log are available on request.

Additional data point: the registry decay window started earlier than our last report suggested.

We previously reported a full scheduled-task registry loss (all tasks gone, on-disk task definitions untouched) dated to the night of the 15th/16th (our local time). Re-checking one task's own run history (a separate log that survived both registry wipes we've now had) shows something more precise:

• Last confirmed normal run: Friday, expected time slot, succeeded normally.
• The following Monday, Tuesday, and Wednesday (three consecutive weekday cron slots): zero run records at all — not a failed attempt, not a late attempt, nothing. For comparison, genuine failures in this same task's history (e.g. upstream API connectivity errors) always produced a "failed" record with an error message. A registry entry that still exists but errors on fire leaves a trace; these three days leave none.
• First run after the gap: the following Tuesday, succeeded.

So the silent disappearance that we could only pin to "sometime around the 15th/16th" actually appears to have started by the Monday morning at the latest — at least one full weekday earlier than we'd been able to document before. This doesn't change the diagnosis, just tightens the timeline: whatever causes the registry to lose entries was already in effect several days before we noticed the full-scale wipe.

Posting this as a data point in case the timing correlates with anything on your end (a deploy, a restart, a config change) around that earlier date rather than the later one we'd originally flagged.