Skip to content

Desktop fails to load sessions: no such column: project_id #42170

New issue
New issue
Closed
Closed
Desktop fails to load sessions: no such column: project_id#42170
Assignees
kitlangton

Description

@DatScreamer
DatScreamer
opened on Aug 12, 2026

Description

Desktop 1.18.17 dies on launch while loading sessions. The sidecar returns 500 from Project.migrateProjectId:

Error: no such column: project_id

Some builds replaced the workspace table with a provider/binding schema and dropped project_id. Current dev still remaps project IDs with UPDATE workspace SET project_id = ..., which fails and takes the renderer down.

Plugins

No response

OpenCode version

1.18.17

Steps to reproduce

  1. Have an OpenCode DB whose workspace table has provider/binding and no project_id (after a build that ran the workspace-domain migration).
  2. Open Desktop 1.18.17 / current dev.
  3. Session load returns 500 and the app shows a fatal renderer error.

Screenshot and/or share link

No response

Operating System

macOS

Terminal

Desktop app

Activity

  1. github-actions
    assigned
    kitlangton
    on Aug 12, 2026

  2. github-actions commented on Aug 12, 2026

    @github-actions
    github-actionsBot
    on Aug 12, 2026 – with GitHub Actions
    Contributor

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

    • Desktop upgrade can fail on workspace migration #32430: Desktop upgrade can fail on workspace migration — also involves a workspace table migration failure with a "no such column" error during Desktop upgrades; the root cause and symptom are very similar to what you're describing.

  3. DatScreamer commented on Aug 12, 2026

    @DatScreamer
    DatScreamer
    on Aug 12, 2026
    Author

    Not a duplicate. Same area, different bug.

    Related family (workspace schema drift), not the same issue; do not close as a duplicate.

  4. ceotind commented on Aug 15, 2026

    @ceotind
    ceotind
    on Aug 15, 2026
    Image Issue present

    Fixes the issue manually: dropped the empty workspace table and recreated it with the correct schema including project_id:
    id, type, name, branch, directory, extra, project_id, time_used

  5. bgzo commented on Aug 22, 2026

    @bgzo
    bgzo
    on Aug 22, 2026

    Fixes the issue manually: dropped the empty workspace table and recreated it with the correct schema including project_id: id, type, name, branch, directory, extra, project_id, time_used

    This work for me. Append SQL DDL on ~/.local/share/opencode/opencode.db:

    DROP TABLE IF EXISTS workspace;

