[FEATURE] Add a CLI command to hand off a running local session to the cloud (local→web, the inverse of `--teleport`)
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
From the CLI, session handoff is one-way: --teleport pulls a cloud session down into the terminal, but there is no way to push an already-running local session up to the cloud. Today the only mechanism that lifts a live local session to the web is the Desktop app's "Continue in" menu.
That mechanism is unreachable for a large slice of developers:
- There is no Claude Desktop app for Linux (official guidance is "use the CLI").
- On Windows, the Desktop app's embedded shell runs commands in the Windows environment, not inside WSL2, so it can't see WSL-resident files (or can, as a network mount, but that's a setup that is useless for anything beyond silly demos -- aka, actual work), toolchains, or the running session (see #12506, #49933).
Net effect: developers whose primary environment is WSL2 or native Linux — i.e. a substantial share of the professional dev audience — have no supported path to move an in-progress session to the cloud before stepping away or going offline. --remote only starts a new cloud session; it does not carry over the current conversation/context.
Proposed Solution
A CLI-native command that pushes the current local session (conversation history + working branch) to a cloud session — effectively the inverse of --teleport. For example /teleport --to-cloud or claude --push-remote, reusing the git preconditions teleport already enforces (clean state / pushed branch).
This must not require a GUI. The capability is missing at the CLI layer; gating it behind a desktop surface is the actual defect. A headless / terminal-only path is the entire point of the request — I'm happy to do all the git hygiene the handoff needs, I just need the handoff to exist without a desktop app.
Alternative Solutions
- Desktop "Continue in" — nonexistent on Linux, non-functional for WSL2 on Windows.
--remote— starts a fresh session, discards current context.- Manual
git push+--remotewith a re-explained prompt — works, but loses conversation state and is fully manual.
Priority
Critical - Blocking my work
Feature Category
CLI commands and flags
Use Case Example
- Late enough that office AC turned off.
- Long prompt work ahead -- Ooh, I can move the session online so I can continue as soon as I get home.
/remote-control
(Yes, now I know it's bogus. But I don't know what to type as a "use case" for something that you clearly have as a feature, so, you know -- "the usual".)
Additional Context
- A few minutes late: WTF.
- Another N minutes later: claude.ai has a definitive answer -- "Anthropic doesn't care about you".
Showing cached comments. Read the full discussion on GitHub ↗
4 Comments
Found 2 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
This is essentially #56687, which was closed as a duplicate of #27028 → #27005. That chain is a misclassification, and I'd ask to keep this one open rather than fold it into the same collapse. Here's the distinction the dedupe missed.
#27005 / #27028 are about the
&shortcut — a different feature. The&prefix (like--remote) starts a new cloud session from a prompt. It doesn't carry over the current conversation, todos, or working state — the cloud VM clones fresh from GitHub. #27005 is specifically a regression report that the&shortcut stopped firing. That's "fix the start-a-new-session shortcut."This request — and #56687 before it — is the opposite: migrate an already-running local session, with its conversation context, up to the cloud. #56687 said this explicitly ("
--remotespins up a brand new cloud session… it doesn't migrate conversation history") and was still merged into the&bug. So a context-handoff request got deduped across the exact line it drew, into a new-session-shortcut regression — which then died of inactivity. The machinery already exists one direction:--teleportpulls a cloud session into the terminal, headlessly. This is just the inverse, and it has no CLI equivalent.Why this is a real gap, not a convenience-parity ask. The standard answer is "use the Desktop app's Continue in menu." That answer does not exist for a large part of the CLI userbase:
For both, there is no path — GUI or otherwise — to move a live session to the cloud. Not "less convenient." None.
To be precise about who this affects: if your session already runs on a remote/cloud VM, you don't need this — you shut the laptop, SSH back in from anywhere (the subway included), and the same session is still attached under tmux. Persistence is already solved for you, because the compute was never local. The people stranded are those running Claude Code on the local machine itself — bare-metal Linux laptops and WSL2 — where the session lives on the device that goes offline, and per the above there's no handoff path off it. "Just run it on a VM" isn't a fix; it's telling a local-development workflow to stop being local.
The root problem is that a capability is being modeled as a property of a GUI rather than a feature of the tool. Session handoff isn't inherently graphical;
--teleportalready proves it runs fine headless. The inverse is missing only because it was wired exclusively to a desktop menu. The earlier threads kept getting pulled into surface-specific specifics — what the Desktop/editor integration does — when the underlying capability is surface-agnostic. I don't need a GUI, a "Continue in" menu, or any particular client. I need a CLI verb —/teleport --to-cloud,claude --push-remote, whatever you call it — that does headlessly what the Desktop menu does, reusing the same git preconditions--teleportalready enforces.Requesting this stay open as the canonical issue for the CLI-native, headless inverse of
--teleport, distinct from the&-shortcut regression in #27005 / #27028.not stale
+1 — hitting this exact gap.
My scenario: I work in the CLI on my laptop and get a session to a good point — context built up, plan agreed. Then I want to type the next prompt as a continuation of that same conversation and have it execute as a cloud session (claude.ai/code), so the work keeps running after I close the laptop. Today the only options are
--remote(fresh session, all context lost) or manually re-explaining everything in a new web session.The ideal UX for me would be exactly what's proposed here: a session-level handoff (e.g.
/teleport --to-cloudor similar) that carries the conversation history up, so the next prompt I send lands on the cloud continuation. Since--teleportalready proves transcripts can move between surfaces in one direction, the inverse direction feels like the missing half of the feature.