[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.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.