Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

Summary

sessions_history can report that a WebChat session has no earlier history, even though older turns for the same visible dashboard conversation still exist locally in prior/reset transcript files.

This looks related to reset/archive/family-session handling: the active session transcript is returned, but older transcripts with the same visible WebChat/dashboard session key are not surfaced by sessions_history.

No private user data is included below. Session IDs, paths, and prompts are sanitized.

What happened

A user asked to view earlier messages from the current WebChat session before the current day.

The agent called sessions_history for the visible WebChat session key:

{
  "sessionKey": "<webchat-dashboard-session-key>",
  "limit": 200,
  "includeTools": false
}

sessions_history returned only the current active transcript, starting with the first message in <current-session-id>.jsonl.

However, searching local session files showed that the same visible dashboard session key appeared in multiple trajectory files:

<old-session-id-1>.trajectory.jsonl
<old-session-id-2>.trajectory.jsonl
<current-session-id>.trajectory.jsonl

The previous session transcript had been rotated into a reset archive:

<sessions-dir>/<old-session-id-2>.jsonl.reset.<timestamp>Z

An older prior transcript also existed as:

<sessions-dir>/<old-session-id-1>.jsonl.reset.<timestamp>Z

Those older files contained prior user turns for the same visible WebChat/dashboard conversation, but sessions_history did not include them.

Evidence from local investigation

Sanitized structure observed:

Current visible session key:
<webchat-dashboard-session-key>

Current active transcript:
<sessions-dir>/<current-session-id>.jsonl

Prior transcript archived at current session start:
<sessions-dir>/<old-session-id-2>.jsonl.reset.<timestamp>Z

Older prior transcript archived at previous session start:
<sessions-dir>/<old-session-id-1>.jsonl.reset.<timestamp>Z

The same <webchat-dashboard-session-key> appeared in the corresponding .trajectory.jsonl files for all three session IDs.

sessions.json only mapped the visible session key to the current active session ID.

Related issues / PRs

This appears to match or overlap with:

• [Feature]: Script to restore session history archived by new daily-reset mechanism (introduced v2026.2+) #45003 — [Feature]: Script to restore session history archived by new daily-reset mechanism
• [AI-assisted] Add session history family lookup #90239 — Add session history family lookup
• feat(session): add includeArchived to chat.history and sessions_history #73883 — feat(session): add includeArchived to chat.history and sessions_history
• fix(sessions): fall back to latest reset archive for missing async transcripts #76134 — fix(sessions): fall back to latest reset archive for missing async transcripts

Related closed issues that appear relevant:

• sessions_history should support reading archived/reset sessions #57139 — sessions_history should support reading archived/reset sessions
• Bug: session reset archives are not discoverable via sessions_history, breaking context recovery after reset #56131 — Bug: session reset archives are not discoverable via sessions_history, breaking context recovery after reset
• Session history not listed in UI after /new or /reset #42336 — Session history not listed in UI after /new or /reset
• [Bug]: WebChat session silently resets on first message after daily 4 AM boundary — stale canReuseSession renames transcript to .jsonl.reset.* with no warning #88991 — WebChat session silently resets on first message after daily 4 AM boundary
• WebChat Control UI auto-archives sessions with action:new senderId:unknown — loses context without user action #89760 — WebChat Control UI auto-archives sessions with action:new senderId:unknown
• [Feature Request]: Auto-pull recent session context on daily reset #82334 — Auto-pull recent session context on daily reset

Adjacent but not the same root cause:

• [Feature] sessions_history: add pagination/offset and export support #90981 — sessions_history: add pagination/offset and export support

#90981 is about truncation/pagination. This report is specifically about older history existing in reset/archive/family session files but not being reachable through sessions_history.

Suggested fix

Expose and document one reliable path for retrieving logical conversation history across reset/archive/family transcripts.

For example:

{
  "sessionKey": "<webchat-dashboard-session-key>",
  "includeFamily": true,
  "includeArchived": true
}

or a separate export/history endpoint that returns:

• active transcript messages
• reset/archive transcript messages
• session family lineage
• source file/session IDs for auditability
• a flag when older history exists but was not included

Privacy note

This report intentionally omits real prompts, real attachment names, real local usernames, and exact private file paths. The issue is reproducible from the transcript/session structure alone.

### Steps to reproduce

1. Use a WebChat/dashboard conversation over multiple days or across a reset boundary.
2. Let OpenClaw rotate/archive the previous active transcript.
3. Continue the same visible WebChat conversation.
4. Ask the agent to retrieve earlier history using `sessions_history`.
5. Observe that only the current active transcript is returned.
6. Search session trajectory files for the same visible dashboard session key.
7. Observe older `prompt.submitted` entries under prior session IDs.
8. Observe prior transcript files such as:

```text
<sessions-dir>/<old-session-id>.jsonl.reset.<timestamp>Z

Expected behavior

When a visible WebChat/dashboard conversation has prior transcript files connected by the same session key, reset archive, or session family, sessions_history should either:

1. include the prior/reset/family transcript history by default, or
2. expose a documented parameter such as includeFamily, includeArchived, or resetAncestors, or
3. return metadata indicating that older reset/archive history exists and how to retrieve it.

The UI should also avoid implying “no earlier history” when reset/archive transcripts exist.

Actual behavior

sessions_history only returned the active transcript.

This made it look like there was no earlier conversation history, even though older turns existed in .jsonl.reset.* files and matching trajectory files.

Why this matters

This can cause agents and users to incorrectly conclude that conversation history is missing or lost.

The data may still exist on disk, but it is hidden from the normal history tool and difficult to discover without manual filesystem inspection.

This is especially confusing in WebChat, where the visible dashboard conversation appears continuous to the user, while the backend has split it across multiple session IDs.

OpenClaw version

v2026.6.5

Operating system

Ubuntu 24.04.4

Install method

npm / pnpm package-manager install, not git checkout

Model

openai/gpt-5.5

Provider / routing chain

OpenClaw -> OpenAI Codex OAuth -> openai/gpt-5.5

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response