Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

openclaw tasks audit can report a cron task as lost with backing session missing even when the cron run history shows that same job run finished successfully.

In this state:

• openclaw status shows a task audit error
• openclaw tasks maintenance --apply does not clear it
• the cron job itself continues to run successfully afterward

So task registry state and cron run history disagree, and maintenance cannot reconcile the stale lost row.

Steps to reproduce

I hit this live on OpenClaw 2026.4.8 on Linux arm64 (Raspberry Pi, systemd gateway).

1. Run:

openclaw status --deep

Observed task health summary included:

Tasks: 0 active · 0 queued · 0 running · 11 issues · audit 1 error · 219 warn · 330 tracked

2. Run:

openclaw tasks audit

Observed:

Tasks audit: 222 findings · 1 errors · 221 warnings
Task findings: 220 · TaskFlow findings: 2
Task     error    lost  55aad356-…  lost  1h12m  backing session missing

3. Check the task store directly:

sqlite3 ~/.openclaw/tasks/runs.sqlite \
  ".headers on" \
  ".mode column" \
  "select task_id,runtime,source_id,label,status,delivery_status,datetime(created_at/1000,'unixepoch','localtime') as created_local,datetime(started_at/1000,'unixepoch','localtime') as started_local,datetime(last_event_at/1000,'unixepoch','localtime') as last_event_local,datetime(ended_at/1000,'unixepoch','localtime') as ended_local,child_session_key from task_runs where status='lost' order by created_at desc limit 5;"

Observed row:

task_id                               runtime  source_id                             label                        status  delivery_status  created_local        started_local        last_event_local     ended_local          child_session_key
55aad356-acb8-47bf-8798-44c12796fdcd  cron     049dcc9c-a957-4ed8-94d2-a44ce08b36b1  hourly-memory-summarizer-v2  lost    not_applicable   2026-04-08 21:08:06  2026-04-08 21:08:06  2026-04-08 21:19:59  2026-04-08 21:19:59

4. Check cron run history for that source_id job:

# source_id from the lost row above
openclaw cron runs 049dcc9c-a957-4ed8-94d2-a44ce08b36b1

Observed most recent run:

{
  "jobId": "049dcc9c-a957-4ed8-94d2-a44ce08b36b1",
  "action": "finished",
  "status": "ok",
  "runAtMs": 1775657101113,
  "durationMs": 59341,
  "sessionId": "5cea71a5-f2c8-45c1-a3b1-cbe779df3cb3",
  "sessionKey": "agent:summarizer-agent:cron:049dcc9c-a957-4ed8-94d2-a44ce08b36b1:run:5cea71a5-f2c8-45c1-a3b1-cbe779df3cb3"
}

5. Try built-in repair:

openclaw tasks maintenance --apply

Observed:

Tasks maintenance (applied): tasks 0 reconcile · 0 cleanup stamp · 0 prune; task-flows 0 reconcile · 0 prune
Tasks health after apply: 0 queued · 0 running · 1 audit errors · 221 audit warnings
Tasks health before apply: 1 audit errors · 221 audit warnings

Expected behavior

If cron run history records the run as finished + ok, task audit should not still surface a lost task error for the same logical run.

At minimum, openclaw tasks maintenance --apply should reconcile or prune this stale lost row so audit returns 0 errors.

Actual behavior

A lost task row remains in ~/.openclaw/tasks/runs.sqlite and continues to trigger:

• task/lost
• backing session missing

This happens even though cron run history shows successful completion for the same job, and maintenance does not clear it.

OpenClaw version

2026.4.8

Operating system

Linux 6.12.62+rpt-rpi-2712 (arm64)

Install method

pnpm

Model

openai-codex/gpt-5.4

Provider / routing chain

openclaw -> openai-codex

Additional provider/model setup details

Gateway service via systemd on Raspberry Pi.

Logs, screenshots, and evidence

# audit
Tasks audit: 222 findings · 1 errors · 221 warnings
Task findings: 220 · TaskFlow findings: 2
Task     error    lost  55aad356-…  lost  1h12m  backing session missing

# lost row in sqlite
task_id                               runtime  source_id                             label                        status  delivery_status  created_local        started_local        last_event_local     ended_local          child_session_key
55aad356-acb8-47bf-8798-44c12796fdcd  cron     049dcc9c-a957-4ed8-94d2-a44ce08b36b1  hourly-memory-summarizer-v2  lost    not_applicable   2026-04-08 21:08:06  2026-04-08 21:08:06  2026-04-08 21:19:59  2026-04-08 21:19:59

# maintenance cannot clear it
Tasks maintenance (applied): tasks 0 reconcile · 0 cleanup stamp · 0 prune; task-flows 0 reconcile · 0 prune
Tasks health after apply: 0 queued · 0 running · 1 audit errors · 221 audit warnings
Tasks health before apply: 1 audit errors · 221 audit warnings

Impact and severity

Severity: Low to Medium

The system still works, but status/audit become noisy and misleading:

• operators see a real audit error even though the cron job is actually succeeding
• built-in maintenance cannot repair it
• stale rows may accumulate and hide real task-health problems

Additional information

This seems related to the broader task-registry/task-maintenance bookkeeping issues around cron/CLI rows, but this specific symptom is different from stale running rows.

Here the row is already terminal (lost) with timestamps populated, while cron history independently says the run finished ok.

So either:

1. task-run creation/finalization is producing duplicate/conflicting rows for one cron run, or
2. task audit/maintenance is matching the wrong backing-session expectations for cron runs after completion, or
3. cron run completion and task-registry cleanup are not using the same source of truth.