Summary

openclaw tasks maintenance --apply reports 0 reconcile · 0 recovered · 0 cleanup stamp · 0 prune even when openclaw tasks audit reports lost and stale_running errors. These records are exactly what an operator would expect maintenance to clean.

Reproduction

On a long-lived install with the default 5-day session cleanup running:

$ openclaw tasks audit
... 22 errors (20× lost, 2× stale_running), 1204 warnings (all inconsistent_timestamps)

$ openclaw tasks maintenance --apply
Tasks maintenance (applied): tasks 0 reconcile · 0 recovered · 0 cleanup stamp · 0 prune; task-flows 0 reconcile · 0 prune
Tasks health after apply: 22 audit errors · 1204 audit warnings  (unchanged)

Sample lost-record audit detail:

{
  "kind": "task",
  "severity": "error",
  "code": "lost",
  "detail": "backing session missing",
  "ageMs": 406998939,
  "status": "lost",
  ...
  "task": {"runtime": "cron", ...}
}

These are tasks whose backing session JSONL was archived/removed by the 5-day Session & Cache Cleanup cron, but the task record itself persists indefinitely. With heavy cron usage the task store accumulates (this install has 2,556 task records; expected steady-state would be much smaller).

Suggested fix

• tasks maintenance --apply should prune (or at least mark and prune after a grace period) task records whose backing session is gone and whose status is lost.
• inconsistent_timestamps warnings (startedAt < createdAt — almost always benign clock skew) could be auto-corrected by clamping startedAt to createdAt when the delta is below a threshold.

Why it matters

Without this, the audit count grows unboundedly over time and operators have to bypass the supported tooling (direct DB/file edits) to reset the picture, or live with audit reports showing growing error counts that don't reflect real failures.

Environment

• OpenClaw 2026.4.24 (cbcfdf6)
• Darwin 25.3.0 / arm64 / node v25.9.0