[BUG] Scheduled tasks silently disappear: recurring task vanished twice in 5 days while spent one-time tasks persist

The "recurring vanishes, one-time persists" asymmetry is a useful diagnostic signal. It suggests the deletion path is keyed on a condition that recurring tasks meet more often than one-time tasks — expiry evaluation after the last run, a TTL on tasks that have fired at least once, or a cleanup sweep that checks nextRunAt and drops tasks whose computed next run has already passed (which could happen if the scheduler was paused, restarted, or behind during a previous cycle window).

A few things that would help narrow it:

1. What does the SKILL.md for the recurring task look like just before the second vanishing, specifically the lastRunAt and nextRunAt fields? If nextRunAt is in the past at the time of disappearance, that points to the scheduled-past cleanup theory.
2. Does the task disappear from ~/.claude/scheduled-tasks/<taskId>/ on disk, or only from list_scheduled_tasks output? If the directory is gone, the deletion is persistent; if the directory exists but the task isn't listed, it is a registration/reload gap.
3. Did any Claude Code update (auto or manual) happen in the 24-48h window before each disappearance? Version bumps can reload the scheduler and fail to re-register existing tasks if the migration path has a gap.

The silent disappearance without a log entry is the most actionable bug here regardless of root cause — a scheduled task that deletes itself should at minimum write a deletion reason to the task's audit trail.

Thanks — gathered what I could for all three questions. The disk evidence is conclusive on #2.

2. Disk vs listing: directories persist; the registration is what vanishes.
~/.claude/scheduled-tasks/ still contains all 11 task directories ever created on this machine — including tasks that vanished from list_scheduled_tasks days ago, and even tasks that were explicitly deleted via the API weeks ago. The recurring task,s directory was created Jul 27 and survived both vanishings (same directory; its SKILL.md was simply overwritten when I re-created the task). So this is a registration/reload gap, not persistent deletion.

Related finding: the task directory contains only SKILL.md, whose frontmatter holds just name + description. None of the schedule metadata (cronExpression/fireAt/enabled/lastRunAt/nextRunAt/jitterSeconds — all of which list_scheduled_tasks reports) lives in the task directory, and I could not find an index file elsewhere under ~/.claude. Wherever that registry is persisted is what is losing entries.

1. State just before the second vanishing (from list_scheduled_tasks outputs, since SKILL.md carries no schedule fields):

• The recurring task existed and was updated successfully on Aug 1 (~18:00 UTC). Its next run would have been Aug 3 12:01:44 UTC.
• The app was closed at that moment (operator away all morning). First app activity was ~13:20 UTC — at which point a late one-time task fired via catch-up (so catch-up itself works). At 16:10 UTC, update_scheduled_task on the recurring task returned not found.
• The first vanishing matches the same shape: next run Jul 29 12:01:44 UTC, app closed at that time, first activity 12:19 UTC, task found missing later that day.

So in both events, nextRunAt passed while the app was closed — consistent with your scheduled-past cleanup theory. One caveat: in event #1 a future one-time task (fireAt Nov 3, months away) vanished in the same event, which the past-nextRunAt theory does not explain.

A sharper asymmetry than recurring-vs-one-time: after each event, the survivors were exactly the disabled/spent tasks (enabled: false, already fired). The tasks lost were exactly the active ones (recurring + future one-time). That smells like "the active/pending set fails re-registration on reload" while the spent set is either persisted differently or never touched.

3. Version bumps: cannot confirm (no CLI access from this environment to check version history). Both windows did include app/session restarts, at least one non-graceful: background shell tasks from the prior session were reported with "no completion record ... may have been running when the previous Claude Code process exited".

Agreed on the audit trail point — a deletion reason written to the task directory (which demonstrably survives) would have made this diagnosable on the first occurrence.

Third occurrence — same recurring task, vanished again within ~24h of being re-created.

Timeline for this one (times UTC):

• Aug 3 ~16:10: task not found on update → re-created from scratch (daily cron 0 9 * * *, local BRT = 12:02 UTC).
• Aug 3 ~18:00-23:00 + Aug 4 morning: app in active use across multiple sessions (restarts included).
• Aug 4 ~12:02: scheduled fire time. Cannot confirm whether it fired — no run report surfaced.
• Aug 4 ~18:35: update_scheduled_task → Scheduled task "<id>" not found again. list_scheduled_tasks shows only the two spent one-time tasks, as before. Task directory + SKILL.md still on disk, as before.

Pattern across all three: the active recurring task is lost within roughly one scheduled-fire window of its (re-)creation; spent one-time tasks are never affected. This machine typically has the app closed at the cron fire time on some days and open on others, and losses have followed both patterns now — so "nextRunAt in the past at reload" may not be the whole story, unless the relevant reload happens at unpredictable times (session teardown?).

Happy to run any diagnostic on the next re-creation — this reproduces reliably enough here (3/3 within ~5 days) that instrumentation would likely catch it in the act.

4th occurrence (2026-08-05, ~19:50 UTC, same Windows 11 machine).

Registry vs disk at discovery time:

• list_scheduled_tasks returned only 2 entries — both spent one-time tasks (lastRunAt Jul 28 and Aug 3), both enabled: false.
• On disk, ~/.claude/scheduled-tasks/ still holds 11 task directories, every SKILL.md intact.

Lost from the registry (all previously active):

• a daily recurring watcher task (created ~Aug 2, had been firing daily since)
• a weekly recurring task (Mondays, had fired multiple times over several weeks)
• at least one pending one-time task with a fireAt months in the future (November)

Pattern matches occurrences 1–3 exactly: directories and SKILL.md files persist, registry entries for active tasks vanish; the only survivors are already-spent one-time entries. Recovery was again trivial by re-creating from the on-disk SKILL.md files, which is why I can confirm the files themselves are untouched.

Happy to pull any local logs/paths that would help — just tell me what to grab before the next occurrence overwrites state.