openclaw - 💡(How to fix) Fix sessions_history is blind to rotated transcripts after `truncateAfterCompaction: true`

Summary

With agents.defaults.compaction.truncateAfterCompaction: true (default), sessions_history reads only the active (post-rotation) JSONL and returns near-empty results even when the archived (pre-rotation) transcript still exists on disk. This makes self-recovery from compaction loss impossible — the agent sees an empty session even though the prior context is recoverable.

Filed as a standalone follow-up to the bonus section of #78911 ("Happy to file separately if preferred").

Repro

1. Long-running Discord channel session with compactions enabled
2. Wait for a compaction cycle — truncateAfterCompaction: true rotates the active JSONL
3. Call sessions_history for that session

Result:

truncated: true
contentTruncated: true
bytes: 634          // 2 messages
droppedMessages: false

…on a session whose pre-rotation transcript on disk is 43+ KB:

$ ls -la ~/.openclaw/agents/main/sessions/<old-id>.jsonl
-rw------- 1 user staff 44103 May 14 03:17 <old-id>.jsonl

The data still exists, but sessions_history cannot see it.

Why this matters

This is the largest single contributor to Discord channel sessions "feeling fresh" in our deployment. The chain is:

1. Compaction model produces a summary (sometimes empty, see #78911 for the related compaction-quality issue)
2. Transcript rotates
3. Any subsequent sessions_history call (recovery, debugging, sub-agent context, post-compaction memory rebuild) returns the post-rotation tail only
4. The agent has no way to recover the lost context without manual disk archaeology

When compaction summaries are good (~80%+ after the #78911-related sonnet-4-6 switch), this is annoying. When compaction summaries are bad ("(none)" placeholders), it's catastrophic — the active transcript and the summary are both empty, and the archived transcript that would answer the question is invisible to the tool.

Proposed fix

sessions_history (and equivalent in agent SDK) should accept a fallback strategy when the active transcript has fewer than N messages or fewer than N bytes:

Option A — Implicit fallback:

• If active JSONL contains fewer than minActiveMessages entries (default e.g. 5), automatically read the most recent rotated JSONL in the same session directory and concatenate (or return as archivedContent field).

Option B — Explicit opt-in:

• Add includeArchived: boolean (default false) and archivedLookback: integer (default 1) parameters.
• When set, walk back through <old-session-id>.jsonl files in the session directory in mtime order.

Option C — Symlink-based:

• Keep a stable latest.jsonl symlink that points at the active file, and a previous.jsonl symlink to the most recently rotated one. Lets external tools find both without an SDK change.

Option B is probably safest (no surprise data exposure, explicit caller intent).

Workaround

Currently: manually cat ~/.openclaw/agents/<agent>/sessions/<old-id>.jsonl | jq — which the agent doing the recovery can't do without raising the user's trust ceiling on exec.

Environment

• OpenClaw 2026.5.16-beta.1 (also reproduced on 2026.4.26, 2026.5.12)
• macOS arm64, Node v26.0.0
• Discord channel sessions, truncateAfterCompaction: true (default)
• keepRecentTokens: 120000, mode: safeguard, compaction model claude-sonnet-4-6

Related

• #78911 — config.patch protected paths (this is the standalone follow-up to the bonus section)
• PR #82225 (merged) — fixed the upstream Discord WS stale-HELLO race that was compounding compaction-loss visibility, but doesn't address this archive-blindness root issue.