Problem
When a session is reset via /new or daily auto-reset, the old session transcript is archived as a .jsonl.reset.* file on disk. However, the sessions_history tool only returns history for the current active session. There is no agent-facing tool to read archived session transcripts.
This creates two problems:
1. Agents lose access to recent conversation history after session rotation
After /new, an agent calling sessions_history gets nothing from the previous session. If the agent didn't write memory files during the conversation (e.g., because compaction failed and the context was too large for a memory flush), the conversation content is effectively lost to the agent — even though it's fully intact in the archived JSONL file.
2. Sandboxed agents can't mine their own session history
Session transcripts live at ~/.openclaw/agents/<agentId>/sessions/, which is outside the agent workspace. Sandboxed agents can't access this path via filesystem tools. Non-sandboxed agents can read the raw JSONL with absolute paths, but this is fragile and undocumented.
This matters for use cases like:
- Knowledge base maintenance — mining past conversations for entity mentions, decisions, and relationship changes
- Memory recovery — reconstructing memory files after a failed flush or compaction
- Session continuity — recalling recent context that was discussed before a reset
Proposed Solution
Extend sessions_history (or add a new tool like sessions_list_archived) to support:
- Listing archived sessions for the current agent (with timestamps and sizes)
- Reading history from a specific archived session by session ID or relative index (e.g., "previous session")
This would work within the existing sandboxing model — the Gateway mediates access, so sandboxed agents get their own session history without filesystem escape.
Workaround
Non-sandboxed agents can read raw JSONL files at ~/.openclaw/agents/<agentId>/sessions/*.jsonl.reset.* using absolute paths. Sandboxed agents have no workaround — they must rely on memory files as the sole source of past conversation context.
Context
Discovered while investigating a 3.1MB session bloat where compaction didn't fire (fixed in 2026.3.13-1). The agent's memory flush never ran, /new archived the session, and the agent woke up with no recollection of the previous day's conversations. The data was on disk but inaccessible through agent tools.
Problem
When a session is reset via
/newor daily auto-reset, the old session transcript is archived as a.jsonl.reset.*file on disk. However, thesessions_historytool only returns history for the current active session. There is no agent-facing tool to read archived session transcripts.This creates two problems:
1. Agents lose access to recent conversation history after session rotation
After
/new, an agent callingsessions_historygets nothing from the previous session. If the agent didn't write memory files during the conversation (e.g., because compaction failed and the context was too large for a memory flush), the conversation content is effectively lost to the agent — even though it's fully intact in the archived JSONL file.2. Sandboxed agents can't mine their own session history
Session transcripts live at
~/.openclaw/agents/<agentId>/sessions/, which is outside the agent workspace. Sandboxed agents can't access this path via filesystem tools. Non-sandboxed agents can read the raw JSONL with absolute paths, but this is fragile and undocumented.This matters for use cases like:
Proposed Solution
Extend
sessions_history(or add a new tool likesessions_list_archived) to support:This would work within the existing sandboxing model — the Gateway mediates access, so sandboxed agents get their own session history without filesystem escape.
Workaround
Non-sandboxed agents can read raw JSONL files at
~/.openclaw/agents/<agentId>/sessions/*.jsonl.reset.*using absolute paths. Sandboxed agents have no workaround — they must rely on memory files as the sole source of past conversation context.Context
Discovered while investigating a 3.1MB session bloat where compaction didn't fire (fixed in 2026.3.13-1). The agent's memory flush never ran,
/newarchived the session, and the agent woke up with no recollection of the previous day's conversations. The data was on disk but inaccessible through agent tools.