sessions: V1-migrated sessions are orphaned in the global project and hidden after upgrading to V2 #54640

Summary

After upgrading from V1 (opencode-ai 1.19.0) to V2 (@opencode/cli 2.0.26), all historical sessions are missing from the TUI session list. They are not deleted — 94 sessions remain in the V2 database — but the V1 migration left them attached to the synthetic global project (canonical: "/", subpath: "Windows/System32"), which no real directory resolves to in V2. Since the session list is scoped to the current location's project, the sessions are unreachable from the normal list (/sessions, <leader>l) and can only be found via Ctrl+O.

Environment

• opencode version: 2.0.26
• OS: Windows 10.0.26200.9457 (win32 x64)
• Terminal: Unavailable: terminal environment variables are not set
• Shell: C:\WINDOWS\system32\cmd.exe
• Install/channel: npm global, channel latest (@opencode/cli); migrating from npm opencode-ai@1.19.0
• Active plugins: None found in config (~/.config/opencode/opencode.jsonc only declares providers and MCP servers)

Reproduction

1. On V1 (opencode-ai 1.19.0), use the TUI from a non-git directory (C:\Windows\System32) and create sessions. V1 stores them under the global project with subpath: "Windows/System32".
2. Upgrade to V2 (@opencode/cli 2.0.26) and let the automatic V1 migration run to completion (GET /api/experimental/migration/v1 → {"status":"completed"}).
3. Start the TUI from the same directory (C:\WINDOWS\system32) and open the session list.
4. Only the newly created session appears; the 94 previous sessions are missing.

Expected Behavior

After migration, sessions previously associated with C:\Windows\System32 should be reachable from the TUI session list when working in that directory (V1 behavior preserved).

Actual Behavior

The migrated sessions stay attached to the global project (canonical: "/", subpath: "Windows/System32"). V2 now creates one project per directory, so C:\WINDOWS\system32 resolves to a brand-new project id, and the project-scoped session list shows none of the migrated sessions.

Evidence from GET /api/session?limit=5000:

• 95 sessions total
• 94 with projectID: "global" and subpath: "Windows/System32"
• 1 in the new per-directory project

GET /api/project returns only global (canonical: "/"), the current directory project, and C:\Users\<user> — no project exists that the migrated sessions can match.

Secondary related issue: project identity and the directory filter are case-sensitive on Windows. Creating two sessions with location.directory set to C:\Windows\System32 and C:\WINDOWS\system32 produces two different project IDs (e.g. 76fb832b… vs 6dc551d8…) for the same physical directory, and GET /api/session?directory=... matches case-sensitively (one value returns the migrated sessions, the other returns none).

Additional Context

• V1 migration status: GET /api/experimental/migration/v1 → {"status":"completed"}; all database migrations logged as completed.
• Data is intact. As a recovery step, all 94 sessions were moved to the current directory project with POST /api/session/{id}/move and {"directory":"C:\\WINDOWS\\system32"}; they then appear in the list normally. This confirms the issue is purely the project assignment left behind by the migration, not data loss.
• Workaround without mutating data: Ctrl+O ("Open recent sessions and projects") lists sessions across projects.
• Logs: ~/.local/share/opencode/log/opencode.log.