desktop: renderer crashes with "Database is not empty and has no session table" when shared DB is migrated by v2 CLI

Summary

The OpenCode Desktop app (v1.18.34) fails to start with Error: Database is not empty and has no session table when its shared database at ~/.local/share/opencode/opencode.db has been migrated to the v2 schema (table session_v2, 48 migrations) by the opencode CLI (v2.0.22). The desktop renderer's DB layer still expects a table literally named session and refuses to open the non-empty DB.

Environment

opencode version: CLI opencode v2.0.22 (channel: latest); Desktop @opencode-ai/desktop v1.18.34 (installed via brew install --cask opencode-desktop)
OS: Darwin 25.6.0 (darwin arm64)
Terminal: TERM_PROGRAM=Apple_Terminal, TERM=xterm-256color, COLORTERM=truecolor
Shell: /bin/zsh
Install/channel: latest
Active plugins: none found in config

Reproduction

With the opencode CLI v2.0.22, create/migrate the shared DB ~/.local/share/opencode/opencode.db (this creates the session_v2 table and applies 48 migrations).
Launch the OpenCode Desktop app (v1.18.34).
The app's renderer crashes with a fatal renderer error.

Observed tables in the shared DB (from sqlite3 ~/.local/share/opencode/opencode.db ".tables"):
account, account_state, control_account, credential, event, event_sequence, instruction_blob, instruction_entry, instruction_state, kv, migration, permission, project, project_directory, session_inbox, session_message, session_pending, session_v2, workspace, worktree — note there is no table literally named session.

Expected Behavior

The Desktop app should open the shared database after the CLI applies the v2 schema migration, or otherwise coexist with the v2 CLI. If the two are intentionally incompatible over a shared DB path, the DB should be namespaced (e.g. per channel/version) rather than colliding on opencode.db.

Actual Behavior

Fatal renderer error on startup. From renderer.log:

[error] (renderer) fatal renderer error {
  error: 'Error: Database is not empty and has no session table',
  url: 'oc://renderer/index.html',
  version: '1.18.34',
  platform: 'desktop',
  os: 'macos'
}

Relevant code in the Desktop bundle (out/main/chunks/node-Cwiogc01.js):

if (tables.some((table) => table.name === "session"))
  return yield* applyOnly(db, migrations);
if (tables.length > 0)
  return yield* exports_Effect.die("Database is not empty and has no session table");

Additional Context

Both the Desktop sidecar server and the v2 CLI target join$1(Path.data, "opencode.db"). The DB currently holds live session data (3 sessions in session_v2, 45 messages), so it must not be deleted/reset. Reproducible consistently. Workaround: none so far without losing session data — running each tool against a separately namespaced DB would avoid the collision.

This issue might be a duplicate of existing issues. Please check:

Mixed stable/beta channels sharing one data dir silently split sessions across session and session_v2 #44028: Stable and beta generations share opencode.db but use incompatible session and session_v2 tables; it also discusses using per-channel database files.

+1

Versions: opencode 2.0.22 and 1.18.34 (linux-x64), installed side by
side.

What happens

Both versions default to $XDG_DATA_HOME/opencode/opencode.db on the
latest channel (1.x: opencode.db unless OPENCODE_DB or a
non-default channel is set; 2.x: the same name in the same directory).
When 2.x starts its server against a database last written by 1.x, it
runs its own migrations on it: no prompt, no backup, no check that the
file belongs to the other major version.
Some of those migrations are not compatible with 1.x: tables 1.x still
uses are rebuilt in a new shape or dropped. 1.x then fails at run time.

What we observed (one machine; 1.x was in daily use with a ~70 GB
database; 2.x was started once by a test that redirected HOME,
XDG_CONFIG_HOME and XDG_STATE_HOME but not XDG_DATA_HOME)

Within one second, 2.0.22 applied 10 migrations to the 1.x file
(20260804233008_loose_psylocke through 20260923013825_project_time_active).
workspace was rebuilt as (id, provider, binding, created_at, last_used_at). 1.18.34 expects (…, project_id, time_used).
session_input, session_context_epoch and data_migration were
dropped. All three are 1.x tables (1.x's own schema and migrations
define them).
session_message was rebuilt (compatible columns; its rows were lost).
event.created and project.time_active were added, both with
defaults (harmless to 1.x).
8 new 2.x tables were created (harmless to 1.x).
Afterwards 1.18.34 fails to open any project whose cached project id
changed, with no such column: project_id, from Project.migrateProjectId
→ UPDATE workspace SET project_id = ? WHERE project_id = ?. Code paths
that use the dropped tables would fail with "no such table".

Minimal repro (no model needed)

A scratch XDG_DATA_HOME. Run any 1.x command that opens the
database (e.g. opencode debug config, or one opencode run against a
stub provider), so that $XDG_DATA_HOME/opencode/opencode.db holds the
1.x schema.
sqlite3 "$XDG_DATA_HOME/opencode/opencode.db" ".schema workspace":
it shows project_id.
With the same XDG_DATA_HOME, start 2.x: opencode serve --service,
or a client with no server running, which autostarts one.
Repeat step 2: workspace now has 2.x's columns, and
.tables no longer lists session_input, session_context_epoch or
data_migration.
Run 1.x again on a project whose cached id differs from its root
commit (or any code path using those tables): no such column: project_id.

