Local installs have no WP-Cron/Action Scheduler heartbeat — Data Machine queue starves on headless Studio sites

[chubes4]

Problem

On a headless local Studio install (no browser traffic), WP-Cron never fires — it is HTTP-triggered. Observed on a production intelligence install on 2026-07-12: every cron event overdue since 2026-06-22 (wp cron event list shows action_scheduler_run_queue next-run 2026-06-22 23:06, all core events similarly frozen), 36 due Data Machine actions starved, the nightly datamachine_recurring_workspace_retention_cleanup recurrence pending for 20 days, and system-task jobs (e.g. a Workspace Retention Cleanup job with a valid pending datamachine_execute_step action) parked in pending indefinitely. The queue only advanced when an agent session happened to run wp datamachine worker run/drain by hand — the last job completion coincided with a manual CLI session, not the scheduler.

wp-coding-agents already owns the service layer for these installs: it provisions launchd (macOS) and systemd (VPS) services for chat bridges (kimaki, cc-connect, telegram) via setup.sh/upgrade.sh and bridge templates. But nothing provisions a scheduler heartbeat, so the substrate the bridges depend on (Data Machine jobs, retention, recurring flows, wiki maintenance) silently starves between agent sessions.

Fix shape

Provision a queue heartbeat service alongside the bridge services, per detected environment:

• macOS local: a launchd agent (e.g. com.wp.datamachine-worker.plist) running a bounded loop on an interval — e.g. wp datamachine worker run --once (or a small --time-limit) every 1–5 minutes per registered site.
• VPS: the systemd timer equivalent.
• Managed by setup.sh/upgrade.sh like the existing bridge services (install, adopt, restart on upgrade), with the same identity-adoption handling the bridge services already have.
• Multi-site aware: iterate registered sites (or accept a site list) rather than hardcoding one path.

Data Machine's worker run is already designed as the safe external entrypoint (bounded, composes stuck-recovery + drain, lane-locked), so the service is a thin invoker — no new runtime semantics needed.

Related: Extra-Chill/data-machine#2889 (worker health should surface stale Action Scheduler dispatcher state so this failure mode is visible instead of silent).

How to verify

1. Fresh local Studio site with wp-coding-agents setup complete; do not open the site in a browser.
2. wp cron event list — without the fix, action_scheduler_run_queue next-run drifts into the past and stays there.
3. Schedule any Data Machine system task; observe it stuck pending.
4. With the heartbeat service installed: the due actions process within one interval and wp datamachine jobs liveness reports no scheduler starvation.

AI assistance

• AI assistance: Yes
• Tool(s): Claude (Opus 4.5) via Kimaki/OpenCode
• Used for: Root-cause diagnosis from live cron/queue evidence and issue drafting