OpenClaw's Matrix channel received an important upgrade-safety fix in PR #112919. The patch changes how legacy Matrix encryption snapshots are migrated, moving the work out of runtime fallback behavior and into an explicit openclaw doctor --fix repair path.
The issue affects installations upgrading from releases that wrote crypto-idb-snapshot.json. According to the PR, the runtime fallback that shipped in v2026.6.10 could import, rename, or bypass encryption state while the Matrix client was already running. In the wrong sequence, that could split encryption keys between a legacy sidecar file and canonical SQLite state.
That is the kind of migration ambiguity you do not want around encrypted messaging.
Doctor Owns the Migration
The new behavior makes the Matrix legacy crypto doctor migration the single owner of snapshot upgrades. openclaw doctor --fix reads the legacy snapshot under the same cross-process lock used by runtime persistence, imports it into SQLite, reads it back for verification, and only then moves the original bytes into a timestamped recovery archive.
That sequence matters. It means the original snapshot is not discarded just because an import was attempted. The doctor path verifies structure and content before archiving, repairs partial or invalid SQLite writes from a valid source, and keeps valid SQLite state canonical when there is a conflict.
Malformed sources are archived without deletion, and filesystem read failures leave the source active. In other words, the migration is designed to preserve key material first and clean up only after proof.
Runtime Fails Closed
The Matrix runtime now reads and writes SQLite only. If canonical state is missing or unusable while a legacy snapshot still exists, crypto startup and persistence fail closed with a typed diagnostic that points the operator to openclaw doctor --fix.
That is a cleaner boundary than a runtime fallback. Runtime code should not be guessing whether it is safe to transform encryption state while the client is active. The operator-run doctor flow is slower and more explicit, but it is the right place for a one-time state migration.
Why It Matters
Matrix encryption state is not ordinary cache data. If a migration path moves or rewrites key material too eagerly, users can end up with confusing recovery work or broken encrypted-message access. The PR's release-note context is direct: Matrix upgrades now migrate legacy crypto snapshots through doctor once, and runtime no longer imports snapshot sidecars.
For OpenClaw operators, the practical instruction is simple. If you are upgrading an affected Matrix setup, run openclaw doctor --fix, restart Matrix, and let the verified repair path move the legacy snapshot into SQLite.
Verification
The evidence included focused Matrix coverage across the doctor contract API, SDK persistence, and client storage. The reported run passed 34 Matrix tests. The branch also passed hosted CI at the final head, with 176 check runs reporting zero pending and zero failed checks.
The numstat is notable too: 499 insertions and 503 deletions across nine files. The patch adds doctor-side lock, verify, and archive behavior while deleting the runtime import paths and obsolete fallback tests.
Operator Takeaway
This is a good example of OpenClaw tightening a security-sensitive migration after the first shipped implementation. The new design favors explicit repair, byte preservation, and fail-closed runtime behavior over convenient but ambiguous fallback logic.
For encrypted Matrix deployments, that is exactly the tradeoff to prefer.