Expected (any one of these would have prevented it)

2.x uses a different default file name or directory from 1.x
(e.g. opencode2.db, or $XDG_DATA_HOME/opencode/v2/), or
2.x refuses to migrate a database whose migration history belongs to
1.x, unless asked explicitly, and it backs up first, or
the 2.x migrations that change 1.x tables are additive only, and 2.x
keeps its own versions of workspace, session_message and the rest
under new names.

Related: a 2.x client with no running server autostarts serve --service (filed separately). That is how a single client command
reached the 1.x database here.

Windows confirmation: Desktop v2 + npm v1 CLI, caused by conflicting install docs

I reproduced the reverse direction of this compatibility problem on Windows:

OpenCode Desktop was 2.0.22 and had already created/migrated the shared ~/.local/share/opencode/opencode.db.
The opencode command on PATH came from the globally installed npm package opencode-ai@1.18.34.
The TUI appeared blank. A non-TUI command exposed the underlying failure after updating the same package to its npm latest, opencode-ai@1.19.3:

Error: Unexpected error
Database is not empty and has no session table

Installing opencode-ai@latest therefore did not resolve the version skew; it remained on the 1.x line.

The working recovery was:

npm uninstall -g opencode-ai
npm install -g @opencode/cli
opencode --version

This installed @opencode/cli@2.0.32. Afterward:

opencode models completed successfully and returned 92 models.
opencode mini rendered normally.
Desktop 2.0.32 connected to the same background service and its authenticated /api/model endpoint returned the same 92 models.
No database reset or session deletion was required.

There is also a documentation path that can lead users directly into this state:

https://opencode.ai/docs currently tells Windows/npm users to run npm install -g opencode-ai (v1).
https://opencode.ai/download tells users to run npm install -g @opencode/cli (v2).

Because Desktop auto-updates to v2 while the general docs still recommend the v1 npm package, a normal installation path can produce two incompatible clients sharing one database. It would help if the docs consistently pointed to @opencode/cli, or explicitly warned that opencode-ai is v1 and must not share its data directory with Desktop v2. A version-aware error suggesting @opencode/cli would also make the blank-TUI symptom actionable.

Diagnosed and verified with automated assistance; all commands and outcomes above were checked on the affected machine.

@ormanovalmaz-coder

Thanks for the detailed report, @ormanovalmaz-coder!

The app that crashes is OpenCode Desktop 1.18.34, which is OpenCode v1. v1 now only gets fixes for critical bugs, so this is unlikely to be fixed in the 1.x Desktop app.

Your data looks safe. The v2 CLI uses ~/.local/share/opencode/opencode.db as designed and renames the session table to session_v2 during its migration. Your sessions and messages are still there and the v2 CLI can read them. Only the older 1.x Desktop app fails, because it doesn't recognise the new schema. Upgrading Desktop to a v2 release (2.x) should fix the crash, since v2 knows this schema. If Homebrew's opencode-desktop cask still gives you 1.18.34, the installer from opencode.ai should get you the v2 Desktop app.

Related issues:

windows: Desktop v2 and legacy winget v1 conflict on shared database #59727: the same error when a v1 CLI (winget 1.19.x) shares the database with Desktop v2
core: previous V2 import is skipped when a fresh target has no legacy session table #56732: a previous v2 import is skipped when the new database has no legacy session table
feat(core): add a database table prefix for shared SQLite databases #53746: PR adding a table prefix so OpenCode can share a SQLite database with tables it doesn't own

If you think this is critical, or if you see the same crash with a v2 Desktop build, please reply here with the version and the log.

@ormanovalmaz-coder

Closing this as not planned, since there hasn't been a reply. The crash is in OpenCode Desktop 1.18.34 (v1). That version doesn't recognise the session_v2 schema the v2 CLI uses, and v1 only gets fixes for critical bugs. Your sessions should still be in opencode.db, and upgrading Desktop to a v2 (2.x) release should let it open the database again.

If the same crash happens with a v2 Desktop build, or you believe this is critical, please comment with the version and the renderer.log output and we can take another look. Thanks again for the detailed report, @ormanovalmaz-coder!

Navigation Menu

Repository navigation

desktop: renderer crashes with "Database is not empty and has no session table" when shared DB is migrated by v2 CLI #53221

Summary

Environment

Reproduction

Expected Behavior

Actual Behavior

Additional Context

Windows confirmation: Desktop v2 + npm v1 CLI, caused by conflicting install docs

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

desktop: renderer crashes with "Database is not empty and has no session table" when shared DB is migrated by v2 CLI #53221

Description

Summary

Environment

Reproduction

Expected Behavior

Actual Behavior

Additional Context

Activity

github-actions commented on Oct 4, 2026

ruoshuixx commented on Oct 13, 2026

askaramirov commented on Oct 17, 2026

MityaFoxy commented on Oct 19, 2026

Windows confirmation: Desktop v2 + npm v1 CLI, caused by conflicting install docs

opencodejr commented on Oct 27, 2026

opencodejr commented on Oct 28, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions