[Feature]: Transfer a provider-native session between T3 Connect environments

[ElliotDrel]

Before submitting

• I searched existing issues and did not find a duplicate.
• I am describing a concrete problem or use case, not just a vague idea.

Area

T3 Connect / remote environments, apps/server, and apps/web

Problem or use case

T3 Code lets me configure and access multiple environments through T3 Connect, but a session remains tied to the machine where it started.

For example, I may start a long-running Claude Code or Codex session on Computer A, then need to shut that computer down and continue from Computer B. Both environments may already have the same provider CLI installed and be configured in T3 Code, but there is no one-click way to move the existing session to the other environment.

Starting a new thread or giving the destination model a summary is not equivalent. The destination CLI should recognize the conversation as the same provider-native session, with the same history and continuation state it would have had on Computer A.

Proposed solution

Add a Transfer Session action that moves an active or paused T3 thread from one configured environment to another.

From the user's perspective:

1. I start a session on Computer A.
2. I click Transfer Session.
3. I select Computer B from my configured T3 Connect environments.
4. T3 safely pauses or stops the provider process on Computer A.
5. T3 copies the provider's relevant native session files, history, resume cursor/session ID, and any required T3 metadata to Computer B.
6. T3 updates the thread's environment binding.
7. The same CLI resumes the same native conversation on Computer B.
8. The existing T3 conversation remains visually unchanged; only the execution environment changes.

The destination CLI should behave as though the conversation had been running on that machine all along. This should not create a fresh provider session with only a transcript or summary injected into it.

Required behavior

• Keep the same T3 thread and full visible conversation.
• Preserve the provider-native session identity and continuation state, not only the rendered transcript.
• Copy or recreate every provider-specific session-history file required for native resume on the destination.
• Pause or stop the source runtime before migration so both machines cannot continue writing to the same logical session.
• Change the thread's execution-environment binding only after the destination session is ready.
• Roll back cleanly if migration fails, leaving the source session resumable.
• Clearly show which environment currently owns the session.
• Run a preflight check for compatible provider/CLI versions, authentication, project availability, paths, and other required configuration.
• Warn about state that cannot be migrated, such as active subprocesses or machine-local services.

Provider scope

This should be a provider-neutral T3 capability with provider-specific migration implementations.

An initial version could support Claude Code and Codex when the same provider and a compatible CLI version are installed on both environments. Other providers could be added through the same abstraction later.

Credentials and secrets should not need to be copied if the destination is already authenticated. T3 should validate that the destination provider is usable before beginning the transfer.

Project state

Native conversation history is only useful if the destination sees the expected project state. The transfer flow should therefore either:

• verify that the same repository/worktree and relevant uncommitted changes already exist on the destination, or
• offer to transfer the required working-directory state as part of the handoff.

It should never silently resume against a materially different checkout without warning the user.

Smallest useful scope

A reasonable MVP could support:

• paused or stopped sessions only;
• the same provider on both environments;
• compatible provider CLI versions;
• a project/worktree that already exists at a compatible destination path;
• copying provider-native session files and updating the T3 thread binding;
• resuming the same native session on the destination;
• clear preflight, progress, failure, and rollback states.

Live subprocess migration, cross-provider migration, and automatic transfer of every machine-level dependency can remain out of scope initially.

Why this matters

Users often move between a laptop, desktop, workstation, server, or cloud VM. Today, the safest approach is to predict which machine will need to stay online and start the session there from the beginning.

A real session-transfer flow would make long-running agent work portable. The user could close one machine without abandoning the thread, manually copying hidden session files, or forcing the model to reconstruct context it believes it already has.

Alternatives considered

• Start every session on a remote server: works only when the user predicts the need in advance.
• Start a new session with a generated summary or transcript: preserves some text, but not the provider's native conversation state, tool history, compaction state, or exact continuation behavior.
• Manually copy provider session directories and project files: provider-specific, fragile, easy to get wrong, and not reflected automatically in T3's environment/thread binding.

Related but distinct issues

