[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.