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

[Lenoridev]

I would like maintainer approval for copying a plain-folder workspace and its thread to another connected environment. This overlaps the proposed “Bring to local” workflow above, with a specific case: the project is an ordinary local folder that has never been a Git repository. Examples include prototypes, scripts, documents, and generated assets that exist only on one machine.

The conversation import in #16731 and handoff in #16751 look like the right foundation. In the current #16751 code, HandoffNotARepositoryError falls back to conversation-only transfer, so the workspace files do not arrive. The receiving flow also expects a destination project. I would like to contribute folder packaging and fresh destination project creation using those services.

Proposed first scope:

• One stopped thread and the non-Git folder where it actually worked. Copy into a new destination directory chosen by the user, register a project there, and attach a fresh imported thread. No matching destination project or Git initialization is required.
• Retain the complete user/assistant transcript, attribution, timestamps, and supported message attachments. Use the destination's available provider for continuation, with the existing context budget and access to older imported history.
• Copy nested and empty directories, text and binary files, and supported executable permissions. Show file exclusions and size limits before transfer, allow explicit selection of sensitive project files such as .env, and report unsupported names, links, permissions, or file types. Do not follow symlinks outside the selected root.
• Copy semantics: preserve the source folder and history. Do not automatically start an agent or execute imported setup scripts. Prevent queued work from starting during capture and detect conflicting workspace changes rather than silently taking an inconsistent snapshot.
• Validate and stage the payload before exposing the destination project/thread. Failed or cancelled imports must leave existing destination work intact; retries must avoid duplicate threads or projects.
• Reuse authenticated environment connections and HTTP byte transport, with server services, typed contracts, shared client orchestration, and capability checks. Initial entry points would be web/desktop thread menus.

I suggest connected-environment copying first. Archive export/import for independent installations and project exports containing multiple threads can follow using the same services. Projectless scratch folders could be included if you consider them part of the initial scope. Git history transfer, native provider session migration, live processes, and ongoing synchronization would remain separate work.

Planned verification: two isolated T3 environments, a source folder with no .git, and a destination with no matching project. Compare file paths/hashes and full transcript ordering; confirm the imported folder remains non-Git; continue with a destination provider that reads a transferred file and retrieves an older requirement. Also cover exclusions, binary/empty-directory fidelity, source changes, destination collisions, corrupt payloads, cancellation, interrupted imports, retries, and old-server capability gating. No implementation or verification results are being claimed here.

Would you approve this direction and scope for a contribution, and which part of the current handoff stack should own folder import and new project creation?

Prepared with GPT-6.1-Sol in the Codex harness through T3 Code.

[JohanSardar]

Same need here. I run T3 Code on two Macs (both connected through T3 Connect) and wanted to move a long thread from one to the other so it keeps running there. Today the only option is starting fresh from a handoff note. A "Transfer to…" action on the thread would solve it.

[jaypopat]

Continue active work on a preferred environment before laptop sleep

I start agent work on my laptop and sometimes need to leave or suspend it before the work finishes. I already use the option to add a project to another environment, such as my always-on home lab.

I’d like to select a preferred continuation environment and hand off an active thread, its conversation, and its current workspace so the work continues there.

A useful first version would offer “Continue on Home Lab after this turn.” It should check destination readiness, transfer unpushed commits and local changes, prevent both copies from running, and show a link to the destination thread. A failed transfer should leave the source usable.

Later, opt-in idle or battery triggers could prepare the handoff before sleep. Closing the lid should only promise continuation when the transfer has completed; a suspend notification may arrive too late.

Portable conversation context in a fresh provider session would satisfy my initial use case. Exact native-session preservation and moving running subprocesses can remain outside this scope.

This could build on #16751. Would maintainers support this direction, and should the preferred destination and automatic triggers be tracked separately?

Prepared with Codex (GPT-6) via T3 triage.

[Aryan-Saini]

Same need. I'm a student and do my work on my laptop, but before class I want to send the running thread to my desktop so it keeps going while the laptop is closed. Starting the thread on the desktop from the beginning works, but I'd rather work on the laptop and send it over when I leave.

#16751 covers this. Having the agent move its own thread ("send this to my desktop after this turn") is the part I'd use most. For the UI follow-up, a "Send to…" action in the thread menu would make it a one-click thing before heading out.

[kesslerio]

I’d love this feature, would be awesome to start something on one host and then move to another.