Bug type

Behavior bug (incorrect output/state without crash)

Summary

Issue: openclaw cron run returns enqueued: true with a new runId, but openclaw cron runs --id does not show a new finished entry (only old runs).
Affected job: 948faf38-7992-4172-aa63-0df4c923b120 (lifeos-whatsapp-daily-summary)
Job config: sessionTarget=main, payload.kind=systemEvent, enabled=true
Version: OpenClaw 2026.3.8 (3caab92)
Reproducible: Yes, even after cron disable -> gateway restart -> cron enable -> cron run
Evidence: New runId is returned each time, but cron runs history remains unchanged (total does not increase).

Steps to reproduce

1. Ensure job is enabled and configured as main/systemEvent:
   sessionTarget: main
   payload.kind: systemEvent
2. Trigger manual run:
   openclaw cron run 948faf38-7992-4172-aa63-0df4c923b120
3. Wait ~5–10 seconds
4. Check history:
   openclaw cron runs --id 948faf38-7992-4172-aa63-0df4c923b120 --limit 3

Expected behavior

After running openclaw cron run , a new entry should appear in:
openclaw cron runs --id --limit 3
with a new finished record (ok or error)

Actual behavior

Manual run accepted:
runId: manual:948faf38-7992-4172-aa63-0df4c923b120:1773260687574:1
cron runs still returns only old entries (timestamps around 1773259078645 and 1773171036019), total unchanged.
This persists after:
openclaw cron disable ...
openclaw gateway restart
openclaw cron enable ...
running again

OpenClaw version

OpenClaw 2026.3.8 (3caab92)

Operating system

macOS 15.7.1

Install method

No response

Model

openai-codex/gpt-5.3-codex

Provider / routing chain

CLI (openclaw cron run) → Gateway (LaunchAgent) → Cron scheduler → main session (systemEvent payload)

Config file / key location

No response

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

We previously switched this job from isolated/agentTurn to main/systemEvent due to access restrictions.
Current config is valid (enabled=true, sessionTarget=main, payload.kind=systemEvent).
Behavior suggests a run-persistence/history tracking issue rather than a validation/config issue.