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
{{ message }}
Repository navigation
Mixed stable/beta channels sharing one data dir silently split sessions across session and session_v2 #44028
All generations write to the same opencode.db, but they use different session tables:
Writer
Table
stable CLI / desktop-prod embedded server
session
beta CLI / desktop-beta opencode-cli
session_v2
The beta performs a one-time copy of existing session rows into session_v2, stamped in kv as migration.v1-v2 = {"phase":"completed"}. In my case it copied 73/106 rows.
Consequences observed:
Sessions created in stable after the stamp never appear in the beta (33 stranded rows in my DB).
Sessions created in the beta are invisible to stable CLI and to the desktop-prod embedded server (the prod bundle contains zero references to session_v2) — 41 such rows in my DB.
Nothing warns the user; each surface just shows a different session list against what looks like one workspace history.
Expected behavior
Either:
Continuous (or lazy/read-through) migration, so session rows created after the one-shot stamp flow into session_v2; and/or
Older readers fall back to reading session_v2 (union view) so beta-created sessions are visible; or
Per-channel database files by default (like the existing non-standard-channel opencode-<channel>.db path) plus a clear warning when a second generation opens an existing data dir.
Repro
Use stable CLI/desktop to create sessions in ~/.local/share/opencode.
Install/run the beta channel (opencode2 / OpenCode Beta desktop). First run migrates a snapshot into session_v2.
Create more sessions in stable → they never appear in beta. Create sessions in beta → they never appear in stable/prod-desktop.
Data
DB snapshot at time of writing: session = 106 rows, session_v2 = 112 (73 migrated + 41 beta-native; overlap 73).
Drafted from a live-machine audit; happy to provide anonymized schema dumps if useful.
If your issue is distinct from these (e.g. specifically the lack of a continuous/lazy migration or per-channel DB path), please clarify how it differs so it can be tracked separately.
Activity
github-actions commentedon Aug 22, 2026
This issue might be a duplicate of existing issues. Please check:
session_v2leaves sessions invisible across channels, including the same stranded-rows problemIf your issue is distinct from these (e.g. specifically the lack of a continuous/lazy migration or per-channel DB path), please clarify how it differs so it can be tracked separately.
github-actions commentedon Oct 21, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.