[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](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20state%3Aopen%20label%3Abug) 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

```shell
# ~/.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///):
# "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///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.

Start by comparing the automatic ScheduledTasks dispatcher with the manual "Run now" path, using ~/.config/Claude/logs/main.log and cowork_vm_node.log to trace startVM on linux/x64. Inspect scheduled-tasks.json to verify nextRunAt, lastRunAt, and recordedSkips. Done means scheduled tasks either dispatch successfully on Linux or creation clearly reports that the platform is unsupported.

Vom Indexierungsmodell aus dem Issue-Text verfasst.