OpenClaw 2026.3.7 Archived Scheduled Resets

OpenClaw’s 2026.3.7 release fixed a small conditional with a large operational consequence: an automatic daily or idle session rollover would no longer leave the previous conversation as an unlabelled, unreferenced JSONL file.

The old transcript had not necessarily been erased. That was precisely the problem. It remained on disk, but the live sessions.json map had moved the conversation key to a new session ID. Without the .reset.<timestamp> archive suffix used by explicit resets, an operator could not readily tell a legitimate rollover from abandoned state or an unrelated failure.

The March change established a useful durability rule: starting a fresh session and disposing of the previous transcript are different operations. Automatic rollover should preserve and identify the old record before advancing the live pointer.

This is historical analysis of the flat-file session system shipped in March 2026. We did not reinstall or execute that old release; implementation and test results below are attributed to the upstream issue, merged pull request, commit and release.

The historical change

In 2026.3.2, session continuity depended on two related artifacts on the Gateway host:

• sessions.json mapped a stable session key to a current sessionId and metadata;
• a <sessionId>.jsonl file held the transcript for that ID.

The documentation preserved at the 2026.3.7 tag described the Gateway as the source of truth and located both artifacts under each agent’s sessions directory. It also documented the lifecycle: sessions were reused while fresh, the default daily boundary was 4:00 AM in the Gateway host’s local time, and expiry was evaluated when the next inbound message arrived. An optional idle window could force rollover sooner.

That last detail matters. The clock crossing 4:00 AM did not itself mutate storage. The first later message caused OpenClaw to evaluate freshness, mint a new session ID and update the mapping.

Issue #35481, filed on 5 March 2026 against 2026.3.2, documented what happened next. After a Telegram topic rolled over, sessions.json pointed to a new transcript while the old 656 KB JSONL remained under its original name. The reporter found 12 such files, totalling about 4 MB, across roughly 14 topics over three days. Those numbers describe that deployment only; they are not a project-wide impact estimate.

Explicit /new and /reset flows already called the transcript archiver. Scheduled expiry did not.

Why the old path stranded history

The bug was not in JSONL writing. It was in deciding whether to remember the prior session entry long enough to archive its transcript.

Before the fix, previousSessionEntry was captured only when resetTriggered was true. That flag represented an explicit reset command. A scheduled rollover instead made the existing entry fail the freshness check. OpenClaw created the new session, but the archival block later in the flow had no previous entry to process.

PR #35493 changed that condition. The code first evaluated freshEntry, then retained the old entry when either an explicit reset had been requested or the existing entry was stale. The already-existing archiveSessionTranscripts call could then rename the old file with a .reset.<timestamp> suffix.

The change was five added lines and one removed line in the runtime file, plus a regression test. The merged commit records the test setup: freeze time at 5:00 AM, make the prior entry’s update time 3:00 AM, use the default 4:00 AM boundary, send a message, and assert that a new session ID is created while the old ID is passed to the archiver with reason reset.

That test proves the intended call path in upstream’s suite. It does not independently prove every filesystem, crash or channel edge, and the Academy did not reproduce it on 2026.3.2 or 2026.3.7.

Who the fix affected

The affected group was narrower than “everyone with sessions” and broader than one Telegram report.

Operators were exposed when all of these were true:

1. they ran a flat-file release with the faulty path, including the reported 2026.3.2;
2. an existing session became stale under daily, idle or another scheduled freshness policy;
3. a later inbound message caused rollover; and
4. the previous session had a JSONL transcript to leave behind.

Manual /new and /reset were not the broken path. The merged PR explicitly says those commands already archived their old transcript. The release note describes the fix as covering stale-session scheduled and daily resets.

Channel symptoms could vary because session keys and transcript filenames varied. Telegram topics, for example, could have a -topic-<threadId> suffix. But the fault sat in shared session initialization rather than a Telegram-only archiver. The original report observed Telegram DMs and topics and did not reproduce the same default-reset behaviour for Discord channels; that observation should not be inflated into a definitive channel matrix.

The fix merged to main on 5 March at 19:52 UTC. It then shipped in OpenClaw 2026.3.7, published on 8 March. The release notes explicitly list “Sessions/daily reset transcript archival” and cite PR #35493. That release evidence is important: a merged commit and an installable release are not interchangeable milestones.

What operators had to learn

The incident exposed three distinctions that remain useful in recovery work.

The live pointer is not the transcript

A session can look new because its key now points to a new ID while older content still exists elsewhere. “The agent forgot” does not establish “the transcript was deleted.” Operators investigating a historical flat-file installation needed to inspect both the mapping and the transcript directory.

An orphan is not yet a recovery artifact

The old implementation retained bytes by accident. The fixed implementation retained them with a reason and timestamp encoded in the filename. That naming change did not automatically make every archive visible as a normal live session, but it made maintenance, diagnosis and deliberate recovery substantially safer.

Retention policy still matters

The tagged 2026.3.7 documentation listed session.maintenance.resetArchiveRetention, defaulting to the general prune window, and explained that enforce-mode maintenance could purge old .reset.<timestamp> archives. Archiving therefore created a recovery window, not permanent preservation. Operators needing audit-grade retention still required backups outside OpenClaw’s managed cleanup boundary.

For forensic handling of an old installation, a conservative editorial sequence would be: stop treating the sessions directory as disposable, copy it before repair, record the active key-to-ID mapping, and distinguish active .jsonl files from .jsonl.reset.* archives. This sequence is OpenClaw Academy guidance, not an upstream runbook, and it was not independently tested. Cleanup could remove evidence needed to understand a rollover, so it should not be the first step in that conservative approach.

What this history explains today

OpenClaw’s storage architecture has since moved on. The current session documentation identifies per-agent SQLite as the runtime store and calls sessions.json a legacy migration source. It also says legacy JSONL history can be imported during migration.

That does not make the March episode irrelevant. It explains why older installations and migrated state can contain .reset.* transcript artifacts, why a transcript file can outlive the live session that produced it, and why storage recovery must distinguish the active session index from durable conversation evidence.

Most importantly, 2026.3.7 marks the point where scheduled expiry adopted the same explicit archival intent as user-triggered reset. The operator consequence was not “sessions never reset.” They still did, by design. The consequence was that routine rollover stopped making valid history look indistinguishable from filesystem debris.

Verification note: OpenClaw Academy checked issue #35481, merged PR #35493, commit d7a15c31fe9464f4b74cffe96516528f1ec80be3, the 2026.3.7 release and tagged historical session documentation on 23 July 2026. We also checked the current session documentation to explain the later SQLite migration. We did not independently run the old packages; the regression-test behaviour and deployment observations are attributed to upstream sources.