Bug Description

After a gateway restart (via update or manual restart), the cron scheduler sets nextWakeAtMs to an incorrect future time, causing all scheduled jobs between the restart time and the next calculated wake time to be skipped.

Environment

• OpenClaw Version: 2026.2.3-1 (d84eb46)
• OS: macOS (Darwin 25.2.0, arm64)
• Node: v25.4.0

Steps to Reproduce

1. Have multiple cron jobs scheduled throughout the day (e.g., hourly dispatcher, daily jobs at 02:00, 03:30, 06:00, 07:00)
2. Update gateway via gateway(action="update.run") or manually restart the openclaw process
3. Check cron status after restart

Expected Behavior

After gateway restart, the cron scheduler should:

1. Recalculate nextWakeAtMs based on current time
2. Find the next scheduled job from NOW
3. Set nextWakeAtMs to that job's scheduled time

Actual Behavior

After gateway restart at 23:37:53 on Feb 5:

• Scheduler set nextWakeAtMs to 09:00 on Feb 6
• All jobs scheduled between 00:00 and 09:00 were skipped:
  • clickup-dispatcher (hourly): missed 9 runs (00:00, 01:00, ... 08:00)
  • night-learning-mode (02:00): skipped
  • prayer-scheduler-daily (03:30): skipped
  • GuardTrail Security Scan (06:00): skipped
  • morning-digest-combined (07:00): skipped

Evidence

# Cron status after restart
{
  "enabled": true,
  "jobs": 24,
  "nextWakeAtMs": 1770343200000  // Feb 6 09:00 WIB
}

# Process start time
Thu Feb  5 23:37:53 2026

# Jobs that should have run:
clickup-dispatcher:
  Schedule: 0 * * * *
  Last run: 2026-02-05 23:01
  Next run: 2026-02-06 09:00  <-- Should be 00:00, not 09:00!
  Hours since last: 9.8
  Expected runs missed: ~9

Workaround

Created a self-healing cron job that periodically checks for stale jobs and triggers manual recovery.

Impact

High - Critical daily automation jobs (security scans, digests, monitoring) can be silently skipped after any gateway restart, with no automatic recovery or alerting.

Suggested Fix

In the cron scheduler initialization (after process start):

1. For each enabled job, calculate the correct nextRunAtMs based on schedule.expr and current time
2. Update nextWakeAtMs to the minimum of all calculated next run times
3. Consider adding a "catch-up" mode for jobs that should have run during downtime