[BUG] Windows desktop: ScheduledTasks startVM retry loop every ~5 min, forever ('VM service not running. Restart your computer to restore it.') - 496 failures/48h, persists across reboots

Status Open
Maintainer reply None cached
Activity 0 comments · opened Aug 17, 2026

Summary: The desktop app's ScheduledTasks subsystem retries startVM every ~5 minutes, around the clock, and every attempt fails with the same error. 496 failures in one 48-hour window on this machine. The error text tells the user to restart the computer; a full restart does not stop the loop.

Environment: Windows 10 Pro 19045, Claude Desktop MSIX 1.30096.5.0 (also observed on 1.30096.1). Hyper-V host services (vmcompute, hns) present and Running. 64 GB RAM.

Signature:

[warn] [ScheduledTasks] VM not ready (tick 5), requesting startVM
[warn] [ScheduledTasks] startVM failed: Error: VM service not running. Restart your computer to restore it.

Cadence data (from main.log): exactly 12 failures per hour, every hour, including overnight with the machine idle - e.g. a continuous 12/hour band from Aug 16 05:00 through Aug 17 04:00. First burst observed Aug 15 ~11:21 immediately after an app update to 1.30096.5 (machine had been rebooted at 10:46 that morning, so the advised restart had effectively just happened).

Confusing datapoint: scheduled tasks still fire on schedule despite the loop - a daily cron task on this machine has lastRunAt timestamps from the same days the loop was running. So either the VM is not actually required for task execution, or a second path starts it successfully while the ScheduledTasks tick keeps failing.

Impact: log noise that buries real errors (496 identical lines in 48 h), continuous background retry work while the app is idle, and a user-facing error message whose remedy (restart the computer) does not clear it.

Related smaller defects observed in the same subsystem, same machine:

  1. Ghost task entries. A one-time task whose SKILL.md had been deleted from disk stayed registered and produced ENOENT read failures on every scheduler tick (36 in 48 h): Failed to read task file for <task>: ENOENT ... .claude\scheduled-tasks\<task>\SKILL.md. Deleting the task through the scheduled-tasks MCP tool cleared it. Registration should not survive the task file's deletion, or should self-heal instead of retrying forever.
  1. Orphan legacy-path task. The scheduler also retries a task pointing at a legacy location (...\Claude\Scheduled\<task>\SKILL.md, folder does not exist) which does NOT appear in list_scheduled_tasks, so it cannot be removed through the MCP tools at all: Skipping scheduled task weekday-morning-brief: task file not found.
  1. Minor, possibly unrelated: [Chrome Extension MCP] Failed to copy native host binary: EBUSY: resource busy or locked (chrome-native-host.exe) fires on every app start, including starts that followed a fully clean onQuitCleanup quit. Does not block startup; constant noise.

Happy to provide sanitized log excerpts for any of these.

View original on GitHub ↗