Repository navigation
desktop: GUI sessions and TUI sessions are not synced (desktop app still writes legacy session tables) #57770
Description
Summary
Sessions created in the OpenCode desktop GUI app never appear in the terminal TUI, and vice versa. Both share the same local database file but read and write different session tables, so history is not synced between the two interfaces.
Environment
- opencode version: 2.1.2 (CLI/TUI); desktop app reports engine version 1.19.3
- OS: Windows 10.0.26300.9711 (win32 x64)
- Terminal: Windows Terminal (
WT_SESSIONset),TERM=xterm-256color - Shell:
C:\WINDOWS\system32\cmd.exe - Install/channel:
latest— CLI is a global npm install of@opencode/cli; desktop app is installed from the GitHublatestrelease and its auto-updater reports "up-to-date" at 1.19.3 - Active plugins: local plugin
orca-opencode-status(~/.config/opencode/plugins/orca-opencode-status.js); no plugins declared inopencode.jsonc
Reproduction
- Launch the desktop GUI app, open a workspace directory, create a new session and send a message (GUI session written with engine version
1.19.3). - In the same directory, run
opencodein the terminal (v2.1.2) and open/sessions. - The session created in step 1 is not listed, and it cannot be resumed from the terminal.
Expected Behavior
Because both interfaces use the same local data directory (~/.local/share/opencode), sessions created in the desktop GUI should be visible and resumable from the terminal TUI, and vice versa.
Actual Behavior
GET /api/sessionon the shared background service lists only rows from thesession_v2table (the CLI's own sessions).GET /api/session/<gui_session_id>returnsHTTP 404with{"_tag":"SessionNotFoundError"}even though the row exists in the same database file, in the legacysessiontable.
Additional Context
Both interfaces point at the same database file: ~/.local/share/opencode/opencode.db.
The GUI desktop app runs its own sidecar server on a different port than the shared background service, but writes to that same database file. The split is at the table level:
| Interface | Engine version | Session tables |
|---|---|---|
| Desktop GUI | 1.19.0 / 1.19.3 | session, message, part (legacy schema) |
| Terminal CLI/TUI | 2.0.26 – 2.1.2 | session_v2, session_message (V2 schema) |
The session.version column records the engine that created each row, which confirms the split:
-- session (legacy) : created by the desktop GUI
ses_... version=1.19.0 <dir> 2026-10-14 00:13 "New session - ..."
ses_... version=1.19.0 <dir> 2026-10-15 23:28 "Test message"
ses_... version=1.19.3 <dir> 2026-10-21 12:37 "<GUI session>"
ses_... version=1.19.3 <dir> 2026-10-21 14:05 "<GUI session>"
ses_... version=1.19.3 <dir> 2026-10-21 14:12 "<GUI session>"
ses_... version=1.19.3 <dir> 2026-10-21 14:18 "<GUI session>"
-- session_v2 : created by the terminal CLI
ses_... version=1.19.0 <dir> 2026-10-14 00:13 "New session - ..."
ses_... version=2.0.26 <dir> 2026-10-14 12:14 "<TUI session>"
ses_... version=2.0.28 <dir> 2026-10-14 12:18 "<TUI session>"
ses_... version=2.0.29 <dir> 2026-10-21 12:26 "<TUI session>"
ses_... version=2.1.2 <dir> 2026-10-21 18:50 "<TUI session>"
Relevant migration state:
// kv table
"migration.v1-v2": "{\"phase\":\"completed\"}"The V1-to-V2 migration completed once and converted the sessions that existed at that time. Exactly one session appears in both tables (created before the migration). Every session created afterwards by the desktop GUI stays only in the legacy session table, and V2 never imports it. So the desktop GUI and the V2 terminal are permanently out of sync until the desktop app is built on the V2 session storage.
Message content is not lost — the legacy message and part tables still hold the GUI conversation data — but it is unreachable from the V2 API and TUI.
Workarounds tried: none available. The only current options are to use each interface for its own sessions, or to read the legacy tables directly from SQLite.
Related: the desktop auto-updater reports 1.19.3 as the latest available version on the latest channel, so there is currently no V2-based desktop build to update to.
Activity
mesakhlolo commentedon Oct 21, 2026
Duplicate of #50130, which describes the same latch: once
kv['migration.v1-v2']is{"phase":"completed"}, any V1 session that appears in the database afterwards is never imported and stays in the legacysession/message/parttables. #55493 was closed as a duplicate of the same issue, so closing this one too.Desktop-side detail from this report, for the record:
sessionrows after the migration completed on 2026-10-14 in this database, writing to the sameopencode.dbthat the v2 CLI (2.1.2) uses.session.versioncleanly separates the two writers inside one database:1.19.0/1.19.3(desktop) vs2.0.26–2.1.2(CLI/TUI).GET /api/sessionlists onlysession_v2rows, andGET /api/session/<legacy_id>returnsSessionNotFoundErroreven though the row exists in the same file.Recovery: the non-destructive path documented in #50130 by @visuarte (rebuild the stranded sessions from the legacy tables and import them with
opencode session import <file> --directory <dir>, without touching thekvmarker) is the route I will use for this database.Thanks for the detailed triage in #50130 — it made the cause immediately clear.
opencode-agent commentedon Oct 21, 2026
Thanks for the detailed report and the table-level breakdown, it makes the cause easy to see.
I think this is a duplicate of #50130. The desktop app you have (engine 1.19.3) is still OpenCode v1, so it writes to the legacy
session/message/parttables. The v2 CLI ran its one-time v1→v2 import once and markedmigration.v1-v2ascompleted. Since then it never picks up v1 sessions created later, which is whyGET /api/session/<id>returnsSessionNotFoundErroreven though the row exists.Possible duplicates and related issues, ordered by likelihood:
migration.v1-v2completes are never imported. Same root cause and symptoms. The thread also has backup-first recovery steps, e.g. importing stranded sessions withopencode session import.If you try any of the manual recovery steps from #50130, back up
opencode.dbfirst.The bot will close this issue as a duplicate in 1 day unless you reply explaining how your problem is different.
opencode-agent commentedon Oct 22, 2026
Closing this as a duplicate of #50130, since we haven't heard back in the past day. Both describe the same problem: the v1 desktop app (1.19.3) creates sessions after
migration.v1-v2has been markedcompleted, and v2 never imports them.Please follow #50130 for updates. The proposed fix is in PR #54272, which hasn't been merged yet. Until then, the #50130 thread has recovery steps. Back up
opencode.dbbefore trying any of them.If your problem turns out to be different, reply here with the details and we can reopen this. Thanks again for the thorough report.