OpenClaw merged a security-sensitive database integrity fix tonight: PR #161783, titled "fix(state): gate read-only agent database opens against quarantine." The patch closes a gap where a freshly opened read-only connection could still read an agent database generation after the integrity verifier had already proved that generation corrupt and quarantined it.
That distinction matters. The writer path already refused the quarantined generation, but session discovery and other read-only consumers were still able to bypass the same admission decision. In the wrong failure mode, an operator could see session data from a database generation OpenClaw had already marked unsafe.
What Changed
The fix moves the missing check into openOpenClawAgentDatabaseReadOnly, the shared owner for fresh direct, scoped, retained, and companion read-only readers. Before opening SQLite, that path now checks the existing process terminal latch and persisted quarantine state.
The expected behavior is tighter:
- Healthy databases still read normally.
- Missing databases still avoid creating a file.
- Replaced or successfully recovered generations still work.
- Already-quarantined generations now raise
SqliteIntegrityErrorinstead of returning a successful empty or stale result. - Doctor remains the maintenance path for supported repair and quarantine clearing.
OpenClaw's PR notes that no configuration, SQLite schema, migration, dependency, or public API change is included. This is an admission-control repair at the database boundary.
Why This Is a Security Boundary
Agent session data is operational state. If OpenClaw has proof that a database generation is corrupt, every ordinary access path should honor that decision. A write gate alone is not enough if read-only consumers can still build UI or discovery results from the same unsafe generation.
The change is especially important because read-only access tends to feel harmless. In reality, stale or corrupt session state can mislead recovery flows, dashboards, and operator decisions. The safer contract is blunt: once a generation is quarantined, normal readers stop using it until Doctor verifies a supported repair or replacement.
The PR also records maintainer acceptance for the operator impact. After upgrade, an already-quarantined generation stops serving fresh read-only session access until recovery. Depending on the corruption type, operators may need verified-backup restoration or SQLite recovery, and should preserve the database and WAL.
Validation
The evidence is unusually direct. Maintainer verification used real SQLite in isolated temporary state and one persisted synthetic session, then compared current-main and candidate behavior across the physical opener and the public listSessionEntriesReadOnly accessor.
The candidate preserved healthy reads, replacement behavior, Doctor index repair, and missing-file behavior. It rejected generation-bound persisted quarantine, process-latch quarantine, and a verifier-quarantined corrupt cache index with SqliteIntegrityError.
The test evidence also includes a before-and-after unit run where baseline code failed the intended persisted-quarantine and process-latch refusal assertions, while the candidate passed all 19 cases. Additional quarantine, retained-scope, and shared-state read-only tests passed, along with the changed-file gate and CI.
Why Operators Should Care
This is the kind of fix that makes OpenClaw's recovery story more trustworthy. Quarantine is only useful if every normal path respects it. With PR #161783, session readers now align with the same integrity decision as writers, and Doctor remains the explicit owner for repair.
For self-hosters and teams running long-lived Gateways, that reduces the chance of a damaged database quietly looking usable. The failure becomes visible, bounded, and routed through the recovery path that was built to handle it.