[BUG] Linux desktop: local scheduled tasks never auto-fire — dispatch blocked by "VM not supported (linux/x64)" (manual Run now works)

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?

This is a Claude Desktop (Cowork scheduled tasks) bug observed on Linux, filed here because desktop/Cowork issues are tracked in this repo (cf. #87252, #44129).

On Linux, locally scheduled tasks are NEVER fired automatically — not even once. Schedule bookkeeping works (nextRunAt keeps advancing every minute), and clicking "Run now" executes the task successfully, but automatic dispatch never happens.

Logs show why: the ScheduledTasks dispatcher gates dispatch on the Cowork VM being ready, and on linux/x64 startVM is a silent no-op ("VM not supported"), so the dispatcher waits forever for a VM that can never come up. main.log shows the tick loop running every minute with "VM not ready (tick N), requesting startVM" continuously since the scheduler first initialized (2 days, across app restarts), and cowork_vm_node.log shows every request refused with "[startVM] VM not supported (linux/x64), skipping". At scheduled fire times there is no dispatch/fire/skip log at all, and recordedSkips in scheduled-tasks.json stays empty — the misses are completely silent. Sleep/suspend is ruled out (journalctl shows none in the affected windows).

Why this looks like a dispatch-path bug rather than an intended platform limitation:

1. Manual "Run now" executes the same task WITHOUT any VM (via a local agent-mode session). Task execution does not require the VM — only the automatic dispatch path is gated on it. The two paths are inconsistent.
2. On Windows, #87252 shows the exact same "VM not ready (tick N), requesting startVM" loop, but there startVM fails with a real error ("VM service not running") and scheduled tasks still fire. On Linux the "unsupported, skipping" silent no-op apparently leaves the dispatcher waiting forever — the hard block seems Linux-specific.
3. If Linux were intentionally unsupported, task creation should be blocked or warned about. Instead the UI lets you create tasks and shows a healthy advancing nextRunAt while nothing ever runs.

Settings are correct: ccdScheduledTasksEnabled: true and coworkScheduledTasksEnabled: true in claude_desktop_config.json (verified — this is not #61648). CLAUDE_CONFIG_DIR is not set.

What Should Happen?

Either (a) automatic dispatch should use the same VM-less local path that "Run now" uses on platforms where the Cowork VM is unavailable (so tasks fire on Linux just like manual runs do), or (b) scheduled-task creation on those platforms should fail loudly / warn the user that tasks will never fire. Silent permanent non-firing with a healthy-looking UI is the worst of both.

Error Messages/Logs

# ~/.config/Claude/logs/main.log — tick loop runs every minute; VM has NEVER been ready in any session:
2026-08-22 20:39:39 [info] [ScheduledTasks] VM not ready (tick 1), requesting startVM
2026-08-22 20:43:39 [info] [ScheduledTasks] VM not ready (tick 5), requesting startVM
... (continues every 5 ticks, across app restarts, for 2 days) ...
2026-08-24 20:40:19 [info] [ScheduledTasks] VM not ready (tick 450), requesting startVM
2026-08-24 20:45:19 [info] [ScheduledTasks] VM not ready (tick 455), requesting startVM

# ~/.config/Claude/logs/cowork_vm_node.log — every startVM request refused as unsupported:
2026-08-24 20:45:19 [warn] [startVM] VM not supported (linux/x64), skipping
2026-08-24 20:50:19 [warn] [startVM] VM not supported (linux/x64), skipping

# The only "run" entries correspond exactly to manual "Run now" clicks:
2026-08-24 20:39:41 [info] [ScheduledTasks] Confirmed task run for: local-pc-health-check2

# scheduled-tasks.json (~/.config/Claude/local-agent-mode-sessions/<account>/<org>/):
#   "cronExpression": "* * * * *", "enabled": true,
#   "lastRunAt": "2026-08-24T11:39:41.455Z"   <- the manual run above; never advanced by the scheduler
#   "recordedSkips": {}                        <- misses not even recorded as skips

Steps to Reproduce

1. On a Linux machine (Ubuntu 26.04 x86_64, Wayland), install Claude Desktop 1.34493.1 from the apt stable channel and sign in.
2. Create a local scheduled task with cron * * * * *, jitter 0, enabled. (Any schedule reproduces it — a daily task missed every day too.)
3. Wait. Observed 13+ minutes = 13+ consecutive missed fires: the task never runs, lastRunAt stays fixed while nextRunAt advances every minute.
4. Click "Run now" — the task executes fine (this is what lastRunAt reflects).
5. Check ~/.config/Claude/logs/main.log and cowork_vm_node.log: every minute "VM not ready (tick N), requesting startVM" followed by "[startVM] VM not supported (linux/x64), skipping". No dispatch/fire/skip entry ever appears at scheduled times.

Claude Model

Opus

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

Claude Desktop 1.34493.1 (apt stable); bundled CLI 2.1.241 (Claude Code)

Platform

Anthropic API

Operating System

Ubuntu/Debian Linux

Terminal/Shell

Other

Additional Information

• This is a Claude Desktop / Cowork scheduled-tasks issue, not a terminal/CLI issue — the Terminal field above is "Other" for that reason.
• Related issues:
• #87252 — same "VM not ready / requesting startVM" loop on Windows, but tasks still fire there (key contrast suggesting the hard block is Linux-specific)
• #44129 — same user-visible symptom (auto never fires, manual works) on macOS, attributed to wakeScheduler:unavailable; closed not-planned/stale
• #73568 / #77348 / #75375 / #84243 / #80884 — the underlying "Cowork VM not supported on Linux" family
• #61648 — ruled out here (ccdScheduledTasksEnabled is true while the symptom occurs)
• Duplicate search done before filing: "VM not supported" + scheduled, "linux/x64" + schedul, and platform:linux + never-fires queries all return zero results connecting the VM gate to scheduled-task non-firing.
• Docs also point to ~/.claude/scheduled-tasks/ while the implementation actually uses ~/Claude/Scheduled/ (task SKILL.md files) + ~/.config/Claude/local-agent-mode-sessions/<account>/<org>/scheduled-tasks.json (registry).
• Workaround verified on the affected machine: systemd user timers + headless CLI (claude -p --chrome ... in a oneshot service) fully replace local scheduled tasks on Linux, including Chrome-extension browsing with the logged-in profile.
• Happy to provide fuller (sanitized) logs on request.