[BUG] Desktop app update silently wiped the internal scheduled-tasks registry (scheduledTasks: []) — all scheduled tasks died at once, with zero user notification
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?
Summary
On 2026-08-07 at ~17:35 (Europe/Madrid), a desktop app update/reinstall emptied the app's internal scheduled-tasks registry. All four of my scheduled tasks died simultaneously and silently. There was no warning, no migration, no notification — the app simply started with scheduledTasks: []. I discovered it a day later through my own external watchdog, and lost roughly three working days (Friday evening through Sunday) diagnosing the root cause and rebuilding my automation outside the app.
Environment
- Windows 10 (build 10.0.19045), Claude desktop app (Cowork), Max 20x plan
- App update/reinstall footprint:
first_launch_at= 2026-08-08 11:46;.last-cleanup= 2026-08-07 17:53
Evidence (from my own disk, verified)
%APPDATA%\Claude\...\<id>\scheduled-tasks.json→"scheduledTasks": [](file dated 2026-08-08 11:50) — registry empty after the update.- The task definitions themselves survived intact at
C:\Users\<user>\.claude\scheduled-tasks\<task-name>\SKILL.md— so the app kept the payloads but lost every registration, and told no one. - My tasks (checkpoint every 30 min + three dailies) have per-run logs: the last app-scheduled run of each was 2026-08-07 ~17:3x; none ever fired again.
What Should Happen?
- An update must migrate (or at minimum preserve) the scheduled-tasks registry.
- If registrations are dropped for any reason, the user must be notified ("N scheduled tasks were disabled by this update — restore?"). Silent loss of automation is the worst possible failure mode: the absence of a background task produces no error anywhere.
Error Messages/Logs
There are no error codes, dialogs, or log messages — that is precisely the complaint: everything failed silently. The only machine-readable evidence is the post-update state on disk:
%APPDATA%\Claude\...\<id>\scheduled-tasks.json -> "scheduledTasks": [] (file dated 2026-08-08 11:50)
C:\Users\<user>\.claude\scheduled-tasks\<task-name>\SKILL.md -> all 4 task definitions intact
Per-run task logs: last app-scheduled run of every task = 2026-08-07 ~17:3x; nothing after.Steps to Reproduce
- On Windows 10, have several scheduled tasks registered and firing normally in the Claude desktop app (Cowork) — in my case: one checkpoint task every 30 min + three dailies, all with per-run logs.
- Let the desktop app update/reinstall itself (here: 2026-08-07 ~17:35 Europe/Madrid;
.last-cleanup= 2026-08-07 17:53;first_launch_at= 2026-08-08 11:46). - Observe: the internal registry file
scheduled-tasks.jsonnow contains"scheduledTasks": [], while the task definitions underC:\Users\<user>\.claude\scheduled-tasks\remain intact on disk. - No scheduled task ever fires again. No warning, dialog, or notification is shown at any point — the loss is only discoverable from outside the app.
Claude Model
None
Is this a regression?
Yes, this worked in a previous version
Last Working Version
Unknown — desktop app build in use until 2026-08-07 ~17:35 (tasks firing normally)
Claude Code Version
Unknown — Claude desktop app (Cowork), auto-updated 2026-08-07; first_launch_at 2026-08-08 11:46
Platform
Other
Operating System
Windows
Terminal/Shell
Other
Additional Information
Related gaps found while recovering (same silent-failure pattern)
- Headless capability asymmetry, undocumented: tasks relaunched via
claude.cmd -p(Windows Task Scheduler) run, but the harness deniesschtasks/ theScheduledTasksPowerShell module, and the session has no account connectors (Gmail MCP) and no push-notification tool — all available in app sessions. Each gap fails silently or with a generic denial; none of this is documented in one place. My alert-escalation chain (email draft + push after 72 h down) turns out to be unimplementable exactly in the mode that survives app failures. - Cloud scheduled tasks (Cowork triggers) start with no device-bridge folder grants, so they cannot read/write local files — discovered only by watching a task fire on schedule and silently do nothing (its JSON output never appeared). Reasonable design, but it needs to be stated where scheduled tasks are created.
Impact
Max 20x subscriber. Three working days lost at a financially critical moment, plus a substantial amount of my paid usage spent diagnosing and repairing the product's own failure (audit, migration of 4 tasks to Windows Task Scheduler, verification runs). The product's core promise to me is unattended automation; that promise failed silently.
Ask
- Fix registry migration across updates.
- Notify on any dropped/disabled scheduled task.
- Document, in one place, exactly which capabilities exist in: app sessions vs
claude -pheadless vs cloud scheduled sessions.
Related issue
#83600 reports active scheduled-task registrations vanishing on Windows while the on-disk SKILL.md definitions survive — same silent-loss shape. My case pins one concrete trigger (app update/reinstall) and locates the registry that loses the entries: %APPDATA%\Claude\...\<id>\scheduled-tasks.json, found containing "scheduledTasks": [] immediately after the update.
Showing cached comments. Read the full discussion on GitHub ↗
3 Comments
Update - 13 August 2026 (3 days after filing; no maintainer response yet).
One correction to my own report, for accuracy: I wrote "Max 20x subscriber". That was my error - the account is on a Max 5x subscription. The plan tier has no bearing on the bug itself, but I would rather the report be correct.
The substance of the issue is unchanged: a desktop app update rewrote
scheduled-tasks.jsonto"scheduledTasks": []while leaving the task definitions intact on disk. Every scheduled task stopped firing. No notification, no error, no log entry. The silent failure mode is the core of the report - a loud failure would have cost minutes instead of three working days.Still asking for the three items in the original issue: fix registry migration across updates, notify users when scheduled tasks are dropped or disabled, and document capability differences across execution modes (app sessions vs headless vs cloud).
Related reports in the tracker, plus a timeline that rules out the most obvious alternative explanation.
Since filing this I searched the tracker and found a cluster of scheduled-task failures that look related. Listing them in case it helps triage see a pattern rather than isolated reports:
The common thread across those and this report is not any single wrong value. It is that the failure is silent. In each case the tasks stop doing their job while the app continues to present a normal state. That is what turns a small defect into days of lost work: there is no signal to react to. A loud failure here would have cost me minutes.
Ruling out #86115 for this report.
#86115 is the closest match by symptom, so I checked whether it explains what I saw. It does not, and the timeline is what separates them:
"scheduledTasks": []. At this point none of my scheduled tasks were paused or disabled; all of them were active and firing normally.So the disabling happened after the wipe, not before it. #86115 describes disabled tasks vanishing from the Routines list; here, tasks that were active and enabled were removed from the registry at update time. Different precondition, and #86115 cannot account for this one.
I raise it explicitly rather than leave it for someone else to notice, and I would still suggest the two be looked at together: if both are real, the registry is losing entries under more than one condition.
Impact note, for prioritisation only.
Beyond the working days lost, recovering from this consumed a substantial amount of my paid plan usage: diagnosing the failure, auditing what had been destroyed, and rebuilding the automation outside the app. I mention it only because this tracker already has an area:cost label and #74547 as precedent - silent scheduled-task defects carry a measurable cost to the user, which may be worth weighting in triage. I am not raising any billing matter in this thread; that is with support separately.
Correction to my own report, on my own evidence. Part of this issue as filed does not hold, and I am withdrawing it.
I reported that the 7 August desktop app update wiped the scheduled-tasks registry. Having now read the Windows AppX deployment logs, that specific claim does not hold and I withdraw it.
Verified sequence from the logs:
app\resources\cowork-svc.exe.scheduled-tasks.json({"scheduledTasks": []}) is created, four minutes later.So the empty registry file dates from after my own uninstall/reinstall on 8 August, not from the 7 August update. My uninstall also destroyed the evidence of the app's prior state, so what happened at ~17:35 on 7 August cannot be reconstructed from any log on this machine. I am not going to claim what I cannot prove.
This also supersedes my earlier comment on this issue about the tasks' enabled/disabled state, which was framed around the update-time wipe.
What remains, and is documented:
.claude\scheduled-tasks. What was lost was the app's live registry of them.The silent stoppage is the defect I am still reporting, and it is the part that cost the week. Whatever the precise mechanism, at no point did the product indicate that the automation had stopped.
If maintainers judge that what remains is too thin to act on without the pre-uninstall state, close this and I will not object. I would rather have an accurate tracker than a live issue built on a claim I can no longer support. If a notification-on-registry-change request is worth keeping separately, I am happy to file that on its own.
Raw AppX log excerpts available on request.