You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Editing opencode.jsonc while a session is actively running causes the service to lose session events. Two concurrent writers allocate the same event.seq for one session aggregate, and the second insert fails on UNIQUE(aggregate_id, seq). The affected turn is reported to the model as an error and the event is dropped, leaving the session unable to continue.
Environment
opencode version: 2.0.18
OS: Linux 6.18.33.2-microsoft-standard-WSL2 feat: compact and other improvements #1 SMP PREEMPT_DYNAMIC Thu Jun 18 21:54:43 UTC 2026 x86_64 (WSL2, networkingMode=mirrored)
Terminal: TERM=xterm-256color, TERM_PROGRAM unset, COLORTERM unset, WT_SESSION set (Windows Terminal)
Shell: /usr/bin/zsh
Install/channel: curl install, latest channel
Active plugins: none configured
Reproduction
Start a session and let it run a tool call so the session has in-flight event writes.
While that session is still running, edit the global config at ~/.config/opencode/opencode.jsonc (even a whitespace/comment-only edit).
The service watches ~/.config/opencode with inotify and reloads configuration.
Within ~20 seconds, the running session's event write fails and the turn errors.
Observed twice in a single session:
2026-09-28T07:42:08.607 mtime of ~/.config/opencode/opencode.jsonc
2026-09-28T07:42:09.950 violation #1
2026-09-28T07:42:26.539 violation #2
Both failures are seq=427 on the same session aggregate, from two different event types — which is what makes this look like a sequence-allocation race rather than a duplicate insert:
A configuration reload should not interfere with in-flight session writes. Either the sequence allocator should serialize per aggregate so the second writer takes seq=428, or the insert should retry on conflict.
The failure propagates into Session.updateMessage -> SessionProcessor.cleanup and is surfaced to the model as an UnknownError turn. The session stopped accepting prompts afterward.
Additional Context
Reproduced 2 times, both within one session. I have not yet reproduced it from a clean start, so I cannot confirm the config edit is causal rather than coincidental with an unrelated write race — the reload and the collision are tightly correlated in both cases, but n=2 in a single session is weak evidence for causation.
The service subscribes to the config directory, so this is reachable without any explicit action beyond editing a file:
Summary
Editing
opencode.jsoncwhile a session is actively running causes the service to lose session events. Two concurrent writers allocate the sameevent.seqfor one session aggregate, and the second insert fails onUNIQUE(aggregate_id, seq). The affected turn is reported to the model as an error and the event is dropped, leaving the session unable to continue.Environment
networkingMode=mirrored)TERM=xterm-256color,TERM_PROGRAMunset,COLORTERMunset,WT_SESSIONset (Windows Terminal)/usr/bin/zshlatestchannelReproduction
~/.config/opencode/opencode.jsonc(even a whitespace/comment-only edit).~/.config/opencodewith inotify and reloads configuration.Observed twice in a single session:
Both failures are
seq=427on the same session aggregate, from two different event types — which is what makes this look like a sequence-allocation race rather than a duplicate insert:Expected Behavior
A configuration reload should not interfere with in-flight session writes. Either the sequence allocator should serialize per aggregate so the second writer takes
seq=428, or the insert should retry on conflict.Actual Behavior
The failure propagates into
Session.updateMessage->SessionProcessor.cleanupand is surfaced to the model as anUnknownErrorturn. The session stopped accepting prompts afterward.Additional Context