How to Move Claude Code Between Your Laptop and the Cloud

Published August 28, 2026 · by the AQ team

Moving a Claude Code workflow from your laptop to a cloud VM (or back) is mostly a git operation plus one fresh sign-in. Everything checked into the repository travels: your code, branches, the project CLAUDE.md, and settings in .claude/. Everything else stays on the machine it was created on: login credentials, session transcripts, personal settings, and auto memory. Claude Code offers exactly one sanctioned migration verb, claude --teleport, and it only pulls an Anthropic-hosted cloud session down into a local terminal; every other move is git plus a plan file. This guide inventories what moves and what does not, then walks both directions, with every Claude Code detail verified against Anthropic's documentation as of August 2026.

What travels with the repo, and what stays on the machine

The single most useful mental model: Claude Code splits your workflow into repository state and machine state. Repository state moves with a push; machine state has to be recreated (or deliberately synced) on every box.

Three of those rows surprise people. Sessions: Claude Code stores each conversation as a JSONL transcript under ~/.claude/projects/, in a directory derived from the absolute path of your working directory, and claude --resume and claude --continue search this machine's history only. Credentials: macOS keeps them in the encrypted Keychain and Linux in an owner-only file, the formats differ, and signing in fresh takes a minute anyway. Auto memory, the notes Claude writes for itself about your preferences: Anthropic's documentation is explicit that these files are not shared across machines or cloud environments, so a VM starts with a blank memory of you.

Laptop to cloud VM: the migration in order

Assume you have a persistent Linux VM ready. (If not, running Claude Code on a cloud VM covers provisioning, hardening, and sizing; this guide picks up where that one ends.) The move is five steps:

# 1. On the laptop: get everything into git and push
git add -A && git commit -m "wip: moving to the VM"
git push -u origin my-branch

# 2. On the VM: install Claude Code and sign in once
curl -fsSL https://claude.ai/install.sh | bash
claude   # copy the login URL to your laptop browser, paste the code back

# 3. Clone and check out the same branch
git clone [email protected]:you/repo.git && cd repo
git checkout my-branch

# 4. Recreate personal config you care about
# (~/.claude/CLAUDE.md, ~/.claude/settings.json)

# 5. Run the session inside tmux so it outlives your SSH connection
tmux new -s my-task
claude

The sign-in in step 2 works fine on a headless server: the browser on your laptop cannot reach the callback on the VM, so it shows a login code you paste into the terminal instead. Your subscription does not change; the same Claude account signs in on both machines and usage is billed exactly as before.

What does not come with you is the conversation: a half-finished session stays in the laptop's transcript files. Two honest options. Lightweight: run /export in the laptop session and paste the relevant parts into the new session as background. Robust, and better in practice: before leaving the laptop, ask Claude to write the current plan and remaining steps into a markdown file, commit it, and push, then start a fresh session on the VM against that file. A plan in the repo survives any number of machine moves; a transcript survives none of them.

Cloud back to laptop

The return trip depends on what kind of cloud you were in.

From your own VM, it is git again: commit and push on the VM, pull on the laptop. The VM's session history stays on the VM, which is usually fine, because the durable outputs (commits, the plan file, the PR) already moved. A still-running session does not need migrating at all; reattach to it later (more below).

From Claude Code on the web, Anthropic's hosted product (in research preview for Pro, Max, and Team plans as of August 2026), there is a real migration command. claude --teleport opens a picker of your cloud sessions; claude --teleport <session-id> pulls a specific one. Teleport fetches and checks out the session's branch and loads the full conversation history into your terminal, which makes it the one case where a Claude Code conversation genuinely moves between machines. It has four requirements: a clean working tree (it prompts you to stash), a checkout of the same repository, the session's branch pushed to the remote, and the same claude.ai account on both ends. Note the direction: as of August 2026 the CLI hand-off is one-way. You can pull a cloud session down, but you cannot push an existing terminal session up to the web; claude --cloud starts a new cloud session from your current repo's pushed branch rather than transplanting the one you are in. The teleported copy also forks: new work in the terminal stays local and no longer appears in the web session.

Often you should move your access, not your workflow

If you find yourself migrating every few days, the workflow is living on the wrong machine. The alternatives to moving state are moving your point of view:

• tmux reattach. A session inside tmux on a VM does not care which device connects next: SSH in from anywhere, run tmux attach, and you are back in the live session. Keeping Claude Code running after closing your laptop covers the persistence patterns in depth.
• Remote Control. Running /remote-control in a local or VM session connects it to claude.ai and the Claude mobile app, so you can steer the same session from a browser or phone while execution stays on the original machine. Running Claude Code from your phone compares the mobile options.
• Make the VM home. Do the laptop-to-cloud migration once, permanently: the repo lives on the VM, sessions run there in tmux, and every device becomes a thin client. That is the always-on agent setup, and it dissolves the migration problem instead of solving it repeatedly.

Keeping two machines from drifting

If you keep both machines active, drift shows up in the machine-state column of the table above. The community pattern that works is a dotfiles repo with a strict allowlist: sync ~/.claude/CLAUDE.md, settings.json, and your commands, skills, and agents directories; never sync credentials, the projects/ directory (transcripts are keyed to absolute paths and break elsewhere), caches, or history. The better long-term fix is shrinking the personal layer: anything that matters to the project belongs in the checked-in CLAUDE.md and .claude/settings.json, where git does the syncing and teammates benefit too.

Where AQ fits

AQ is the multiplayer coding harness where engineering teams run AI coding agents like Claude Code and Codex together: shared live terminals, a code editor, and app previews, in your own cloud. In this guide's terms, AQ is the "make the VM home" option operated as a product. Agents run as real CLIs (Claude Code, Codex, Cursor Agent, Kimi, Grok, or plain shells) in persistent tmux sessions on your team's VM, streamed live to the browser: the session never lives on your laptop in the first place, so there is nothing to migrate when you switch devices. Close the lid, open the same workspace from another machine or your phone's browser, and the session is exactly where you left it.

The machine-state problem gets smaller too. Each engineer signs into the CLIs once on the team VM with their own Claude or OpenAI account (AQ never marks up model usage), commits and PRs use per-user GitHub auth, and every workspace gets its own isolated git worktree on a branch named ai/{id}-{slug}, with dependencies installed automatically and a one-click rebase onto main. Teammates open the same workspace and watch the same live session, and a live dev-server preview per workspace gives shareable links that work without an account for viewing.

Pricing is two plans. The Free plan is a personal sandbox for one person: AQ creates a private machine in an isolated network, nothing to install, no time limit, which makes it a zero-setup way to try the VM-as-home pattern. The Team plan is $50 per user per month in early access (standard $200, billed monthly), covering VMs you connect from your own cloud or a dedicated always-on AQ-managed VM in its own isolated network, with the rate locked for your first 12 months. If you are one engineer with one VM, the git-plus-tmux workflow in this guide is enough. AQ earns its place when the migrations stop being yours alone: when a teammate needs to see the session you would otherwise be moving.