Desktop app silently quits on launch — FumaDB import migration fails with SQLITE_BUSY when data.db is in WAL mode

[Mark-Life]

Summary

On macOS, the desktop app launches and immediately quits (window flashes in the menu bar, then disappears — no crash report). The Bun sidecar exits with code 1 during the one-time FumaDB import migration because PRAGMA journal_mode = DELETE throws SQLITE_BUSY on a data.db left in WAL mode. No second Executor process needs to be running for this to happen.

Environment

• Executor desktop: 1.4.33 (sh.executor.desktop, notarized, arm64)
• Executor CLI (executor npm, bun global): 1.4.19
• macOS 26.5 (25F71), Apple Silicon (arm64)
• Sidecar runtime: Bun v1.3.11 (macOS arm64)

Symptom

App opens then closes within ~1s. No .ips crash report in ~/Library/Logs/DiagnosticReports/ (clean exit, not a signal crash). Repeats on every launch.

Logs

From ~/Library/Logs/Executor/main.log and Executor --log-level debug:

[error] Failed to start executor sidecar Error: Sidecar exited before ready (code=1 signal=null).
error: Failed to prepare local SQLite data. Close other Executor processes and retry, or run with --log-level debug for details.
  operation: "importSqlite"
  _tag: "LocalExecutorCreateError"
    at W_1 (apps/local/src/server/executor.ts:145:3)

// does not match this build's bundled legacy migrations.
// Skipping legacy Drizzle replay and importing the existing schema as-is.
425 |     sqlite.exec("PRAGMA wal_checkpoint(TRUNCATE)");
426 |     sqlite.exec("PRAGMA journal_mode = DELETE");
                 ^
SQLiteError: database is locked
  errno: 5, code: "SQLITE_BUSY"
    at run (bun:sqlite:336:21)
    at hQR (apps/local/src/server/executor.ts:426:12)
    at <anonymous> (apps/local/src/server/executor.ts:524:24)
    at ChildProcess.onExit (app.asar/out/main/index.js:2035:11)

Root cause

importSqlite (executor.ts ~425-426) tries to convert the existing DB out of WAL mode (wal_checkpoint(TRUNCATE) → journal_mode = DELETE) before importing into FumaDB. If ~/.executor/data.db is in journal_mode=wal (with lingering -wal/-shm), the journal-mode switch needs an exclusive lock and returns SQLITE_BUSY. The error isn't caught/retried, so the sidecar exits 1 and the Electron main quits. PRAGMA integrity_check on the DB returned ok, so the data was fine — only the journaling state blocked the migration.

Reproduction

1. Have an existing ~/.executor/data.db in WAL mode (from a prior version / unclean shutdown).
2. Launch desktop 1.4.33 (first run with the FumaDB import path).
3. Sidecar fails importSqlite; app quits.

Workaround (confirmed)

Convert the journal mode from a clean single connection, then relaunch:

# ensure no executor process is running first
sqlite3 ~/.executor/data.db "PRAGMA wal_checkpoint(TRUNCATE); PRAGMA journal_mode=DELETE;"

After this, the migration succeeded: Imported 1438 row(s) into FumaDB SQLite storage; moved old DB to data.db.imported-…, EXECUTOR_READY, app launches normally.

Suggested fixes

• Wrap the importSqlite journal-mode switch in a busy_timeout / retry, and ensure no second connection to the same DB is open within the process when switching modes.
• Catch SQLITE_BUSY during migration and surface a visible error dialog instead of silently quitting (right now the only signal is the log file).
• Consider that the desktop app and the CLI/MCP server share a single ~/.executor/data.db — concurrent use (e.g. CLI executor mcp running while the desktop app starts) can produce the same lock contention. A lockfile + clear "another Executor instance is using this database" message would help.
• Minor: desktop (1.4.33) and CLI (1.4.19) ship different versions against the same data dir.