Skip to content

tui: V1→V2 migration stores stripped absolute dir in session.path, hiding sessions from /sessions #53709

New issue
New issue
Closed as not planned
Closed as not planned
tui: V1→V2 migration stores stripped absolute dir in session.path, hiding sessions from /sessions#53709
Assignees
kitlangton

Description

@Frey-Fu
Frey-Fu
opened on Oct 7, 2026

Description

After upgrading the CLI from V1 to V2, pre-existing sessions disappear from the TUI /sessions dialog — from both the default list and the title search. The session data and the fix's prerequisites are intact, but the V1→V2 importer keeps session.path unnormalized: it stores the absolute directory with the leading slash removed (e.g. Users/alice/Projects/foo) in a column that must hold the path relative to the project worktree (empty string at the project root). The /sessions dialog filters by the current relative path, so these migrated sessions never match.

A maintainer reproduced this on 2.0.20 and identified the V1 sequence behind it: sessions created in a non-git directory are filed under the global project with the stripped absolute path; after git init, V1 moves the sessions to the new project but leaves path unchanged; V2 then copies path as-is into session_v2.

Same underlying problem is tracked (still open) in #49827, #50551, #50800 and #51176. The suggested duplicate #52844 was automatically closed for template compliance, not because the bug was fixed. Two proposed fixes are still open and unmerged: #51935 (migration-time re-attribution + repair on next start) and #54048 (runtime resolution for markerless directories).

Plugins

oh-my-opencode-slim@latest, @mohak34/opencode-notifier@latest, @openviking/opencode-plugin, plus one local file:// plugin. (The bug also reproduces with plugin behavior factored out; it is caused by the importer, not a plugin.)

OpenCode version

2.0.20 (Homebrew, latest channel). Original sessions created with V1 1.18.x; V1 desktop 1.18.34 still shows them because it lists by directory without this path filter.

Steps to reproduce

  1. In V1, create sessions in a directory that is not yet a git repo. V1 stores them under the global project with path = absolute directory without leading slash, e.g. Users/alice/Projects/foo.
  2. git init that directory and use V1 there again. V1 moves the sessions to the new git project but leaves path unchanged.
  3. Start V2. The background migration runs (GET /api/experimental/migration/v1 → {"status":"completed"}) and copies path unchanged into session_v2.
  4. Open the TUI at the project root and run /sessions.

Observed in the database:

SELECT id, path FROM session
WHERE path LIKE 'Users/%' OR path LIKE 'private/%';

Expected behavior

Migrated sessions at the project root have path = '' (path relative to the worktree) and show up in /sessions and the dialog search, matching how V1 listed them.

Actual behavior

The migrated sessions keep the stripped absolute path, so they are absent from the default /sessions list and from title search. They can only be reached via the "all projects" toggle, marked ... Messages/parts are intact and the HTTP API (/api/session) returns the sessions; only the TUI dialog hides them. On this machine 79 rows were affected (18 in the git project, 61 still under global), in both session and session_v2.

Stopgap used to restore visibility (database backed up first), confirmed working:

UPDATE session     SET path='' WHERE path LIKE 'Users/%' OR path LIKE 'private/%';
UPDATE session_v2  SET path='' WHERE path LIKE 'Users/%' OR path LIKE 'private/%';

then opencode service restart. An alternative per-session repair is POST /api/session/{id}/move with the same directory.

Operating System

macOS (Darwin 25.4.0, arm64)

Terminal

Apple Terminal (TERM=xterm-256color, COLORTERM=truecolor); shell /bin/zsh.

Screenshot and/or share link

None.

Activity

  1. github-actions
    assigned
    kitlangton
    on Oct 7, 2026

  2. github-actions commented on Oct 7, 2026

    @github-actions
    github-actionsBot
    on Oct 7, 2026 – with GitHub Actions
    Contributor

    This issue doesn't fully meet our contributing guidelines.

    What needs to be fixed:

    • Please use the Bug Report issue template and include its required Description field. The current body uses a custom Summary heading and does not include that required field.

    Please edit this issue to address the above within 72 hours, or it will be automatically closed.

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

    • #52844: V1→V2 migration leaves session.path unnormalized, hiding migrated sessions from the TUI /sessions list.

    If you believe this was flagged incorrectly, please let a maintainer know.

  3. github-actions
    added
    needs:complianceThis means the issue will auto-close after 2 hours.
    on Oct 7, 2026

  4. opencode-agent commented on Oct 7, 2026

    @opencode-agent
    opencode-agentBot
    on Oct 7, 2026 – with OpenCode Agent
    Contributor

    Thanks for the detailed report. I was able to reproduce this on 2.0.20 with a real V1 (1.18.34) database:

    1. With V1, create sessions in a folder that is not yet a git repo. V1 stores them in the global project with path set to the absolute directory without its leading slash, e.g. Users/alice/Projects/foo.
    2. git init the folder and use V1 there again. V1 moves those sessions to the new git project but leaves the old path as it was. This likely explains your affected rows in a project other than global.
    3. Start V2. The V1→V2 migration copies path unchanged into session_v2.
    4. Run /sessions at the project root. Only sessions with path = '' are listed; the migrated ones are missing from both the list and the search, and only show up with the "all projects" toggle, marked ...

    The same unchanged copy also leaves the stripped absolute path on migrated sessions that stay in the global project. Your SQL workaround (after a backup) is a reasonable stopgap for now.

  5. Frey-Fu commented on Oct 10, 2026

    @Frey-Fu
    Frey-Fu
    on Oct 10, 2026
    Author

    Updated the body to follow the Bug Report template, with the required Description field first (followed by Plugins, OpenCode version, Steps to reproduce, Expected/Actual behavior, OS and Terminal). Could the compliance check please be re-run? Note the suggested duplicate #52844 was auto-closed for template compliance, not resolved; the root-cause issues (#49827, #50551, #50800, #51176) remain open and the proposed fixes #51935 / #54048 are unmerged.

  6. Frey-Fu commented on Oct 10, 2026

    @Frey-Fu
    Frey-Fu
    on Oct 10, 2026
    Author

    This is confirmed and reproduced, and it affects every existing V1 install that upgrades, so it would be good to land a fix rather than leave users on manual DB edits.

    Two open PRs already address it (both mergeable against v2, neither reviewed yet):

    Could a maintainer indicate which approach is preferred (migration-time vs runtime resolution, or whether both layers are wanted) and review the chosen one? Happy to help with review, rebase, or extra coverage on whichever PR you'd like to move forward. The root-cause issues #49827, #50551, #50800, #51176 are still open, so merging one of these would close a broad cluster.

  7. github-actions commented on Oct 10, 2026

    @github-actions
    github-actionsBot
    on Oct 10, 2026 – with GitHub Actions
    Contributor

    This issue has been automatically closed because it was not updated to meet our contributing guidelines within the 72-hour window.

    Feel free to open a new issue that follows our issue templates.

  8. github-actions
    removed
    needs:complianceThis means the issue will auto-close after 2 hours.
    on Oct 10, 2026
  9. github-actions
    closed this as not plannedon Oct 10, 2026
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