Repository navigation
[FEATURE]: Add session migration dialog to recover orphaned or misplaced sessions #23249
Description
Activity
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.
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+oin 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/historywith cursor pagination - feat:
opencode 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.
Reacted by rektide- feat(tui): add session migration dialog #23250: TUI dialog for migrating sessions interactively (
@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.
Reacted by NotFoundTo stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
Reacted by endolithAnybody interested in this feature can lookup the plugin where I moved the implementation of #23250:
Feature 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:
ctrl+ofrom the session list!indicator in the gutterctrl+dallows deleting sessions (with double-press confirmation)GET /session/orphansandPOST /session/:sessionID/migrateNote: this does not fix the root cause of orphaned sessions (#23248). An automatic fix in
fromDirectory()would still be valuable.