[FEATURE]: Add session migration dialog to recover orphaned or misplaced sessions

[sim590]

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Add a TUI dialog that allows users to migrate sessions between projects. This serves three main use cases:

1. Recovering orphaned sessions — When a project directory is renamed or moved (Sessions become orphaned when project directory is renamed #23248, Session lookup fails with NotFoundError when PTY spawned from non-git directory context #8538), sessions become invisible because their directory field points to a path that no longer exists. The migration dialog shows all sessions across all projects, marks orphaned ones with a visual indicator, and allows moving them to the correct project.

2. Intentionally migrating sessions between projects — When work was started in the wrong project, users can move the session (with its full conversation history) to another project rather than starting over.

3. Deleting orphaned sessions — Since orphaned sessions don't appear in the normal /sessions list, there is currently no way to delete them. The migration dialog provides access to these sessions for deletion.

Proposed solution:

• A new "Migrate Session" dialog accessible via ctrl+o from the session list
• The dialog shows all sessions across all projects, grouped by project
• Orphaned sessions are marked with a ! indicator in the gutter
• Selecting a session opens a destination picker (current project, home directory, or any known project)
• ctrl+d allows deleting sessions (with double-press confirmation)
• New server routes GET /session/orphans and POST /session/:sessionID/migrate

Note: this does not fix the root cause of orphaned sessions (#23248). An automatic fix in fromDirectory() would still be valuable.

[rektide]

One additional wrinkle, that perhaps deserves it's own ticket: opencode session list will show sessions that opencode tui will not show. The TUI requires both the session's project-id to match and the directory to match, where-as the cli only requires one (I think the directory?). The inconsistency can be confusing.

I've tackled this on the cli with #24728. One thing I like about my cli work: I can very quickly mass-target sessions for moving, using directories (with wildcard support!) (or project id or session id). As someone who has a lot of jj workspaces, and often a lot of sessions in each, my cli PR should let me quickly move a lot of sessions with ease. I'd love to have both good cli tools, and good tui tools. In #24726 we also started to see some api tools as well, which is another important leg of the session management triangle/polygon.

[sim590]

Hi! I'm the author of #23250 (the TUI migration dialog). I noticed there are now three PRs tackling session migration from different angles:

• feat(tui): add session migration dialog #23250: TUI dialog for migrating sessions interactively (ctrl+o in session list), plus backend routes (GET /session/orphans, POST /session/:sessionID/migrate)
• feat(session): add methods to migrate session #24726 (@Alchuang22-dev): Backend routes (same endpoints) reimplemented using Effect Service + httpapi, CLI commands (session orphans, session migrate), GET /session/history with cursor pagination
• feat: opencode session move / session detached #24728 (@rektide): CLI-only approach with session move (bulk selection via wildcards) and session detached (advanced orphan detection via git rev-list)

There's significant overlap on the backend side between #23250 and #24726: same API paths, same functions (listOrphans, migrate). Since #24726 already reimplements the backend using Effect Service (which is more idiomatic with the project's conventions), I'd be happy to drop the backend portion of #23250 and rebase my TUI dialog on top of that instead.

I also want to acknowledge @rektide's points about bulk migration with wildcard support and the --dry-run workflow. Those are valid use cases that the backend API should probably accommodate. It would be worth agreeing on a shared backend implementation that serves all three surfaces (TUI, CLI, and bulk operations) before we move forward independently.

Let's keep the discussion here on this issue rather than spreading it across the individual PRs, so we can converge on a unified approach.

[sim590]

@kitlangton Heads up: this issue now has three open PRs (#23250, #24726, #24728) with overlapping backend implementations. We're trying to coordinate here to avoid duplicating work. Would appreciate your input on which direction to take for the backend so we can align our efforts.

Also, #23250 was automatically closed by the cleanup bot (not enough reactions, never reviewed). I've left a comment requesting it be reopened. It's the only PR that provides the TUI dialog for session migration, which the other two PRs intentionally leave out.