CREATE TABLE `workspace` (
          `id` text PRIMARY KEY,
          `type` text NOT NULL,
          `name` text DEFAULT '' NOT NULL,
          `branch` text,
          `directory` text,
          `extra` text,
          `project_id` text NOT NULL,
          `time_used` integer NOT NULL,
          CONSTRAINT `fk_workspace_project_id_project_id_fk` FOREIGN KEY (`project_id`) REFERENCES `project`(`id`) ON
DELETE
    CASCADE
        );

    Or try do manaul using cli via: #31119 (comment)

  6. btriapitsyn commented on Aug 22, 2026

    @btriapitsyn
    btriapitsyn
    on Aug 22, 2026

    Additional Windows reproduction from openchamber/openchamber#3056:

    • The same shared opencode.db failure reproduces with both OpenChamber's bundled OpenCode 1.18.18 and standalone OpenCode 1.18.21 via opencode run, so it is independent of OpenChamber.
    • The stale workspace schema was left by 0.0.0-next-17444 after applying 20260808023530_workspace_domain. It contains provider, binding, created_at, and last_used_at, with no project_id.
    • Project.migrateProjectId then fails for every non-global git project.
    • In this reproduction the table contained 0 rows; backing up the DB, dropping only workspace, and recreating its current schema restored session create/list and made existing sessions visible again.

    The original report includes the full schema, logs, and reproduction steps: openchamber/openchamber#3056

  7. coygeek commented on Sep 12, 2026

    @coygeek
    coygeek
    on Sep 12, 2026

    Confirmed on macOS with OpenCode 1.18.30. This also affects CLI/TUI startup: running opencode fails with “Unexpected server error,” and the server log reports SQLiteError: no such column: project_id in Project.migrateProjectId.

    The database’s workspace columns are id, provider, binding, created_at, and last_used_at. The repository’s .git/opencode cache contained an older project ID, while all ten existing v2 sessions for the directory already referenced the current remote-derived project ID.

    After backing up and correcting only the cached project ID, startup succeeded without manually changing the database schema or session rows. Both opencode and its shell alias were then verified in tmux 3.6a: the home screen loaded, the command palette responded, and both exited with status 0.

    This is a workaround for this particular state; the incompatible migration remains in 1.18.30.

  8. besty-boy commented on Sep 17, 2026

    @besty-boy
    besty-boy
    on Sep 17, 2026

    Confirmed still present in the latest stable release: OpenCode Desktop 1.18.31 (released 2026-09-14) on macOS, after the shared data directory was upgraded by the OpenCode 2 preview (opencode2 / @opencode-ai/cli 0.0.0-beta-18999).

    Same failure path as reported above: while booting, Project.migrateProjectId runs UPDATE workspace SET project_id = ... → SQLiteError: no such column: project_id → InstanceStore.boot fails → the UI only shows "Failed to load sessions" / "Failed to finish bootstrap instance".

    Data points from this case:

    • The V1 desktop build's migration set is 10 migrations behind the database (full list in desktop: bootstrap fails with "no such column: project_id" after data dir is migrated by OpenCode 2 #49614), including 20260808023530_workspace_domain and 20260823191254_nullable_workspace_binding; the workspace table is the V2 shape (id, provider, binding, created_at, last_used_at), so the V1 update can never succeed.
    • Caution for the schema workarounds in this thread: recreating the V1 workspace table (or restoring project_id) makes V1 work again but breaks V2 preview clients that share the same opencode.db. A version-aware startup error ("this data directory was upgraded by OpenCode 2") would be a good stopgap until the underlying fix lands.

    Full environment, logs, and analysis: #49614

  9. MiRacLe-RPZ commented on Sep 29, 2026

    @MiRacLe-RPZ
    MiRacLe-RPZ
    on Sep 29, 2026

    Can confirm this on CLI 1.18.33 (Linux) - so it's still present in the latest release, not Desktop-specific.

    One missing detail that explains why this only hits some projects on the same machine: Project.migrateProjectId only runs when the stored project id in .git/opencode doesn't match the freshly computed one (sha("git-remote:host/path")) - e.g. a stale marker from an older id algorithm or a changed origin URL. Every other directory short-circuits, which is why the DB-wide schema mismatch goes unnoticed until one project triggers the migration.

    Workaround that fixed it for us (table was empty in our DB): recreate workspace with the current schema:

    DROP TABLE IF EXISTS workspace;
