Summary

A utility script to automatically restore and re-index session transcript files
that were archived as .reset.<timestamp> by the new daily session-reset mechanism.

Problem to solve

Starting with PR #14949 (Feb 13, 2026) and PR #35493 (Mar 6, 2026), OpenClaw
began archiving old transcript files as <session>.jsonl.reset.<timestamp> when
a session resets — both on manual /new//reset and on the scheduled daily
reset (default: 4 AM).

Users who upgraded to v2026.3.12 (the first release containing both changes)
found that all their session history had disappeared from the UI sidebar.
This happened because the daily reset ran for the first time after upgrade and
archived all existing sessions at once — not because of a migration script.

The data is not lost; it exists in .reset.* archive files. But re-indexing
dozens of files manually is tedious.

Proposed solution

A script that automates the restoration: it renames .reset.* archive files
back to .jsonl and rebuilds the sessions.json index.

Script: https://github.com/CadanHu/openclaw/blob/feat/session-restore/scripts/restore-sessions.mjs

Alternatives considered

Manual renaming, which is error-prone and time-consuming for users with large
chat histories.

Impact

• Affected: Users upgrading from versions before Feb 2026 who had existing session history.
• Severity: Medium (perceived data loss; data is actually archived, not deleted).
• Frequency: One-time, on first daily reset after upgrade.
• Consequence: Users lose sidebar access to previous chat contexts.

Additional information

Note: future daily resets will continue to archive sessions. Users should be
aware that .reset.* files are subject to automatic pruning via
session.maintenance.resetArchiveRetention (defaults to pruneAfter).
If restoration is needed, it should be done before the retention window expires.

Related issues and root cause analysis

After further investigation, this issue is part of a broader systemic gap rather than an isolated upgrade problem.

The real problem has three layers:

1. Archiving was introduced without access tooling
Sessions are archived to .reset.<timestamp> files by design (PR #14949, PR #35493), but no UI, agent tool, or API was built to surface these archives. From the user's perspective the history is gone, even though the data still exists on disk.

2. The archiving trigger is too aggressive
The current logic (updatedAt < lastDailyResetAt) archives any session last updated before today's 4 AM reset — which on first upgrade includes all existing sessions regardless of age. Only sessions that were active within the current reset window should be archived on daily reset.

3. Archives are time-limited with no recovery path
Archived files are subject to automatic pruning via session.maintenance.resetArchiveRetention. Users who don't know to act quickly will permanently lose their history with no built-in recovery option.

Related open issues:

• Preserve previous session history after /new (read-only access) #35472 — Preserve previous session history after /new (read-only access)
• Session history not listed in UI after /new or /reset #42336 — Session history not listed in UI after /new or /reset
• [Feature]: Dashboard - browse archived/historical session transcripts #42980 — Dashboard: browse archived/historical session transcripts
• [Feature]: logical chat history across rolled sessions #43929 — Logical chat history across rolled sessions
• [Bug][CRITICAL] Session transcript lost after session reset - 6 hours of conversation history missing #46250 — Session transcript lost after session reset
• Bug: session reset archives are not discoverable via sessions_history, breaking context recovery after reset #56131 — Session reset archives not discoverable via sessions_history
• sessions_history should support reading archived/reset sessions #57139 — sessions_history should support reading archived/reset sessions

All of the above are open as of April 2026, suggesting this is a known but unresolved area. The utility script in this issue addresses the symptom; the root fix requires either (a) correcting the reset freshness evaluation logic, or (b) exposing archived sessions through existing tools and UI.