Teleport a Claude Code session between any two of your computers, in either direction

Teleport moves a running Claude Code session's work between any two computers you have in Melta, in either direction, with one tap. That covers laptop to server, server to laptop and server to server: the session pauses at a clean point, its work goes up on a branch, and a session on the other computer picks it up from there.

Direction is not a thing in the mechanics. The phone talks to both computers, so it runs the same steps on whichever one holds the session and whichever one you pick as the target. Moving work back is just another teleport.

What is a teleport?

A Claude Code session is three things: the files it has changed, the conversation that explains why, and the folder it runs in. None of them can be carried across while the session is running. A teleport pauses at a clean point, puts the code where both computers can reach it, and gives the new session enough of the story to carry on. Melta's Chief does the work on each computer; the phone drives it. It works for Claude Code sessions.

What moves?

• The work, on a branch. Everything the session changed is committed as wip: teleport <date> and pushed with git push -u to your git remote. If the session is on main, master or a detached HEAD, a new branch named teleport/<title>-MMDD-HHMM is made first.
• The handoff. The session writes its own handoff file while its prompt cache is still warm, so this is cheap. It covers the goal and where it stands, what is done with commits, what is in progress and the exact next steps, files that matter, decisions and why, gotchas, and the commands to run.
• The transcript, when it is small. The session's conversation file travels through the phone only when it is under 5 MB. Over that, the app says so and the new session starts from the handoff alone.

What never moves?

Secrets. Everything is staged, untracked files included, then anything that looks like a secret is taken back out: .env and .env.*, *.pem, *.key, *.p12, id_rsa*, id_ed25519*, credentials*, secrets* and serviceAccountKey*.json. When a .env was there, the handoff on the target starts with "Secrets (.env) did not travel: set them up on this computer," and the app shows a note telling you to set them up on the target once.

Nothing on the source is closed or deleted either. Its work is committed and pushed, and that is all.

What is the one tap on the phone?

In the Melta app, long-press a Claude Code session on the host screen and choose Teleport…, or open the session and pick it from its menu. You pick the target computer, which can be any other computer you have in the app, confirm, and the sheet shows four steps as they happen:

1. Handoff written. The session writes its handoff on the computer it is on.
2. Work pushed. The work is committed and pushed on its branch. Teleport never pushes main and never force-pushes.
3. Worktree opened. The target clones or fetches the repo and opens a worktree on the branch.
4. Session started. Claude Code starts in that worktree.

[Screenshot: the Teleport sheet with its four steps ticked]

What happens on the other computer?

If the repo is missing, it is cloned (by default into ~/projects/<repo>), then fetched, and Herdr opens a worktree on the pushed branch. The handoff is saved in Chief's handoffs folder, with a first line saying which branch the work came on.

If the transcript came across and Claude Code accepts it, the session resumes with --resume and is told it continued on another computer. Otherwise a new session starts and its first prompt is "Read <handoff> and continue."

When the target already has a worktree on that branch, teleport uses it and fast-forwards it to what was pushed. If that worktree has changes that aren't on the remote, it stops and asks you to commit or move them first, rather than overwrite anything. On the source, the session's row shows Teleported to the other computer.

When does a teleport refuse?

The app names the failed step in plain words:

• The session is busy. A session that is working or waiting for permission can't write a clean handoff. Teleport it when it is idle.
• No shared git remote. The project needs a remote both computers can reach, such as a GitHub repo. Add one with git remote add origin <url>.
• Push rejected. Git refused the push, usually because the remote branch has commits yours doesn't. Bring the branch up to date on the source, then teleport again.
• Clone or fetch failed. The target needs its own access to the remote: its own SSH key or token for GitHub.
• Target without Chief. If Chief isn't set up on the target, or is older than 0.1.6, the app says so before anything moves. Set it up there first.

Three examples

Lid closing: laptop to server

A refactor is half done on your laptop and you need to leave. When the session finishes its turn, teleport it to your server. The branch goes up, the server opens a worktree on it, and the session carries on while the laptop sleeps.

Back home: server to laptop

The server finished most of the work overnight and you want to test it locally. Teleport the server's session to the laptop. The laptop still has the branch from before, so its worktree is fast-forwarded to what the server pushed and the session continues there.

Heavy build: small VM to big VM

A session on a small cloud VM reaches a build or test run that needs more memory. Teleport it to a bigger VM. Neither computer is a laptop, and it does not matter: the phone reaches both, so the steps are the same.

How do I do it by hand, without Melta?

Without Melta the same flow is a few commands. In the session, ask it to write a handoff file. Then on the source:

git switch -c teleport/my-task
git add -A
git status   # check no .env or key file is staged
git commit -m "wip: handoff"
git push -u origin teleport/my-task

On the target:

git fetch origin
git worktree add ../my-task teleport/my-task
cd ../my-task
claude "Read HANDOFF.md and continue."

The part that is easy to get wrong by hand is the secrets check. git add -A picks up an untracked .env unless your .gitignore covers it.

Common questions

Can I teleport server to server?

Yes. Any two computers you have in Melta work, in either direction. The phone connects to both and runs the same steps whichever one is the source.

Can I move it back later?

Yes. Teleport the session on the other computer back. If the first computer still has the branch, its worktree is fast-forwarded to the pushed work.

What if the conversation is very long?

The transcript is copied only when it is under 5 MB. Larger ones stay behind and the new session starts from the handoff, which is written to carry what matters.

Does the session on the first computer keep running?

Nothing on the source is closed or deleted. Its row shows Teleported to the other computer, with Close as its one action.

What do both computers need?

Herdr, Melta's Chief at version 0.1.6 or newer, and access to the same git remote. Teleport works for Claude Code sessions.

Melta does this for you: one Teleport button, either direction, four steps, secrets left behind. Melta is free; join the waitlist.

Sources

• Melta docs: Teleport
• Melta docs: Chief
• Claude Code docs: CLI reference (--resume)
• Git documentation: git-worktree