Summary

When an active session is reset/rotated, the prior transcript may still exist on disk as a *.jsonl.reset.* archive, but the session tools (sessions_history, sessions_list) do not surface that prior context chain. If later system exec-completion messages arrive in a fresh session and the user says "continue", the assistant can fail to recover the original context even though the transcript still exists locally.

This caused a real failure today: I initially told the user I couldn't determine what to continue, but the prior context was still recoverable from the reset archive.

Impact

• Breaks continuity after prompt errors / fetch failures / session resets
• Causes false "context lost" responses even when the transcript still exists
• Makes system exec completion notifications (Exec completed, Exec failed) hard to interpret because they land in a fresh session with no visible parent context
• Forces brittle manual forensic recovery through raw files instead of first-class tools

Evidence from this incident

1) Fresh oversight session looked contextless through sessions_history

Current session file:

• /Users/octavi/.openclaw-cleanroom/agents/main/sessions/90d86798-55ff-45fd-8495-da96419583e7.jsonl

Tool output captured in that session shows:

• sessions_history(sessionKey="agent:main:oversight", limit=20) returned only the fresh messages
• response had truncated: true, contentTruncated: true, bytes: 2614
• it did not indicate there was a prior reset archive containing the actual working context

Relevant line in the current transcript:

• .../90d86798-55ff-45fd-8495-da96419583e7.jsonl line 11

2) The real context still existed in a reset transcript archive

Reset archive:

• /Users/octavi/.openclaw-cleanroom/agents/main/sessions/572d0ce2-1eb5-4413-911c-77bad482a3ef.jsonl.reset.2026-03-28T02-40-51.286Z

That reset archive contains the prior oversight session, including:

• successful Mentat local deployment work
• discovery run completion
• later continue turns
• subsequent validation progress
• prompt errors and fetch failures preceding the reset

Examples:

• line 229: openclaw:prompt-error ... error: "aborted"
• line 230: later system exec completion messages are still attached to that prior flow
• lines 234-238: repeated fetch failed assistant errors
• line 237: user says continue
• line 243 onward: assistant resumes the prior discovery/leader validation work

3) What I initially missed

Because the tool-visible session history only showed the fresh session, I initially concluded the context was gone. In reality, the context was preserved in the reset archive and only became recoverable after raw file inspection.

Probable root cause

OpenClaw appears to preserve rotated session transcripts on disk, but the session retrieval layer does not expose the reset/archive chain as part of the logical session.

More specifically, there seems to be a mismatch between:

1. physical session storage

   • prior transcript still exists as *.jsonl.reset.*

2. logical session retrieval

   • sessions_history(sessionKey=...) only returns the latest active fragment
   • no hint that earlier archived fragments exist

3. system event routing

   • exec completion notifications may arrive in the fresh fragment without enough provenance to reconstruct the originating work context

Why this is bad

The assistant did the reasonable thing with the available API surface and still got the wrong answer. That means this is not just a model mistake; the retrieval surface is materially hiding valid context.

Expected behavior

At least one of these should happen:

1. sessions_history for a logical session key should follow reset/archive chains automatically and return prior fragments in order
2. sessions_history should include metadata such as:
   • previousFragments
   • resetArchives
   • continuationOf
   • archivedMessagesAvailable: true
3. system exec completion messages should carry enough provenance to resolve back to the originating transcript fragment / run / session
4. a first-class tool/API should exist for "recover previous session fragment(s) for this logical session"

Repro sketch

1. Start a long-running session that launches background exec jobs
2. Trigger a prompt error / fetch failure / reset condition so the session rotates into *.jsonl.reset.*
3. Let system exec completion messages arrive afterward
4. In the fresh session, ask the assistant to continue
5. Observe that sessions_history(sessionKey=...) may only show the fresh fragment and hide the archived one
6. Observe that manual raw-file inspection can still recover the missing context

Proposed fix

Retrieval layer

• Treat reset archives as part of the same logical session chain
• Add an option like includeArchived=true / followResets=true to sessions_history
• Prefer making this default for same-session recovery flows

Session metadata

• Persist a durable chain pointer between fragments, e.g.:
  • previousSessionId
  • resetFromSessionId
  • logicalSessionKey
  • archiveReason

UX / tooling

• When sessions_history is truncated and archived fragments exist, return explicit metadata saying so
• Add a first-class recovery command/tool for locating prior fragments instead of requiring raw file spelunking

Event provenance

• Exec completion notifications should include an origin reference to the session/run that launched them so they remain understandable after a reset

Acceptance criteria

• Given a logical session that has been reset, sessions_history(sessionKey=...) can recover prior fragments without raw file inspection
• If history is still truncated, the response explicitly says archived fragments exist and how to retrieve them
• A user saying "continue" after a reset can be correctly resumed from tool-visible context
• Exec completion notifications can be tied back to their originating work context even across session resets

Notes

This is distinct from normal truncation. The key bug is that valid context remained on disk but was effectively undiscoverable through the supported session tools, which directly caused a wrong user-facing answer.