openclaw - 💡(How to fix) Fix cron: `deleteAfterRun: true` is ignored for schedule.kind="every" — job runs indefinitely

Summary

A cron job created with deleteAfterRun: true and schedule.kind: "every" is not removed after its first execution. It keeps firing on every interval indefinitely, until manually deleted from ~/.openclaw/cron/jobs.json (or via the CLI).

In one of my deployments this caused a substantial unintended LLM spend before I noticed: a self-scheduled "check status" reminder fired ~250 times over ~2.5 days. Each tick triggered an embedded agent run that re-sent the full session history to the model, so each ping cost as much as a heavy turn rather than a small one. (The cost-amplification side is filed as a separate issue.)

Reproduction

1. Create a cron job either via openclaw cron add ... or directly in ~/.openclaw/cron/jobs.json with a shape like:

   ```json { "id": "...", "enabled": true, "deleteAfterRun": true, "schedule": { "kind": "every", "everyMs": 60000, "anchorMs": <now> }, "payload": { "kind": "systemEvent", "text": "ping" }, "delivery": { "mode": "none" } } ```

2. Wait more than `everyMs`.

3. Observed:

   • `state.lastRunAtMs` advances.
   • `state.nextRunAtMs` is recomputed.
   • The job fires again on the next tick.
   • After N runs the job is still present in the store.

4. Expected (per the flag name): the job is removed from the store after the first successful run.

`schedule.kind: "cron"` and `"at"` deleteAfterRun behavior was not checked here — this report is specifically about `kind: "every"`.

Environment

• openclaw v2026.4.8
• Linux, user-systemd unit
• gateway hot-reload caches the in-memory store and writes back on save, which makes manual edits to `jobs.json` tricky — but that is independent of the underlying bug.

Suggested resolution

Either honor `deleteAfterRun` uniformly across schedule kinds in the post-run code path, or document that `every` ignores the flag and reject the combination at job creation with a clear error, so users do not rely on it.