All guides
Claude Code logo
Claude Code

Claude Sync: Keep Claude Code Sessions on Every Device

Claude Code doesn't sync sessions between machines. Where your history actually lives, why copying ~/.claude breaks resume, and how to move it losslessly.

You set up a new machine, install Claude Code, cd into the project you've been working in for months, and run claude --resume.

Empty list.

The history isn't gone. It's on the old laptop, in a folder literally named after a path that doesn't exist on the new one — something like -home-alice-code-app. That dash-mangled name is the whole story of why Claude Code doesn't sync, why most DIY recipes half-work, and why "just copy the folder" is the most common way people lose access to months of context. This post maps where your sessions actually live, reviews every sync tool people reach for, and shows the one-command way to move everything to a machine that never sleeps.

Where does Claude Code store session history?

Everything Claude Code knows about you is plain files in your home directory (or under CLAUDE_CONFIG_DIR, if you've set it). No database service, no cloud copy. That's excellent for privacy and terrible for portability:

PathWhat it holdsMoves cleanly?
~/.claude/projects/Session transcripts, one folder per project — the list claude --resume showsNo — folder names and contents are keyed to absolute paths
~/.claude/history.jsonlPrompt history across projectsYes
~/.claude/todos/ and shell-snapshots/Task state and shell context per sessionYes
~/.claude.jsonAccount state and user-scope MCP serversCareful — carries OAuth identity and key-bearing fields
~/.claude/settings.jsonSettings; its env block can hold API keysCareful
CLAUDE.md, ~/.mcp.json, ~/.agents/Your instructions, MCP config, installed skillsYes, once MCP secrets are stripped
~/.claude/.credentials.jsonYour OAuth login tokenShould never move at all

Two of those rows are why naive sync fails, and they fail differently: one breaks your history, the other leaks your login.

Why doesn't copying ~/.claude just work?

Because the session store is path-keyed twice over.

Each folder under ~/.claude/projects/ is named after the absolute path of the project it belongs to, with every non-alphanumeric character flattened to a dash: /home/alice/code/app becomes -home-alice-code-app. And inside each transcript, every JSONL line carries a literal cwd field holding that same absolute path.

Now move that folder to a Mac, where the project lives at /Users/alice/code/app. Claude Code looks for sessions under -Users-alice-code-app, finds nothing, and shows you an empty resume list — while your entire history sits right there in a folder it will never open. Same trap between two Linux boxes with different usernames, and same trap moving to any server or VM.

The /move/claude-code page walks the failure in more detail; the short version is that a faithful move must rename every project folder and rewrite every embedded cwd to the destination's paths. Copying files was never the hard part.

What about claude-sync, claude-mv, and Syncthing?

Enough people hit this wall that a small ecosystem exists. Reviewed honestly:

  • Manual copy + CLAUDE_CONFIG_DIR. Copy the tree, point the env var at it. Works when both machines have identical paths — and silently carries your credentials file along for the ride.
  • claude-mv. Re-keys a project's session folder when you move or rename the project directory. Genuinely useful — on one machine. It's a local-rename fixer, not a sync.
  • claude-sync. Syncs ~/.claude between machines with encryption. The transport is solved; the path-keying isn't — synced sessions resume only where paths match, and you own the exclusion list that keeps credentials out.
  • claude-context-sync. The closest to the right idea: it rewrites paths on import. You run it by hand per machine, and you're trusting a third-party script with your entire history.
  • Syncthing / Dropbox on ~/.claude. Continuous sync sounds right until a transcript syncs mid-write and forks into conflict copies — and until you notice your OAuth token has replicated to every device in the mesh.

None of this is a knock on the authors. The demand is real enough that it's in Anthropic's own issue tracker: #45358 (cross-machine sync) and #73639 (transfer a session to another instance) are open feature requests. The gap is structural: sync tools move bytes, and this problem needs the bytes rewritten.

Is Anthropic Remote Control the answer?

For some of the pain, honestly, yes. Remote Control lets you continue a session from another device, with the transcript held on Anthropic's servers. If what you want is "pick up this conversation from my phone," it's built for that.

What it doesn't do is move your state. The session still lives where it lives; your CLAUDE.md, skills, MCP servers, and months of project history stay on the laptop. You're choosing between transcripts on Anthropic's infrastructure and everything on hardware you control — a real trade-off, argued properly in the Remote Control section of the Claude Code move page, so it won't be re-argued here.

What does a lossless move actually look like?

Verifiable, before anything uploads. jurniti transfer detects your local Claude Code state and prints a manifest of exactly what would travel, what gets redacted, and what never leaves. The dry run needs no account:

$ jurniti transfer --harness claudecode --dry-run
Found local Claude Code state (2826 files, 412.0 MiB).

Transfer manifest — Claude Code
  keep  .agents/                            24 file(s)  812.4 KiB
  keep  .claude.json                         1 file(s)  148.9 KiB
  keep  .claude/                          2798 file(s)  410.9 MiB
  keep  .mcp.json                            1 file(s)  1.8 KiB
  keep  CLAUDE.md                            1 file(s)  4.2 KiB
  total 2825 file(s), 411.8 MiB
  never uploaded (credentials — you'll re-enter keys in the VM):
    .claude/.credentials.json
  redacted 3 secret-bearing field(s) in: .claude.json, .claude/settings.json
  sessions: 312 session file(s) travel with you
  path rewrites planned: session folders + embedded paths re-point at the VM home

Dry run — nothing was uploaded. Re-run without --dry-run to transfer.

Three lines in that output are the whole product. never uploaded: your OAuth token stays on your laptop, full stop — you sign in fresh inside the VM. redacted: key-bearing config fields are stripped from the copy that travels. path rewrites planned: every project folder is renamed and every embedded cwd rewritten to the VM's home directory — on your machine, before upload — so claude --resume on the VM lists exactly the sessions you left on your laptop.

How do you sync Claude Code across devices, then?

By retiring the idea that N laptops should each hold a copy. Give the sessions one durable home — an always-on VM — and let every device be a screen attached to it. There's nothing to reconcile, no conflict copies, no machine whose sleep schedule your agent inherits.

Run the dry run above, then drop --dry-run:

jurniti transfer --harness claudecode

The CLI confirms the manifest, uploads (streamed into your VM, never stored on our servers), applies, and walks you through signing back in. No VM yet? The same command takes you through checkout first — plans and what they buy — and picks up where it left off. Your laptop's copy is never modified, so nothing about your local setup changes until you're ready to let the VM be the canonical one.

If what you're actually after is the always-on hosting story — bypass permissions safely, overnight runs, isolation — that's the Claude Code hosting guide. This page's job ends where your sessions arrive intact: Claude Code in the cloud, history included.

Frequently asked questions

Does Claude Code sync sessions between computers?
No. Every session is a local JSONL file under ~/.claude/projects/, and there is no built-in cross-machine sync. Open feature requests (anthropics/claude-code #45358 and #73639) ask for exactly this. Until then, syncing means moving the files yourself — and dealing with the fact that they're keyed to one machine's paths.
How do I see my Claude Code session history on a second machine?
You have to bring the files with you, correctly. A raw copy of ~/.claude isn't enough: session folders are named after the first machine's absolute paths, so `claude --resume` on the second machine finds nothing. The folder names and the cwd field inside each transcript both need rewriting to the new machine's paths.
Can I just copy ~/.claude to another machine?
You can, and the files will arrive — but resume will look empty unless the new machine has identical usernames and directory layout. You'd also be copying ~/.claude/.credentials.json, your OAuth login token, which shouldn't leave the machine it was minted on.
What does CLAUDE_CONFIG_DIR do?
It relocates the whole ~/.claude tree to a directory you choose — useful for putting state on a specific disk, and part of most DIY sync recipes. It does not fix path-keying: sessions inside the relocated tree are still named after the absolute project paths of the machine that wrote them.
Is claude-sync or a dotfiles repo a safe way to sync Claude Code?
They're real tools solving a real pain, but two things need care: any repo or sync folder that includes ~/.claude can quietly carry your credentials file, and synced sessions still only resume on machines with matching paths. Review what's excluded before you push anything.
How do I migrate Claude Code sessions to a new computer losslessly?
Either do the full manual job — copy the state, exclude credentials, rename every folder under projects/ to the new path encoding, rewrite every embedded cwd — or run `jurniti transfer`, which does all of that client-side and lands the sessions in an always-on VM where `claude --resume` lists them intact.
Does Anthropic Remote Control sync my Claude Code sessions?
Not in the move-your-files sense. Remote Control lets another device continue a session, with transcripts held server-side by Anthropic. It's continuity for a session, not portability for your state — your local history, CLAUDE.md, skills, and MCP setup stay wherever they are.