[Bug]: current_local_runtime_v2_migration_failed — corrupt runtime-state.sqlite blocks startup

Start by reading packages/local-runtime/src/persistence/migration/v2-migration.ts and packages/local-runtime/src/persistence/db.ts to follow how startup opens and migrates the runtime-state database. Check the existing backup and path handling in packages/local-runtime-v2/src/infra/db/backup.ts and packages/shared/src/local-runtime-paths.ts; the issue names no tests, so locate the relevant migration tests. Done means corrupt databases no longer block startup without recovery or an actionable error, and session history files remain untouched.

Summary

Starting MCode fails with a fatal, unrecoverable startup error. The local runtime-state SQLite database is reported as malformed, so the v1→v2 migration step that opens it throws, no session can be loaded, and the CLI stays unusable until the file is removed by hand.

Product or interface

CLI - interactive TUI

Version

v0.7.4 (MiniMax Code app version shown in the screenshot; mcode --version output to be added)

Platform

Linux (workspace path style ~/workspaces/<project>; uname -srm to be confirmed)

OS version and architecture

To be confirmed (uname -srm)

Issue area

Startup / install / update

Desktop log upload ID

N/A - CLI report.

Steps to reproduce

1. Start MCode in a workspace: cd <workspace> && mcode
2. The TUI renders the welcome banner and shows Loading session
3. Startup then aborts with the error below; the session is never loaded and the TUI remains unusable
4. Every subsequent start reproduces the same error

Expected and actual behavior

Expected: When the runtime-state database cannot be opened (corrupt / not a database), MCode should recover — for example quarantine the unreadable file, rebuild a fresh runtime-state DB and continue starting — or at minimum fail with an actionable message that contains the absolute path of the file, the SQLite error code, and the exact command that repairs it.

Actual: The only output is a raw machine-readable error code. There is no file path, no SQLite error code, no recovery hint, and no mcode command that repairs the state. The session cannot be loaded at all.

Redacted error summary

current_local_runtime_v2_migration_failed:sqlite:runtime-state:open:database disk image is malformed

It is printed at the bottom of the TUI, under the status bar ~/workspaces/<project> | Permissions | ✦ no model.

Root cause (traced in the published source)

• packages/local-runtime/src/persistence/migration/v2-migration.ts:276 opens the runtime-state database inside the migration step sqlite:runtime-state:open, through openLocalRuntimeDb(dataDir) (packages/local-runtime/src/persistence/db.ts:516), which calls new Database(dbPath). On a corrupt file, better-sqlite3 throws SqliteError: database disk image is malformed (SQLITE_NOTADB / SQLITE_CORRUPT).
• The step error is collected into manifest.errors, and assertV2MigrationSucceeded() (v2-migration.ts:146-150) rethrows it as current_local_runtime_v2_migration_failed:<reason> — exactly what the TUI prints.
• The affected file is <dataDir>/v2/sqlite/runtime-state.sqlite (packages/shared/src/local-runtime-paths.ts:57). The default data directory is ~/.minimax (~/.minimax-<profile> when a profile is selected; MINIMAX_DATA_DIR / MAVIS_DATA_DIR override it).
• There is no recovery path today: the pre-migration backup (<dataDir>/v2/sqlite/backups/runtime-state-before-v2-migration-*.sqlite, packages/local-runtime-v2/src/infra/db/backup.ts:67) is produced through SQLite's online backup API, which itself requires the file to be openable. A corrupt database can therefore never be backed up, let alone repaired, and the failure is terminal for the entire data directory.
• The same migration also creates the v2 database from the legacy v1 database with VACUUM INTO (v2-migration.ts:756-771) and reconciles rows into an existing target (:750-754), so a corrupt target can also be produced by the copy/promote path rather than by external damage.

Request

1. Treat an unreadable runtime-state DB as a recoverable condition: on SQLITE_CORRUPT / SQLITE_NOTADB, move the file aside with a timestamp, recreate a fresh runtime-state DB, and continue starting. Session history is stored as files under <dataDir>/v2/sessions/, so it should survive this.
2. At minimum, print an actionable CLI error: the absolute DB path, the SQLite error code, and the exact command to quarantine the file.
3. Consider running PRAGMA integrity_check on the runtime-state DB during startup, so corruption is detected before it turns into a hard startup failure. Related: #505 (SQLite WAL is never checkpointed) and #282 (SQLITE_BUSY on the shared runtime-state.sqlite).

Workaround used to get the CLI running again

# stop every MCode process first
cd ~/.minimax/v2/sqlite
mv runtime-state.sqlite     runtime-state.sqlite.corrupt
[ -f runtime-state.sqlite-wal ] && mv runtime-state.sqlite-wal runtime-state.sqlite-wal.corrupt
[ -f runtime-state.sqlite-shm ] && mv runtime-state.sqlite-shm runtime-state.sqlite-shm.corrupt

This quarantines the corrupt file and lets the runtime rebuild a fresh runtime-state database. It discards the runtime-state index (message rows, queue items, asset-ref index); the session history files under <dataDir>/v2/sessions/ are not touched.