• feat: remote parity with ssh + codex resume on the same host #510 covers importing and resuming existing Codex sessions from the same host where T3 is already running.
• [Bug]: Stopped Claude thread silently loses native context when switching compatible provider instances #4766 covers preserving a Claude resume cursor when switching compatible provider instances, not copying a session between machines.
• [Feature]: Switch provider/model mid-conversation via transcript handoff #3797 proposes transcript handoff when switching providers/models, not migration of the same provider-native session across environments.

Risks or tradeoffs

• Provider session formats and storage paths differ, so migration likely needs a provider adapter rather than one generic file-copy rule.
• Absolute paths, OS differences, CLI-version differences, and machine-local MCP servers may prevent a safe transfer.
• Authentication and secrets should be validated on the destination rather than copied blindly.
• The source must not remain independently resumable after a successful transfer without an explicit conflict-resolution model, or the session could split into divergent histories.

[Fenris159]

I would also like to see this feature implemented. I notice you could do this with the Kilo extension on VS Code in the same thread. I can change model providers seamlessly and it picks up where it left off. I'm assuming there's some kind of caching of the context window history to a reasonable number of messages and then that context is just passed off into the next model via the header file so the next agent gains all of that insight and assumes the response.

If the header file contained the previous conversation, it probably follows up with "Pretend we had this conversation and pick up where you left off" or something akin to that.

I wouldn't imagine it would be so difficult to implement.

[kbdevs]

I would like maintainer approval for a narrower Bring to local workflow related to this proposal. The immediate use case is starting agent work on a remote machine, then bringing the project and conversation onto a laptop/desktop to continue editing and run development tools and the Browser locally.

The requested behavior is a one-time handoff into a new local thread, using portable conversation context. It does not require moving the provider-native session identity described in the original proposal.

Proposed scope for one PR:

• Offer Bring to local on a remote thread when a compatible local T3 environment is connected. Create a fresh local project directory so existing local work cannot be overwritten.
• Copy the remote thread's actual workspace, including binary files, untracked files, modified files, and deletions. Preserve the current Git commit/branch and staged versus unstaged changes. Worktree transfers must produce a self-contained local repository rather than copying a .git pointer that still names the remote machine.
• Make file exclusions explicit before transfer. Include project configuration and provide a choice for ignored project files such as .env; do not silently omit them. Regenerable dependencies/build caches and machine-level credentials are not copied by default. Report skipped or unsupported files.
• Bring over the conversation as attributed context in a new local thread, retaining the full transferred transcript for retrieval. Use a provider/model available on the destination. Make clear that native provider tool state and running processes are not migrated.
• Stop the original remote thread only after the local files and new local thread have been successfully prepared. Keep its history and files available. Failed or cancelled transfers leave the source usable. If stopping the source fails after import, retain the local copy and show that the remote thread still needs stopping rather than pretending the handoff completed.
• Require a stable workspace snapshot. A first version can wait for the current remote turn to settle and prevent queued work from starting during capture; it must detect conflicting workspace changes and refuse a stale transfer. No live subprocess migration or ongoing bidirectional synchronization.
• Use the existing authenticated environment connections and HTTP attachment byte transport, keeping archive bytes off the WebSocket. Put export/import behavior in server services, with typed contracts and shared client orchestration. Gate actions against older servers.
• Initial user-facing entry points: web/desktop thread menus when a local environment is available. Mobile has no local server filesystem, so it should not offer a misleading “local” target. The transfer primitive should remain usable by other clients/tools against an explicitly selected destination.

Existing portable handoffs supply conversation-selection logic, but they do not copy project files between environments. Related discussions: #16570 concerns moving a worktree to its checkout on the same environment; #16568 concerns where Browser URLs open.

Planned verification for the eventual PR: two isolated environments; real Git repositories and worktrees; binary/untracked/ignored files; staged edits and deletions; long conversation context retrieval; destination provider mismatch; source changes during transfer; cancelled/failed import; failure to stop the source after a successful import; old-server capability gating. UI evidence would cover the complete remote-to-local flow. No implementation or verification results are being claimed here.

Would you approve this direction and scope for a contribution, or prefer it to remain part of the broader native-session migration proposal?

Prepared with gpt-6.1-sol in the Codex harness through T3 Code.