Skip to content

doctor detects corrupted context.db but provides no recovery path #301

Closed

Description

@HaleTom

Short description

doctor detects severe corruption in the shared context.db, but neither the CLI nor the documentation provides a recovery or reset procedure.

What happened?

  1. Ran bunx @cortexkit/magic-context@latest doctor.
  2. Selected OpenCode and Oh My Pi (OMP).
  3. 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:

tags=73, compartments=23, memories=26, notes=0, dream_runs=0

Representative integrity output:

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.

Activity

  1. HaleTom commented on Aug 11, 2026

    @HaleTom
    Author

    Path to corrupt file(s) also not listed.

  2. added 2 commits that reference this issue on Aug 11, 2026
  3. alfonso-magic-context commented on Aug 12, 2026

    @alfonso-magic-context
    Contributor

    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:

    • 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions