You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
doctor detects corrupted context.db but provides no recovery path #301
doctor detects severe corruption in the shared context.db, but neither the CLI nor the documentation provides a recovery or reset procedure.
What happened?
Ran bunx @cortexkit/magic-context@latest doctor.
Selected OpenCode and Oh My Pi (OMP).
Both harnesses reported the same shared database at ~/.local/share/cortexkit/magic-context/context.db.
Expected: after reporting a failed SQLite integrity check, doctor should provide a supported recovery path or an explicit reset command/documentation.
Actual: doctor reports SQLite integrity_check failures, including invalid page number errors for multiple b-trees, then exits with failures. The DB has schema version 76, matching the plugin-supported version 76.
The OpenCode run reported these surviving row counts:
SQLite integrity_check reported: *** in database main ***
Tree 288 page 288 cell 0: invalid page number 1197
Tree 48 page 48 cell 0: invalid page number 1213
Tree 273 page 273 cell 0: invalid page number 1188
Tree 198 page 198 cell 0: invalid page number 1065
The OMP doctor reports the same integrity failure because it uses the same shared DB. Its separate OMP version/plugin/config failures appear unrelated.
Diagnostics
Command run:
bunx @cortexkit/magic-context@latest doctor
OpenCode doctor summary:
Summary: PASS 11 / WARN 0 / FAIL 2
OMP doctor summary:
Summary: PASS 2 / WARN 1 / FAIL 5
Plugin version
0.36.0
OpenCode version
Unknown. Doctor found /home/ravi/code/bwrapper/bwrapper but could not execute it to determine the version.
Platform
Linux x64
Client
OpenCode TUI (CLI)
Log output (optional)
Not included. The report above is from the doctor output.
You were right that reporting a failed integrity check and then offering nothing was the wrong end state.
There is now a repair command that:
backs up the database before touching anything,
attempts salvage into a fresh file,
reports what survived per table so you can see what a salvage would actually cost you,
and only then offers anything destructive.
It refuses to run while a harness still has the database open, and doctor now prints both the database path and the exact command to run rather than leaving you to find them.
One caveat worth stating: salvage depends on a SQLite feature that is not present in every build. When it is missing, the command now says so explicitly instead of misreading the absence as unrecoverable data and offering a reset.
Activity
HaleTom commentedon Aug 11, 2026
Path to corrupt file(s) also not listed.
feat(#301): salvage-first context.db recovery command with holder-liv…
docs: v0.36.1 notes — emergency-band reclaim fix, #161, #301
alfonso-magic-context commentedon Aug 12, 2026
Addressed in v0.36.1.
You were right that reporting a failed integrity check and then offering nothing was the wrong end state.
There is now a repair command that:
It refuses to run while a harness still has the database open, and
doctornow prints both the database path and the exact command to run rather than leaving you to find them.One caveat worth stating: salvage depends on a SQLite feature that is not present in every build. When it is missing, the command now says so explicitly instead of misreading the absence as unrecoverable data and offering a reset.