Move a thread to another environment, with its conversation and uncommitted work

[OmarAlex24]

The problem

I start most work on my Mac. Some of it turns out to belong on my server: long agent runs that should keep going after I close the laptop, or work that needs that machine's hardware or network. By then the thread has the context I care about (investigation, decisions, a half-done change in the working tree).

Today I can't take that thread with me. A draft can move to another machine before its first send (thread-sidebar.md), but a thread that has started can't. delegate_task to a linked environment sends only a text prompt, and it runs in that project's checkout without my uncommitted changes. So my workaround is:

1. stop the agent
2. commit or stash a WIP and push it
3. pull it on the server
4. start a new thread there
5. paste a summary of the old one by hand

Proposal

A Move to environment… item in the thread menu and the command palette. It is a copy plus archive, not a re-homing. The new thread belongs to the destination environment and the old one stays where it was. That keeps the rule in remote.md that a project and its threads belong to one environment.

1. Pause. If a turn is running, stop it the way thread.stop does, holding the queue, and capture a checkpoint.
2. Carry the workspace. Checkpoints are already git commits under refs/t3/... that include uncommitted and untracked (non-ignored) files. Export the branch commits plus that checkpoint as a git bundle. On the destination:
   • find the project by repository identity, as delegate_task does
   • fetch the base from the remote
   • create a worktree on the same branch with the bundle applied
3. Carry the conversation. Create the thread on the destination with the copied messages. Its first turn starts a fresh provider session with the existing portable handoff, as a provider switch does. The native provider session lives on the source disk, so it isn't moved.
4. Close out the source. Archive the original thread with a link to the new one. Nothing is deleted, so a failed move loses nothing.

Proposed scope for a first version

• Only threads in a git project whose repository also exists on the destination
• Only threads without subagents
• The client (web/desktop) runs the move between the two environments, as the draft move already does. It does not depend on Labs peer links.
• Work is carried only through git, so gitignored files (.env, node_modules, build output) do not travel. The confirmation dialog says so.

Out of scope: threads in No project, native provider session state, terminals and previews, and moving back automatically.

Open questions

• Is copy plus archive the right model? The alternative is a true move that keeps the thread id.
• Should the bundle travel through the attachment upload (50 MiB limit) or through a dedicated endpoint?
• Should the first version require a clean or pushed base and refuse otherwise? It would be smaller, but it would drop the uncommitted-work case.

Related: #6857 and #23882 (moving a thread between projects in the same environment; #6857 explicitly left cross-server moves out of scope).

I'd like to implement this once the direction and scope are agreed.

[djgilcrease]

NOTE: This comment was left by claude-fable-5-2 unknown-effort on behalf of Dj Gilcrease.

I built this as an external plugin, Rehome, to see how the proposal holds up in practice. It runs on the plugin host prototype from #23574, not on stock T3 Code, so it is evidence for the design here rather than an upstream implementation. It does not take the place of the implementation the author offered to do. The write-up with screenshots is in this comment on the plugin discussion.

It follows the proposal closely: a Move thread… action on a started thread, copy plus archive, the checkpoint and branch commits as a Git bundle, the destination project found by repository identity, the thread created with the copied messages, and the source archived with a note. It keeps the proposed first-version scope: Git projects that exist on both machines, no subagent threads, and ignored files stay behind, which the confirmation says.

What building it suggests for the open questions:

• Copy plus archive is enough. The new thread belongs to the destination and nothing needed a shared thread id. Archiving the source only after the copy exists is what makes a failed move lose nothing. One consequence: the source thread's page closes when it is archived, so the result has to be shown somewhere that outlives it.
• Neither the attachment upload nor a new endpoint was needed for the client-driven move. The client carries the bundle between the two environments in chunks over the connection it already has to each, so it does not depend on either machine reaching the other. I capped it at 64 MB of new work. A second path, where the destination pulls from the source over HTTP, covers larger transfers and callers with no client in the middle.
• A clean or pushed base is not required. Before bundling, the destination reports the commits it already has, and the source bundles only what is missing. Unpushed commits and uncommitted changes travel together, and work that was already pushed or fetched does not travel twice.

Two things in the proposal worked differently than I expected:

• "The existing portable handoff, as a provider switch does" does not apply directly. A provider switch hands over only the thread's own earlier runs, and a copied thread has none. The path that fits is the one T3 uses for imported history: messages stored without a run are handed to the first turn's new provider session. The copy's first turn received all the copied messages that way.
• "Create a worktree on the same branch" needs a rule for name clashes. If the destination already has that branch with other commits, or has it checked out, the moved work goes to <branch>-moved and the result says so. An existing branch is never rewritten.

Not covered: moving back automatically, threads in No project, native provider session state, terminals and previews, all as the proposal lists. A very long conversation is trimmed to its first message and the most recent ones, up to 2,000; the archived original keeps the rest.