sessions resume stampedes the session DB at boot ("database is locked") and aborts — tabs drop to bare shell

[muqsitnawaz]

Bug · agents sessions resume stampedes the session DB at boot and aborts the resume. After a reboot, VSCodium/swarm-ext relaunches every prior tab at once, each running agents sessions resume <id>. All of them hit the session SQLite DB's write path concurrently (~28 tabs on this box), the 30s busy_timeout is not enough under that stampede, and the unlucky ones throw — dropping the tab to a bare shell with no agent attached. The session looks lost until the command is re-run by hand.

Symptom (verbatim)

.system % agents sessions resume 508b3dca-…
Error: database is locked
    at releaseScan (…/dist/lib/session/db.js:1221:5)
    at discoverSessions (…/dist/lib/session/discover.js:176:13)
    at async fetchRawPool (…/dist/commands/sessions-browser.js:271:11)
    at async collectSessionCandidates (…/dist/commands/sessions-browser.js:538:18)
    at async focusAction (…/dist/commands/focus.js:181:59)
  code: 'ERR_SQLITE_ERROR', errcode: 5, errstr: 'database is locked'

Root cause

• agents sessions resume runs a full discovery scan before attaching (collectSessionCandidates → fetchRawPool → discoverSessions → releaseScan), and releaseScan (apps/cli/src/lib/session/db.ts, dist lib/session/db.js:1191) does a BEGIN IMMEDIATE write transaction (lib/sqlite.ts transaction(), dist sqlite.js:130).
• getDB sets busy_timeout = 30000 (db.ts ~:959), but a boot stampede of ~28 concurrent writers each holding the writer lock for a discovery scan (the code comment itself notes "the first scan of a new version home can take longer than 10s") exceeds 30s for the losers → SQLITE_BUSY surfaces as database is locked and the whole resume aborts.
• Two smells: (a) resuming one known session should not require a fleet-wide, write-locking discovery scan at all; (b) there is no stagger/serialization when N tabs relaunch at boot, and the failure mode is a hard abort rather than a retry.

Repro

1. Open several agent tabs in VSCodium (via swarm-ext), then reboot so the extension relaunches them all at once.
2. Multiple tabs error with database is locked and drop to a bare shell instead of resuming.

Observed on zion, ~28 tabs relaunching; dev build at ~/.local/agents-cli-dev/…, Node v26 (node:sqlite).

Suggested fix (any of)

1. Resume without the write-locking scan — attach a known <id> directly; don't gate resume on releaseScan/discovery.
2. Serialize/stagger the relaunch: the extension (or the resume path) should queue resumes at boot rather than firing all at once.
3. Fail soft: on SQLITE_BUSY, retry the scan with backoff instead of aborting the resume.

Workaround that worked: agents sessions focus → "Resume N in VSCodium agent" once the stampede had cleared.