Repository navigation
[FEATURE]: Add session migration dialog to recover orphaned or misplaced sessions #23249
Description
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:
-
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
directoryfield 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. -
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.
-
Deleting orphaned sessions — Since orphaned sessions don't appear in the normal
/sessionslist, 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+ofrom 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+dallows deleting sessions (with double-press confirmation)- New server routes
GET /session/orphansandPOST /session/:sessionID/migrate
Note: this does not fix the root cause of orphaned sessions (#23248). An automatic fix in fromDirectory() would still be valuable.
Activity
rektide commentedon Apr 28, 2026
One additional wrinkle, that perhaps deserves it's own ticket:
opencode session listwill 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 commentedon Apr 28, 2026
Hi! I'm the author of #23250 (the TUI migration dialog). I noticed there are now three PRs tackling session migration from different angles:
ctrl+oin session list), plus backend routes (GET /session/orphans,POST /session/:sessionID/migrate)session orphans,session migrate),GET /session/historywith cursor paginationopencode session move/session detached#24728 (@rektide): CLI-only approach withsession move(bulk selection via wildcards) andsession detached(advanced orphan detection viagit 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-runworkflow. 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 commentedon May 18, 2026
@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.
github-actions commentedon Jul 18, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
sim590 commentedon Aug 26, 2026
Anybody interested in this feature can lookup the plugin where I moved the implementation of #23250:
https://github.com/sim590/opencode-session-migrate