OpenClaw bug report — session cleanup falsely prunes fresh cron sessions

Date: 2026-03-18 22:20 America/Phoenix
Reporter: OpenClaw autonomous ops cycle
Project: Mission Control / session-store safety

Summary

openclaw sessions cleanup --dry-run --fix-missing is falsely classifying fresh cron sessions as missing-transcript entries, including the currently running autonomous cron session from 1 minute earlier.

This makes enforced cleanup unsafe because the store points some fresh sessions at a nonexistent sessionFile path even though the real transcript file exists on disk under the current session id.

Commands used

openclaw doctor
openclaw sessions cleanup --store ~/.openclaw/agents/main/sessions/sessions.json --dry-run --fix-missing

Reproduction evidence

1) Doctor sees missing transcripts while the latest cron sessions are fresh

• openclaw doctor reported:
  • 2/5 recent sessions are missing transcripts
  • Found 18 orphan transcript file(s) in ~/.openclaw/agents/main/sessions
• Session store summary showed the latest entries were only 1 minute old:
  • agent:main:cron:cecf2c4c-af82-445d-8ead-887414cc0c07 (1m ago)
  • agent:main:cron:cecf2c4c-af82-445d-8ead-887414cc0c07:run:c7e30496-7f45-4fa3-9682-a2f1be94b29c (1m ago)

2) Cleanup dry-run wants to prune the currently running cron session

Dry-run output:

• Entries: 446 -> 301 (remove 145)
• Would prune missing transcripts: 145
• first planned actions include:
  • prune-missing agent:main:cron:...cc0c07 1m ago
  • prune-missing agent:main:cron:...94b29c 1m ago

That means the cleanup tool is willing to prune both the parent cron session and its active run session almost immediately after creation.

3) The store entry points to the wrong transcript file

The affected entries in ~/.openclaw/agents/main/sessions/sessions.json contain:

• key: agent:main:cron:cecf2c4c-af82-445d-8ead-887414cc0c07
• key: agent:main:cron:cecf2c4c-af82-445d-8ead-887414cc0c07:run:c7e30496-7f45-4fa3-9682-a2f1be94b29c
• sessionId: c7e30496-7f45-4fa3-9682-a2f1be94b29c
• sessionFile: /Users/muhammedcam/.openclaw/agents/main/sessions/57b4e4c8-c5d9-47ec-8ba2-04a2ebafda28.jsonl
• that sessionFile path does not exist

4) The real transcript file exists under the current session id

Directory listing from ~/.openclaw/agents/main/sessions shows:

• c7e30496-7f45-4fa3-9682-a2f1be94b29c.jsonl
• c7e30496-7f45-4fa3-9682-a2f1be94b29c.jsonl.lock

So the transcript is present, but the store metadata is pointing at a stale or unrelated path:

• expected-ish file: .../c7e30496-7f45-4fa3-9682-a2f1be94b29c.jsonl
• actual stored path: .../57b4e4c8-c5d9-47ec-8ba2-04a2ebafda28.jsonl (missing)

Likely issue

The session store is sometimes persisting the wrong sessionFile for heartbeat/cron-backed sessions or run sessions. Cleanup then trusts that stale path and marks the session as missing, even when a valid transcript exists on disk under the session id.

Risk

Running enforced cleanup right now could delete valid fresh sessions from sessions.json, including active cron sessions, which would hide recent work and make dashboard/session history incomplete.

Safe next step

Do not run enforced cleanup until one of these is fixed:

1. session-store writes the correct sessionFile for cron/run sessions, or
2. cleanup falls back to checking <sessionId>.jsonl when the stored sessionFile is missing, or
3. cleanup ignores sessions that are currently locked / very recent when sessionFile mismatch is the only failure.

Suggested fix directions

• On session-store write/update, derive sessionFile from the actual active session id when available.
• In cleanup, if sessionFile is missing but sessionId exists, test for ~/.openclaw/.../<sessionId>.jsonl before pruning.
• Add a guard to never prune a live-locked session or a session updated within a short grace window.