Your Claude Code sessions live and die on one laptop.°
Every transcript, todo list, and memory file sits under ~/.claude, keyed to that machine's file paths. jurniti moves all of it into your own always-on VM — sessions resume where they left off, and your keys never leave your machine.
See exactly what would move — free, nothing uploads
$ curl -fsSL https://jurniti.com/install.sh | sh$ jurniti transfer --harness claudecode --dry-runThe dry run prints the full manifest — what travels, what gets redacted, and what never leaves your machine — then exits. Prefer to start with the VM? Get your VM first.
Where Claude Code keeps your session history
Claude Code is local-first: your entire history is plain files in your home directory (or under CLAUDE_CONFIG_DIR if you've relocated it). That's great for privacy — and it's exactly why your sessions are stuck on one computer. Here's what actually lives there:
| Path | What it holds | In the transfer |
|---|---|---|
~/.claude/projects/ | Per-project session transcripts (JSONL) — the history `claude --resume` lists | Travels, with paths rewritten |
~/.claude/history.jsonl | Prompt history across projects | Travels |
~/.claude/todos/ · shell-snapshots/ | Task state + shell context per session | Travels |
~/.claude.json | Account state + user-scope MCP servers | Travels — OAuth identity and key fields stripped first |
~/.mcp.json · CLAUDE.md · ~/.agents | MCP config, your instructions file, installed skills | Travels — MCP secrets stripped |
~/.claude/.credentials.json | Your OAuth login token | Never uploaded — you sign in again inside the VM |
Relocated your state dir? The transfer honours CLAUDE_CONFIG_DIR the same way the agent does.
Why syncing Claude Code across devices breaks your sessions
The trap is that Claude Code's session store is path-keyed. Each folder under ~/.claude/projects/ is named after the absolute path of the project it belongs to — /home/you/dev/api becomes -home-you-dev-api — and every line inside the transcript carries a literal cwd field pointing at that same absolute path.
Copy ~/.claude to a new computer where your home directory is /Users/you instead of /home/you, and nothing lines up: `claude --resume` looks for sessions keyed to the new machine's paths, finds none, and your history is effectively gone — even though the files are right there. This is the wall every naive rsync, Dropbox folder, and dotfiles repo hits.
Moving to a cloud VM has the same problem, plus two more: the copy carries ~/.claude/.credentials.json (your login token, now on a second machine), and a live-syncing folder can clone a transcript mid-write.
claude-mv, claude-sync, Syncthing, scp — what each actually solves
The community has built real tools around this pain. They're worth knowing — and worth being honest about:
Re-keys a project's session folder when you move or rename the project directory on the same machine.
One machine only. It doesn't move your account state, skills, or history to a second computer — it fixes local renames.
Version-controls ~/.claude and pulls it onto other machines.
Sessions stay path-keyed, so history only resumes if every machine shares identical usernames and paths. And a repo that includes ~/.claude can quietly commit your credentials file.
Continuous two-way sync of the directory.
Same path-keying wall, plus live JSONL files syncing mid-write produce conflict copies — and your login token replicates to every device in the mesh.
A one-shot copy you fully control.
You inherit the whole checklist by hand: exclude credentials, re-key every project folder, rewrite every embedded cwd, and re-do it each time. Doable — it's exactly the work the one command below automates.
Run Claude Code remotely — with your sessions intact
`jurniti transfer` detects your local Claude Code state, shows you a manifest of exactly what would move (and what never leaves), then streams it into your own dedicated VM — a real Firecracker microVM, not a shared container. Path rewrites happen on your machine before upload, so on the VM `claude --resume` lists the same sessions you left on your laptop. The dry run is free and prints this:
$ jurniti transfer --harness claudecode --dry-run
Found local Claude Code state (1414 files, 273.9 MiB).
Transfer manifest — Claude Code
keep .agents/ 38 file(s) 1.1 MiB
keep .claude.json 1 file(s) 182.4 KiB
keep .claude/ 1372 file(s) 272.5 MiB
keep .mcp.json 1 file(s) 2.1 KiB
keep CLAUDE.md 1 file(s) 6.3 KiB
total 1413 file(s), 273.7 MiB
never uploaded (credentials — you'll re-enter keys in the VM):
.claude/.credentials.json
redacted 4 secret-bearing field(s) in: .claude.json, .claude/settings.json
sessions: 217 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.Re-run without --dry-run and the CLI confirms, uploads (streamed straight into your VM — never stored on our servers), applies inside the VM, and walks you through signing back in. No VM yet? The same command walks you through checkout first and picks up where it left off.
$ jurniti transfer --harness claudecodeA Remote Control alternative that lives on your own VM
Anthropic's Remote Control feature attacks the same pain from the other end: it lets another device drive a session that still runs on your laptop. That's genuinely useful — until the laptop sleeps, updates, or stays in the office. The session's home never changes; only the screen does.
Moving the sessions themselves to an always-on VM inverts that: the VM is the durable home, and every device — laptop, desktop, phone over SSH — is just a screen. No feature-availability gates, no keeping a machine awake, and the history is on hardware you rent alone. If Remote Control's "not available" message brought you here, this is the version you can run today.
Your keys never leave your machine
Before anything is packed, the CLI copies your state into a private temp directory and scrubs it there — your real ~/.claude is never touched. Your OAuth credentials file is dropped outright, and secret-bearing fields in .claude.json, settings and MCP configs are redacted. The manifest prints every drop and redaction before you confirm; an advisory scan flags anything that still looks like a secret.
The archive streams straight into your VM and is never stored on our servers. On the VM you re-authenticate fresh — sign in with your Claude subscription inside the VM, or set your API key there (BYOK: model traffic goes from your VM to Anthropic, never through us).
What $25/mo buys that a $10 VPS doesn't
You can absolutely rent a $10 VPS, install Claude Code, and carry your state over by hand — the DIY section above is the honest map. What the Starter plan buys over that: a dedicated Firecracker microVM with hardware isolation (not a container beside strangers), the agent pre-installed and kept healthy, and the transfer itself — detection, credential scrub, path rewrites, verified apply — as one command instead of an afternoon of rsync forensics.
Plans are flat monthly — no metered surprises — and every plan carries a 30-day money-back guarantee on your first purchase: if it isn't worth it, email us and we refund you.
Your own Firecracker microVM with Claude Code installed, provisioned ~3 minutes after payment — then one command moves your state in. Not worth it within 30 days? Email us and we refund you.
Claude Code sessions, synced — questions
Will Claude Code sync across devices by itself?
No. Sessions are local files under ~/.claude, keyed to one machine's absolute paths — there's no built-in multi-device sync. The practical fix is giving the sessions one durable home (an always-on VM) and reaching it from every device.
How do I move Claude Code to a new computer?
Copying ~/.claude alone breaks `claude --resume`, because project folders and transcripts embed the old machine's paths. You'd need to re-key the folder names and rewrite every embedded cwd — or run `jurniti transfer`, which does the rewrites client-side and moves everything to a VM in one step.
Where does Claude Code store session history?
Per-project transcripts live under ~/.claude/projects/ (one folder per project, named after its encoded path), with prompt history in ~/.claude/history.jsonl and task state in ~/.claude/todos/. If CLAUDE_CONFIG_DIR is set, the whole tree lives there instead.
Is this a claude-sync alternative?
It solves the same problem with the opposite shape: instead of syncing state between laptops (and fighting path-keying on each), it moves the state once to a VM that's always on. Your laptops become thin clients to one canonical history.
Do my API keys or my Claude login transfer?
Never. The credentials file is excluded before packing, key-bearing config fields are redacted, and the manifest shows you both lists before anything uploads. Inside the VM you sign in fresh — subscription login or your own API key.
What happens to the copy on my laptop?
Nothing. The transfer reads your state into a temp copy and uploads from there — your local ~/.claude is untouched, so the laptop keeps working exactly as before.
Can I use my existing Claude subscription on the VM?
Yes — Claude Code on the VM signs in with your Anthropic account the normal way (the CLI walks you through it after the transfer). jurniti never sees or proxies that login.