Skip to content

migrate: V1 sessions invisible in V2 (kept on legacy "global" project id) #57145

Closed as duplicate

Description

@fahrim

Description

After migrating from OpenCode V1 (1.18.4) to V2 (2.0.32), the V1 sessions were copied into the database but never show up in the V2 session list (CLI opencode session list and TUI /sessions).

Cause: the migrated sessions keep the V1 project binding (projectID: "global", subpath: "root"), while V2 resolves the same working directory to a new project id (e.g. cd31f2124f23…, canonical /root, subpath: ""). Because the session list is scoped to the current project, the migrated sessions are invisible even though they sit in the same directory.

The data itself is intact:

  • session_v2 contains all 10 migrated sessions with project_id = 'global', path = 'root'
  • GET /api/session (no project filter) returns all of them
  • GET /api/session?project=global returns all 10 with full message history
  • GET /api/session?project=<v2-project-id> returns only sessions created in V2

OpenCode version

2.0.32 (migrated up from 1.18.4)

Steps to reproduce

  1. Use OpenCode V1 (1.18.4) in a directory (e.g. the home directory). V1 stores those sessions under the global project with path: "root".
  2. Upgrade to OpenCode V2 (2.0.32) and start it in the same directory.
  3. Run opencode session list → only the session created in V2 is listed, the V1 sessions are missing.
  4. Inspect the database → the V1 sessions exist in session_v2, but bound to project_id = 'global' while V2 created a separate project row for the same directory.

Expected behavior

V1 sessions should be visible in the V2 session list / TUI for the directory they belong to, without manual intervention.

Actual behavior

Migrated sessions remain attached to the legacy global project id, while V2 creates a new project id for the same directory, so the project-scoped session list never returns them.

Workaround

Re-bind each session with the supported move API, which recomputes the project for the target directory:

opencode api post /api/session/<sessionID>/move --data '{"directory":"/root"}'

After that the sessions appear in opencode session list. Side effect: move sets time_updated to "now", so the original ordering/dates in the session list are lost unless time_updated is restored manually (the original values are still present in the legacy session table).

Operating System

Ubuntu 22.04 (Linux 6.8.0-31-generic, x86_64)

Terminal

xterm-256color

Plugins

None

Activity

  1. opencode-agent commented on Oct 19, 2026

    @opencode-agent
    Contributor

    Thanks for the detailed report and the workaround! I think this is a duplicate of #49827: in both, V1 sessions from a non-git directory stay under the legacy global project after migrating, so the project-scoped V2 session list doesn't show them.

    Possible duplicates and related issues, ordered from most to least likely:

    If you have anything new, such as the move workaround resetting time_updated, adding it to #49827 would help.

    The bot will close this issue as a duplicate in 1 day unless you reply explaining how your problem is different.

  2. fahrim commented on Oct 19, 2026

    @fahrim
    Author

    Duplicate of #49827 (and #51176 / #50551 / #50800 / #50999 / #52919 / #53450).

    The extra detail I was going to add — that the session move workaround resets time_updated to "now" — is already documented in #49827, together with the recovery of the original values from the legacy session table, so there is nothing left to add here. Closing in favour of #49827, which also tracks PR #51935.

  3. opencode-agent commented on Oct 20, 2026

    @opencode-agent
    Contributor

    Closing this as a duplicate of #49827. There's been no reply in the past day to say how this differs. That issue covers the same problem: V1 sessions from non-git directories stay under the legacy global project after migration, so the V2 session list for that directory doesn't show them. A fix is proposed in PR #51935.

    Thanks again for the report and the move workaround. Adding the time_updated side effect to #49827 would help. If your case does turn out to be different, reply here and we can reopen it.

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

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions