### Preflight Checklist - [x] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet - [x] This is a single feature request (not multiple features) ### Problem Statement # Feature Request: Portable / transferable sessions between Claude Code instances ## Summary Provide a first-class way to transfer a Claude Code CLI session: its full transcript, resumability, and associated project m

[FEATURE] Transfer session to another claude code instance

Status Open

Maintainer reply None cached

Workaround ✓ Mentioned in thread ↓

Activity 3 comments · opened Jul 2, 2026

Preflight Checklist

[x] I have searched existing requests and this feature hasn't been requested yet
[x] This is a single feature request (not multiple features)

Problem Statement

Feature Request: Portable / transferable sessions between Claude Code instances

Summary

Provide a first-class way to transfer a Claude Code CLI session: its full transcript, resumability, and associated project memory from one machine to another, so that claude --resume <session-id> works on a different host than the one the session started on.

Problem

Session transcripts are stored as machine-local JSONL files under ~/.claude/projects/<path-derived-dir>/<session-id>.jsonl, with no built-in sync or export/import. The existing machine-independence features don't cover the common infra-team workflow:

Cloud sessions / --remote / --teleport move execution onto Anthropic's cloud sandbox â^@^T unusable when the work requires the local environment (GPUs, mounted NFS datasets, internal APIs reachable only from the pod).
Remote Control (--remote-control) only steers a running local session from a browser/phone; it dies with the original machine.
CLAUDE_CONFIG_DIR pointed at shared storage is undocumented/partially implemented (GH #25762, #3833, #30538) and unsafe over NFS.
The only workaround today is hand-tarring ~/.claude between hosts â^@^T which is fragile, unofficial, and dangerous by default because ~/.claude also contains live credentials (.credentials.json); a naive copy to shared storage or S3 leaks auth tokens.

Proposed Solution

claude session export <session-id> [--out file] produces a self-contained, credential-free archive (transcript, project memory, optionally plans/file-history).
claude session import <file> on another machine egisters it so claude --resume <session-id> just works (validating/re-mapping the working-directory path).

Alternative Solutions

opt-in encrypted session sync via the user's Anthropic account, keeping execution local.

Priority

Medium - Would be very helpful

Feature Category

CLI commands and flags

Use Case Example

_No response_

Additional Context

I run long, stateful engineering sessions with Claude Code on ephemeral GPU dev pods (Kubernetes). Mid-project, the pod gets replaced e.g. moving from a 1-gpu H100 pod to an 8-gpu^WH100 pod to scale up a training run. The repo, shared NFS, and datasets all carry over; the session — hours of accumulated context: architectural decisions, verified numerical results, in-flight experiment state, agent memory — does not. Losing it means re-explaining the project or relying on hand-written handoff docs, which are lossy compared to the actual transcript. Pods are never concurrent, so this is a pure migrate-and-resume scenario, not a sync problem.

View original on GitHub ↗

3 Comments

kcarriedo · 19 days ago

The credential-safe export/import gap is real and the workaround you describe (hand-tarring ~/.claude) is exactly as fragile as it sounds. The credentials.json co-location problem is what makes any naive sync approach dangerous.

A few things worth noting from hands-on experience running multi-session workflows across machines:

The path-derived session directory structure (~/.claude/projects/<hash>/) creates an invisible dependency between the session file location and the source machine's filesystem path. Even if you copy the JSONL cleanly, --resume can fail silently on a different host because the path hash doesn't resolve the same way. A credential-free export format would need to embed the project path as metadata rather than encode it in the directory name.

The transcript-only export misses half the problem. Accumulated context (verified results, in-flight experiment state, what the agent tried and why it was wrong) lives in the conversation, but project memory that the agent wrote to memory files lives separately. An export that captures one without the other restores a partial picture.

The "safe over NFS" angle is worth tackling even before export/import: a lot of multi-machine Claude Code workflows run against shared storage (dev boxes, CI machines, remote desktops) and the CLAUDE_CONFIG_DIR instability on NFS is what forces the hand-tar workaround in the first place.

The proposed export/import surface (claude session export producing a credential-free archive) is the right shape. Would also be useful as the transport layer for the handoff pattern in orchestration setups where a session on one machine finishes a phase and needs to hand context to a session on another machine to continue.

CCCCY-ci · 6 days ago

This is almost exactly the problem I built CtxHop for.

It transfers Claude Code sessions between machines while keeping credentials out of the sync payload, and uses your own R2/S3-compatible storage for transport.

After restoring on the target machine, you can continue with Claude Code’s native resume flow.

https://github.com/CCCCY-ci/ctxhop

bessss89 · 4 days ago

Workaround that solves the "no chats after switching accounts" problem (not exactly session export/import, but the same underlying pain point)

This issue is about exporting/importing a session file safely (no leaked credentials), but I ran into the closely related problem — switching Claude accounts and losing access to chats started under the other one — and found a working solution I haven't seen documented anywhere, including in this issue or in the code-server discussions about Claude Code integration. Sharing in case it helps others who land here searching for the same thing.

The setup: two isolated code-server (VS Code server) containers, each running the Claude Code extension logged into a different account (separate CLAUDE_CONFIG_DIR, separate .credentials.json — no credentials ever move or get exported). Both containers mount the same host directory as their projects/ history folder (the one under CLAUDE_CONFIG_DIR/projects/<mangled-cwd>/). Both also need to run with the exact same cwd (down to the literal string) for their Claude sessions — the folder name under projects/ is a mangling of the absolute cwd, so any mismatch silently creates a separate, unshared history folder.

With that in place:

A session started in "Local" mode from either container is visible and live-syncing (confirmed via inspecting the .jsonl — same sessionId, no duplicate writers, no corruption) across both code-server instances, the claude.ai web app, and the mobile app, in real time, regardless of which account you're currently logged into in either container.
The actual answer to "I lost access to old chats after switching accounts": in the account that still has them, open the old chat from the "Web" tab in the extension panel (not "Local"). This materializes/downloads the full session as a real .jsonl file into the shared local projects/ folder — not all messages get imported, but enough of the transcript to recover context. From that point it behaves like any other local session: resumable via --resume, visible in "Local", and (via /remote-control inside that chat) it re-syncs back out to claude.ai/app under whichever account is currently active, keeping its original title.

This obviously requires infra you control (a container host, not something claude.ai gives you directly), and it's a workaround around the product's account-boundary rather than a real "export session" feature — but it fully solves "I have chats trapped under an account I can't currently use" without ever touching/leaking credentials, which seems to be the core concern in this issue too. Happy to share the full docker-compose if useful to anyone.