Environment

• OpenClaw version: 2026.2.3-1
• OS: macOS (arm64, Darwin 25.2.0)
• Node: v25.5.0

Description

After a fresh gateway stop+start, the cron scheduler's internal timer fires correctly (verified via cron.status showing nextWakeAtMs advancing every minute), but runDueJobs does not execute any jobs after the very first auto-triggered run.

Steps to Reproduce

1. Create a simple test job:

openclaw cron add --name 'test-every-minute' --cron '* * * * *' --tz 'Asia/Shanghai' --session isolated --message 'Send a confirmation message' --delivery-mode none

2. Verify cron.status shows nextWakeAtMs is set correctly
3. Wait for the first trigger — it fires successfully
4. Wait for subsequent triggers — they never fire
5. cron.runs --id <jobId> shows only 1 entry (the first auto-fire)
6. openclaw cron run <jobId> --force works every time

Observed Behavior

• Gateway startup calls recomputeNextRuns, setting all jobs' nextRunAtMs to future times
• First timer fires and executes one due job successfully
• After that, timer continues to fire every minute (visible via cron.status nextWakeAtMs advancing)
• But runDueJobs finds zero due jobs each time
• The nextRunAtMs in jobs.json keeps getting pushed forward on each timer tick without any execution

Expected Behavior

Jobs should auto-fire on their schedule continuously, not just once after restart.

Source Analysis

Looking at gateway-cli-D_8miTjF.js:

• computeNextRunAtMs for every type: uses schedule.anchorMs ?? nowMs as anchor, so without anchorMs it always computes now + everyMs (always in the future)
• onTimer → runDueJobs filters jobs where now >= nextRunAtMs, but if nextRunAtMs was recomputed to future during a previous tick's persist() call, the job is never due
• The cron expression type (* * * * *) exhibits the same behavior, so it's not specific to every type

Workaround

Using heartbeat polling (HEARTBEAT.md) as a replacement for cron-scheduled tasks.

Additional Context

• maxConcurrentRuns is default (1)
• Heartbeat interval: 5 minutes
• All jobs use wakeMode: next-heartbeat
• 24 enabled jobs in the store
• The issue persists across full stop+start cycles (not just SIGUSR1 restarts)