CREATE TABLE workspace (
  id text PRIMARY KEY, type text NOT NULL, name text NOT NULL DEFAULT '',
  branch text, directory text, extra text,
  project_id text NOT NULL REFERENCES project(id) ON DELETE cascade,
  time_used integer NOT NULL DEFAULT 0
);

    Suggested fix: an idempotent startup heal - if PRAGMA table_info(workspace) has no project_id, recreate the table per current schema (legacy provider/binding rows are semantically incompatible anyway); and consider not orDie-ing inside migrateProjectId so a schema mismatch degrades to a logged warning instead of killing the process with no stack trace and nothing in the log.

  10. AAGavrilov commented on Oct 5, 2026

    @AAGavrilov
    AAGavrilov
    on Oct 5, 2026

    Confirming the same root cause on Windows with the OpenCode 2 renderer (bundled engine 2.0.18, channel latest) using the default shared data dir.

    Environment

    • opencode version: 2.0.18 (bundled engine; channel=latest)
    • OS: Windows_NT 10.0.19045 (win32 x64)
    • Terminal / shell: Desktop app / cmd.exe
    • Install/channel: desktop, latest
    • Active plugins: local + git plugins configured, mcp servers configured (not implicated)

    Symptom

    The renderer shows Unexpected server error. Check server logs for details. (status 500, ref err_...). The server log has:

    level=ERROR message=failed ref=err_... error="Error: no such column: project_id"
  at Project.migrateProjectId
  at Project.fromDirectory
  at InstanceStore.boot
  at Server.listen

    Schema (PRAGMA table_info(workspace)):

    id, provider, binding, created_at, last_used_at     -- no project_id

    Runtime code still runs the project-ID remap:

    UPDATE workspace SET project_id = <newID> WHERE project_id = <oldID>

    so Project.migrateProjectId fails for any non-global git project whose cached id in .git/opencode differs from the freshly computed id, which also takes down Project.fromDirectory / location boot for that directory.

    Workaround that worked here

    The DB was in WAL mode and workspace had 0 rows:

    1. Consistent backup: VACUUM INTO '<backup>' (this also compacted the source from ~1.65 GB to 185 MB).
    2. DROP TABLE workspace; then recreated it with the schema the current code declares:
    CREATE TABLE workspace (
  id text PRIMARY KEY,
  type text NOT NULL,
  name text NOT NULL DEFAULT '',
  branch text,
  directory text,
  extra text,
  project_id text NOT NULL REFERENCES project(id) ON DELETE cascade,
  time_used integer NOT NULL DEFAULT 0
);

    After this, every statement in Project.migrateProjectId compiles and runs, and creating/listing sessions in the previously failing directory works without restarting the app.

    Still reproducible on 2.0.18. The closed PR #42169 (not merged) describes the same fix direction. Suggest an idempotent startup heal: if PRAGMA table_info(workspace) has no project_id, recreate/skip the workspace remap instead of orDie-ing the whole bootstrap.

    Side observation: the live opencode.db was ~1.65 GB but compacted to 185 MB on VACUUM INTO, i.e. significant free-page bloat (related to #48917).

  11. aidan-ryan80 commented on Oct 14, 2026

    @aidan-ryan80
    aidan-ryan80
    on Oct 14, 2026

    Confirming this on the CLI/server path on Linux, opencode 1.18.33 (standalone/mise), not just Desktop.

    Symptom: launching opencode in a git project dies with the generic Unexpected server error. Check server logs for details. The real cause is only in ~/.local/share/opencode/log/opencode.log:

    level=ERROR message=failed ref=err_xxxxxxxx
error="SQLiteError: no such column: project_id"
  at Project.migrateProjectId (chunk-wtqeqnsg.js:2:3691)
  at Project.fromDirectory   (chunk-fxgjr2a1.js:2:1046)
  at InstanceStore.boot
  at Server.listen

    Server-side repro (no TUI needed):

    cd <git project> && opencode serve --port 43777 --print-logs --log-level DEBUG
curl -s localhost:43777/session     # -> 500 {"name":"UnknownError","data":{...,"ref":"err_..."}}

    Two conditions are required to hit it:

    1. The workspace table carries the provider/binding schema with no project_id.
    2. The project triggers a project-id remap, i.e. Project.resolve returns previous != id. In my case ./.git/opencode held a stale id from before the GitHub repo was renamed; the id derived from the current origin remote differed, so migrateProjectId ran and hit the broken table. Repos whose .git/opencode id already matches are unaffected.

    Workaround (verified): either delete the stale .git/opencode (opencode rewrites it with the correct id) or drop/recreate the empty workspace table with the expected schema:

    DROP TABLE workspace;
CREATE TABLE workspace (
  id text PRIMARY KEY, type text NOT NULL, name text NOT NULL DEFAULT '',
  branch text, directory text, extra text,
  project_id text NOT NULL REFERENCES project(id) ON DELETE CASCADE,
  time_used integer NOT NULL DEFAULT (unixepoch()*1000)
);

    Both fix it immediately. PR #42169 (rebuild the table when project_id is missing / skip the remap when the column is absent) addresses the real root cause; with it closed, Project.migrateProjectId still orDies on any DB carrying the provider/binding workspace schema, and the client only ever shows the generic 500.

    🤖 Drafted with opencode (deepseek-v4.1-flash) · reviewed and validated by @aidan-ryan80

  12. neriousy commented on Oct 20, 2026

    @neriousy
    neriousy
    on Oct 20, 2026
    Member

    Thanks for documenting the no such column: project_id failure and the risks of rebuilding the workspace table. Current v2 no longer runs the old workspace project-ID remap and uses the provider/binding workspace schema, removing this failing startup path. V1 now only receives critical fixes; please update the desktop app or install the current CLI with npm i -g @opencode/cli@latest. If session loading still fails on current v2, please open a new issue with the version and redacted server error rather than modifying the database schema.

  13. neriousy
    closed this as completedon Oct 20, 2026
  14. ninemate
    added a commit that references this issue on Nov 2, 2026

    OpenCode fails to start: "no such column: project_id" (AltharIDE#519)

    70d2ee5
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions