OpenClaw's session history path received a major scalability fix late on July 16. PR #108851, fix(sessions): large histories no longer load entire transcripts, merged at 21:11 UTC with a large SQLite-backed history rewrite.
The problem was straightforward but costly: opening or paging a large SQLite-backed session could materialize the full transcript before applying history limits. For long-running or branched sessions, that meant work scaled with the entire transcript rather than the page the user actually requested.
The PR also notes a second issue. Raw control rows could cause message cursors to overlap or skip visible messages, which is exactly the sort of edge case that makes large histories feel unreliable even when the data is still present.
What Changed
OpenClaw now adds a canonical active-path projection to the per-agent SQLite database. History, count, ID, and anchor reads move onto bounded indexed queries instead of loading the whole transcript first.
The schema moves to version 10. Existing version 9 databases upgrade in place, preserve canonical transcript rows, mark the derived projection dirty, and rebuild it outside request and write stacks.
Runtime reads now use the canonical SQLite store. The PR explicitly says there is no dual-read path or file fallback for this history surface. That simplifies the contract: the database projection is the history path, and the projection is rebuilt when needed.
Why This Matters
Session history is not just an archive. It is how operators inspect past work, resume context, debug delivery, and understand what an agent did. If large histories become slow or cursor behavior gets weird, trust in the session layer drops quickly.
Bounded paging is also important for hosted and mobile experiences. A user opening an old session should not need the server to deserialize a huge transcript just to show the next page of visible messages.
For teams running OpenClaw heavily, this change should make long-running sessions feel less fragile. The user-facing promise is modest but meaningful: large histories page by visible-message cursor without deserializing the entire transcript.
Migration Behavior
Existing installations migrate automatically when their agent database opens. Operators do not need to run manual SQL or perform a separate migration step for this change.
The PR says transcript data is preserved during the upgrade. The derived projection can be rebuilt outside request paths, which helps keep the expensive work away from ordinary history reads.
That is the right shape for a session-store migration: preserve the source rows, derive the optimized view, and avoid making every user request pay for rebuilding state.
Evidence
The PR reports 237 focused tests across the version 9 to version 10 migration, schema and query-plan contracts, a 100,000-message bounded reader, projection reconciliation, gateway RPC and HTTP history, and release packaging.
It also reports the full changed gate, all-project TypeScript checks, oxlint, import-cycle checks, generated schema and database-first guards, and a production build.
A separate macOS live test used SQLite online backups of three real agent databases and verified startup migration behavior against those copies.
Operator Takeaway
If your OpenClaw instance has large or deeply branched sessions, PR #108851 is one to watch in the next release notes. It is a storage and query change, but the outcome is user-facing: histories should open and page with less work, cleaner cursors, and no manual database intervention.