Repository navigation
Concurrent instances on the same project cause silent crash (SQLite WAL lock contention) #36775
Description
Summary
Running two OpenCode instances simultaneously on the same project directory causes one of them to crash silently with no user-facing error. The root cause is concurrent write contention on the shared SQLite database (~/.local/share/opencode/opencode.db).
Steps to reproduce
- Open a terminal in your project directory and start
opencode(instance A) - Open a second terminal in the same directory and start
opencode(instance B) - Use both instances concurrently (e.g., one running a long task, the other starting a new session)
- One of the instances dies silently — no error message to the user
Observed behavior (from logs)
On 2026-07-13, two instances had been running for hours:
| Run ID | Started | Sessions | Status |
|---|---|---|---|
85243909 |
17:52 UTC | quick-wolf, silent-wizard |
Orphaned at 22:01 |
cec74255 |
18:57 UTC | quick-meadow |
Orphaned at 21:58 |
At 22:00:56 UTC, two new instances spawned simultaneously:
b2b3534d(survived, auto-upgraded 1.17.19→1.17.20)8a5c1dc2(crashed after 12 log lines, 0 sessions created, dead on arrival)
The 8a5c1dc2 instance only logged bootstrapping/init and then went silent — no session creation, no error message, no recovery.
Log evidence
2026-07-13T22:00:56.058Z creating instance run=b2b3534d directory=/home/carole/Cyril/Obsidian
2026-07-13T22:00:56.225Z creating instance run=8a5c1dc2 directory=/home/carole/Cyril/Obsidian
2026-07-13T22:00:56.391Z bootstrapping run=b2b3534d
2026-07-13T22:00:56.579Z bootstrapping run=8a5c1dc2
2026-07-13T22:00:56.605Z init run=b2b3534d
2026-07-13T22:00:56.726Z init run=8a5c1dc2 ← last entry for this instance
Instance 8a5c1dc2 logged exactly 12 entries total, then disappeared completely.
Root cause hypothesis
SQLite in WAL mode supports concurrent readers but only one writer at a time. Both OpenCode instances continuously write to the database (session messages, permission evaluations, project refresh). When the auto-upgrade (1.17.19→1.17.20) triggered a schema migration on b2b3534d, the lock contention killed 8a5c1dc2.
Expected behavior
OpenCode should either:
- Detect that another instance is already running on the same project and refuse to start (with a clear message)
- Or implement proper inter-process locking (e.g., a
.lockfile) to coordinate writes
Environment
- OS: Debian Linux
- OpenCode version: 1.17.18→1.17.20 (auto-upgraded during the incident)
- Working database: SQLite 3.x WAL mode (~23MB)
Activity
github-actions commentedon Jul 13, 2026
This issue might be a duplicate of existing issues. Please check:
opencode runinstances deadlock during init (futex, no timeout) — second overlapping instance hangs forever #29395: Concurrentopencode runinstances deadlock during init (no timeout) — second overlapping instance hangs or dies due to SQLite lock on shared data dirPaxGooroo commentedon Jul 13, 2026
Update : doublon partiel identifié a posteriori.
Cette issue chevauche plusieurs rapports existants :
fix(cli): recover from concurrent service replacement during startup— le concurrent startup est le coeur du problemefix(cli): TUI crashes with unhandled transport defect during post-update service restart— le crash apres upgradeSQLite migration from 1.4.17 produces a different schema than a fresh 1.17.18 database— fragilite de la migration SQLiteContexte specifique de mon environnement (Debian 13 Trixie, KDE Plasma, 12 Go RAM, Tailscale pour DNS) :
8a5c1dc2) ne laisse aucune trace d'erreur exploitable — juste 12 lignes de log puis le silenceJe ferme en faveur des issues existantes, mais je peux fournir les logs complets si besoin sur #35801 ou #36688.
PaxGooroo commentedon Jul 13, 2026
Closed as duplicate — chevauche #35801, #36688, #36709. Voir commentaire ci-dessus pour le contexte environnemental (Debian 13, KDE, Tailscale).