OpenClaw merged PR #113382, strengthening startup repair for canonical SQLite indexes.
The issue was subtle but important. OpenClaw could trust sqlite_schema.sql text when deciding whether a canonical unique index was correct. If the schema text looked right but the underlying SQLite b-tree was physically wrong or stale, indexed reads could miss rows that existed, and uniqueness checks could fail to enforce duplicates.
For a local-first agent runtime that leans on SQLite for durable state, that is exactly the kind of hidden storage problem worth catching before normal operation resumes.
What Changed
The new repair path binds every canonical unique index to its owning table and runs targeted table integrity checks during startup.
When a table's physical index state is stale, OpenClaw can transactionally rebuild all canonical indexes for that table. The repair still creates a probe constraint first and rolls back if conflicting data is present. It now requires both targeted and full integrity before committing the repair.
That sequence is intentionally conservative. Rebuilding indexes is useful only if OpenClaw can prove the repaired state is internally consistent before exposing it to the rest of the runtime.
Why Operators Should Care
This is not a flashy UI feature, but it touches the state paths that make OpenClaw reliable over long-lived sessions and restarts.
The PR calls out several affected surfaces:
- transcript idempotency lookups
- active transcript projections
- approvals
- worker leases
- pending inference ownership
Those systems depend on stable uniqueness and reliable indexed reads. If an index silently misses a row or permits a duplicate key, a higher-level system can make a wrong decision while the schema appears normal.
By checking the physical index structure at cold open, OpenClaw moves the repair earlier in the lifecycle. The runtime can fix stale canonical indexes before writable state is available instead of letting sessions, approvals, or workers discover the inconsistency later.
A Better Startup Boundary
The broader theme is startup honesty. OpenClaw already has a lot of defensive work around session recovery, cron ownership, approvals, and Gateway restarts. SQLite is the layer beneath many of those features.
This patch makes the database startup gate more trustworthy by treating canonical SQL text as insufficient on its own. The schema definition still matters, but the b-tree has to match the intended canonical index behavior too.
For teams running OpenClaw across frequent upgrades, restarts, and automation-heavy workloads, that is a worthwhile hardening step. The fewer hidden storage inconsistencies that survive startup, the less likely an operator is to see confusing downstream behavior.
Validation
The PR reports a reproduction against current main where forged canonical SQL over a wrong physical index caused an indexed lookup to miss a row and allowed a duplicate key.
Focused local proof covered SQLite index schema and agent database tests, with 70 passing assertions and one skipped test. A Blacksmith Testbox run then expanded coverage across agent and state database suites with 163 passing assertions, followed by pnpm check:changed.
The practical result is a stronger cold-open repair path for OpenClaw's local state: canonical indexes now have to be physically correct, not merely cosmetically correct in schema text.