Windows desktop app: internal scheduler silently drops scheduled-task slots for hours while app is healthy (+ MSIX updater closes app without relaunch; logger dead after ENOSPC)

Environment

• Claude desktop app for Windows (MSIX), versions observed: 1.28929 → 1.30096.1 → 1.30096.5 (current)
• Windows 11 Pro 10.0.26200, x64
• Heavy scheduled-tasks user: an 8:35 AM daily task plus an hourly task 9 AM–9 PM, used as the backbone for household/business automations. External watchdog scripts monitor the app and its task heartbeats, so the timeline below is from logs, not memory.

Bug 1 (main report): internal scheduler silently stops firing scheduled tasks while the app is healthy, then batch-catches-up hours later

Three incidents in one week with the identical signature (plus three more in the prior three weeks):

| Date | Scheduler dead | Evidence |
|---|---|---|
| Aug 13 | ~70 min (dropped 3 morning slots, batch-ran them together at 9:45 — two tasks fired 1 second apart) | task run logs + external heartbeat file |
| Aug 14 | ~4.2 h (beat once after an app restart, then dropped 4 consecutive hourly slots, recovered on its own) | heartbeat gap 16:10 → 20:23 |
| Aug 16 | ~4 h (beats at 9:11 and 10:11, nothing until self-recovery at 14:09) | heartbeat gap; app processes alive and its usage file updating the whole time |

In every case:

• The app's process tree stays up and looks healthy (30–40 processes, normal memory ~1.4–1.6 GB).
• No Crashpad dumps (reports dir empty), no WER events for claude.exe, sleep/wake ruled out via System event log (no 42/107 pairs), no reboot.
• Recovery is spontaneous and includes a "catch-up" burst where the missed tasks all run.
• Two of the three wedges began within ~15 minutes of an app restart, suggesting a scheduler-init race.

Impact: for a user who relies on scheduled tasks unattended, the app looks fine while hours of scheduled work silently never fires. There is no user-visible signal that the scheduler is wedged.

Bug 2: MSIX auto-updater force-closes the app to register a pending update and never relaunches it

• Aug 14 23:55: update 1.30096.5 downloaded.
• Aug 15 05:01: apply failed with 0x80073D02 ("apps need to be closed") — app was open.
• Aug 15 10:20:05: updater force-closed the app ("Windows session ending (close-app)" in main.log), registered the package at 10:20:42 — and nothing relaunched the app. It stayed down 37 minutes until an external watchdog started it.
• Note for anyone writing their own relauncher: the post-update first launch triggered six AppX Register cycles and took ~7 minutes before claude.exe stayed resident.

Expected: after a forced close-to-update, the app should relaunch itself (or at minimum the update should defer, as it did at 05:01).

Bug 3: file logger never recovers after ENOSPC

The disk briefly hit 0 bytes free on Aug 15 (external cause, not the app). The app logged ENOSPC at 21:58 and its main.log then stayed completely silent for ~16 hours — through a period when the app was demonstrably running and its scheduler wedged (Aug 16 incident above) — until a full app restart restored logging. The logger apparently never retries after a write failure, which blinded diagnosis of Bug 1 during exactly the window it mattered.

Logs

I have main.log excerpts, AppXDeploymentServer event IDs/timestamps, external heartbeat files, and per-incident process/memory snapshots available on request (kept out of this public issue since they contain machine-specific paths).