sessions: V1 legacy session rows unfindable in V2 /sessions because session.path is not normalized to project-root-relative form #54774

Summary

After upgrading a V1 install (1.18.x–1.19.x) to V2, legacy sessions are not shown in the TUI /sessions view for their project. V1 stored session.path relative to $HOME (e.g. home/user/Projects/foo) and project_id under the legacy global/git-repo projects; V2's project-scoped session list requires path relative to the project root ('' for root sessions), so exact-match lookups return zero rows and the view shows "No sessions available". Data is intact but effectively orphaned until project_id and path are migrated.

Environment

• opencode version: 2.0.27 (latest channel, curl install)
• OS: Linux (CachyOS 7.2.9-2-cachyos, x86_64)
• Terminal: xterm-256color (kitty), COLORTERM=truecolor
• Shell: /bin/fish
• Install/channel: latest
• Active plugins: @dietrichgebert/ponytail

Reproduction

1. Install V1 (1.18.x/1.19.x); open opencode in a directory that is not a git repo, e.g. ~/Projects/foo (or any dir), and create sessions. V1 stores these with project_id='global' (or the git repo project) and path relative to $HOME, e.g. home/user/Projects/foo.
2. Upgrade to V2 2.0.27. Migrations run (last: 20261010180456). V2 additionally registers one project per launch directory with new project IDs and project-root-relative path semantics.
3. Open the V2 TUI from ~/Projects/foo and run /sessions.

Expected Behavior

Legacy sessions created from that directory in V1 appear in the /sessions view (migration rebinds project_id/path to the V2 project model).

Actual Behavior

Sessions for foo → No sessions available. The sessions still exist: opencode api get '/api/session?limit=1000' lists them, and ?directory=<dir> also finds them, but the project-scoped query the TUI uses returns nothing.

Root cause (from the 2.0.27 binary, SessionStore.list):

if ("project" in e)       where project_id = e.project
if ("project" in e && e.subpath !== undefined) where path = e.subpath  // exact match

The TUI sends project=<v2-project-id>&subpath= for root sessions, while legacy rows keep path='home/<user>/...' (and project_id='global' or a V1 project ID), so path = '' never matches.

Verified: with a legacy row for /home/user/Projects/foo, ?project=<v2-id> → 0 rows, ?project=<v2-id>&subpath=home/user/Projects/foo → the row; after rewriting the row to project_id=<v2-id>, path='' the same TUI-style query returns it.

Affects every V1→V2 install with legacy sessions, including sessions that were already bound to V1 git-repo projects (root-level rows keep the old home-relative path while new V2 rows use '', so a project mixes visible and invisible sessions — e.g. only sub-directory sessions appear).

Workaround (manual SQL, after backing up the DB): for each legacy row set project_id to the V2 project owning its directory and path to the path relative to that project root ('' when the directory is the root), in both session and session_v2.

Additional Context

• Migrations include 20260601010001_normalize_storage_paths, but it does not normalize session.path against the V2 per-directory project model.
• No in-API path migrates/binds legacy sessions to their V2 project (session.list is the only session query endpoint; session.import is for JSON exports).
• Consistent 100%: every legacy root-level session is affected; search and "all projects" still work as a stopgap.