SQLite database corruption (database disk image is malformed) when running concurrent sessions on NFS

Bug Report

OpenCode version: latest (as of 2026-02-24)
OS: Linux 6.6.105+ (NFS-mounted home directory)
Runtime: Bun

Description

Opening multiple opencode sessions in the same repository corrupts the shared SQLite database (~/.local/share/opencode/opencode.db), making opencode unable to start until the database is manually deleted.

Error

{
  "name": "UnknownError",
  "data": {
    "message": "SQLiteError: database disk image is malformed\n    at values (unknown)\n    at get (../../node_modules/.bun/drizzle-orm@1.0.0-beta.12-a5629fb+1f516382cd87cd66/node_modules/drizzle-orm/bun-sqlite/session.js:91:25)\n    at run (node:async_hooks:62:22)\n    at use (src/storage/db.ts:111:28)\n    at fromDirectory (src/project/project.ts:193:26)\n    at async <anonymous> (src/project/instance.ts:27:52)\n    at async provide (src/project/instance.ts:40:23)\n    at processTicksAndRejections (native:7:39)"
  }
}

Steps to Reproduce

1. Have opencode installed with home directory on NFS
2. Open an opencode session in a repository
3. Open a second opencode session in the same (or different) repository
4. Send a message in either session
5. SQLite database corrupts almost immediately — opencode crashes with the above error
6. All subsequent attempts to start opencode also crash until the database is manually deleted

Root Cause (Suspected)

All opencode sessions share a single SQLite database (~/.local/share/opencode/opencode.db) using WAL mode. Concurrent writers likely cause corruption due to:

1. NFS + SQLite locking: SQLite relies on POSIX fcntl() advisory locking, which is notoriously unreliable on NFS. The WAL -shm file uses shared memory mappings that don't work correctly over network filesystems.
2. bun-sqlite concurrency: Even on local filesystems, multiple processes writing to the same bun-sqlite database without explicit coordination (e.g., PRAGMA busy_timeout, retry logic, or a single-writer architecture) can corrupt the database.

Evidence of NFS involvement: stale .nfs* handle files were present alongside the corrupted database in ~/.local/share/opencode/.

Workaround

Delete the corrupted database and let opencode recreate it (loses all session history):

rm ~/.local/share/opencode/opencode.db ~/.local/share/opencode/opencode.db-shm ~/.local/share/opencode/opencode.db-wal

Suggested Fixes

• Set PRAGMA busy_timeout to handle concurrent access gracefully instead of corrupting
• Use PRAGMA journal_mode=DELETE instead of WAL when on a network filesystem (or detect NFS and warn)
• Consider per-project databases instead of a single global one
• Add integrity checks on startup with a graceful recovery path instead of crashing

Related Issues

• #4251 — Concurrent sessions interfere with each other (session isolation)
• #5241 — Sessions not saving with multiple sessions open
• #5517 — Race condition in concurrent session deletion