Claude Code Remote Control and Claude Code on the web open in the same place, look nearly the same, and do opposite things. One keeps every file operation on your laptop and puts a window on your phone. The other ships the job to a virtual machine that has never seen your laptop.
The documentation flags the confusion directly, which is a good sign that people keep hitting it. In the page on cloud sessions, Anthropic notes that "--cloud creates cloud sessions. --remote-control is unrelated: it exposes a local CLI session for monitoring from the web."
One question that is actually three
"Where am I working" sounds like one question. It is three, and they move independently.
Where does the process run. Which CPU executes the tool calls, runs the tests, and burns the wall clock.
Where does the filesystem live. Which disk holds the files being edited, along with your MCP servers, your credentials and the twelve things you never committed.
Where are you. Which screen you are looking at while it happens.
Local answers all three with "your machine." A cloud session moves the first two and leaves the third alone. Claude Code Remote Control moves only the third. Once you separate them, the flags stop being confusable, because each one is answering a different question.
Local is the only mode with your whole machine
The terminal session is the baseline, and it is worth stating plainly what it has that nothing else does: everything.
Your uncommitted changes. Your .env file. Your local database, your SSH agent, the build cache that took nine minutes to warm. None of that is portable, which is the reason the other two modes exist and also the reason they have limits.
Anthropic’s Claude Code overview describes the surfaces as sharing one engine, so "your CLAUDE.md files, settings, and MCP servers work across all of them." That is true of configuration and not of state. Configuration is a file you can carry. State is the mess on your disk right now, and only the local session has it. Our explainer on what Claude Code is covers the permission model governing all of it.
Claude Code Remote Control moves you, not the work
Remote Control is the mode people misread, because the interface it gives you is a browser and browsers imply servers.
The Remote Control documentation is unambiguous: "Claude keeps running locally the entire time, so your code execution and filesystem access stay on your machine." The web and mobile interfaces are described as "a window into that local session." Nothing is uploaded except the conversation.
You start it three ways. claude remote-control runs a server that waits for connections. claude --remote-control gives you a normal interactive terminal session that is also reachable remotely. /remote-control inside a running session hands the conversation you already have to your phone.
What you keep is the part that matters: your filesystem, your MCP servers, your project configuration, and @ autocomplete against your actual local paths. What you gain is the ability to answer a permission prompt from a coffee shop.
One thing to price in: while Remote Control is connected, the session transcript, meaning your messages, Claude’s responses and tool activity, is stored on Anthropic servers so the conversation stays in sync across devices. Execution stays local. The record of it does not.
Cloud sessions move the work, not you
Claude Code on the web is the inverse trade. Anthropic describes it as running "tasks on Anthropic-managed cloud infrastructure at claude.ai/code, or on your organization’s self-hosted environment when routed there."
The detail that catches people is what the virtual machine actually receives. From the web sessions documentation: "The cloud VM clones your current directory’s GitHub remote at your current branch, not your local checkout, so push first if you have local commits."
Read that twice if you have ever fired off a cloud task and wondered why Claude could not see the function you just wrote. It cloned what GitHub has.
There is a fallback for repositories with no GitHub remote, and it has sharp edges. Claude Code bundles the local repository and uploads it, but the bundle must stay under 100 MB, "untracked files are not included," and sessions created from a bundle "can’t push back to a remote unless you also have GitHub authentication configured."
In exchange you get isolation and parallelism. Each session runs in its own Anthropic-managed virtual machine, network access is limited by default, and credentials such as git keys are "never inside the sandbox with Claude Code," with authentication handled through a proxy using scoped credentials. Three --cloud commands start three independent sessions. That is the real argument for the cloud, and it is the same argument that makes Claude Cowork’s cloud sessions useful for work you want to walk away from.
Teleport is a one way door
The handoff between the two is asymmetric, and the asymmetry is documented rather than accidental.
"From the CLI, session handoff is one-way: you can pull cloud sessions into your terminal with --teleport, but you can’t push an existing terminal session to the web." Teleport checks that you are in the right repository, fetches the branch, and loads the conversation history into your terminal.
Then it stops syncing. "The terminal gets its own copy of the session: new work there stays local and doesn’t appear in the cloud session." To keep steering from your phone after teleporting, the documented answer is to start Remote Control in the local session, which is the cleanest illustration of the distinction. Teleport changed where the work runs. Remote Control changed where you can watch it.
What stops each one from working
Every mode has a failure condition, and they are unrelated to each other. This is the list to check before you build a habit on any of them.
Local needs nothing and breaks on nothing. It is the fallback for every other row here.
Remote Control needs the local process alive. The documentation is blunt: "If you close the terminal, quit VS Code, or otherwise stop the claude process, the session goes offline." On a remote box, the suggested fix is tmux or screen. It also requires a claude.ai subscription login rather than an API key, and is unavailable on Amazon Bedrock, Google Cloud’s Agent Platform and Microsoft Foundry, or when ANTHROPIC_BASE_URL points somewhere other than the Anthropic API.
Cloud needs GitHub and an unrestricted network path. Repository cloning and pull request creation require GitHub. And the constraint most likely to ambush an enterprise team: "If your organization has IP allowlisting enabled, every Anthropic-hosted cloud session fails with an authentication error," because the calls come from Anthropic infrastructure rather than your network.
Both remote modes are gated at the organization level. Cloud sessions depend on the allow_remote_sessions policy, Remote Control is off by default on Team and Enterprise until an Owner enables it, and organizations with Zero Data Retention cannot use either. Same governance surface we mapped for CMS agent permissions: the toggle exists, someone owns it, and most teams learn which way it is set at the worst moment.
Which mode fits which job
Five positions, in the order I would apply them.
Default to local. It has your state, no preconditions and no policy gates. Reach for something else when you have a reason, not by habit.
Use Remote Control when the work is already local and you are not. A long test run, a migration you want to approve step by step, an agent that will hit a permission prompt in forty minutes. Nothing moves except your attention.
Use the cloud when there is nothing local to preserve. A repository you have not cloned, three refactors you want running at once. Configure the cloud environment before you rely on it.
Push before you type --cloud. The virtual machine clones your remote, not your desk. This single habit prevents most of the confusion people report about cloud sessions ignoring their code.
Decide where transcripts may live before you enable anything. Both remote modes store conversation on Anthropic servers by design. That is a fine trade for most teams and a hard stop for a few, and it is better settled by policy than discovered in an audit.
The pattern underneath all of this is the same one that made Codex’s three separate meanings hard to write about. Vendors ship surfaces faster than they ship vocabulary, and two features that share an interface get treated as variants of one thing. Claude Code Remote Control and cloud sessions share a URL and almost nothing else.
Frequently Asked Questions
What is Claude Code Remote Control?
It connects claude.ai/code or the Claude mobile app to a Claude Code session running on your own machine. Claude keeps executing locally the whole time, so your filesystem, MCP servers and project configuration stay available, and the browser or phone acts as a window into that local session. Start it with `claude remote-control`, `claude –remote-control`, or `/remote-control` inside a session already running.
How is it different from Claude Code on the web?
They differ in where the session executes. Remote Control runs on your machine and uses your local files. Claude Code on the web runs in an Anthropic-managed virtual machine that clones your repository from GitHub. Both are reached through the same claude.ai/code interface, which is why they get confused, but only one of them can see the changes you have not pushed yet.
Can I push a local session to the cloud?
Not from the CLI. Handoff is documented as one way: `–teleport` pulls a cloud session into your terminal, and no CLI flag sends an existing terminal session the other direction. The Desktop app offers a Continue in menu that can send a local session to the web. Starting a fresh session with `claude –cloud “task”` is a different operation, since it creates a new session rather than moving yours.
Why can’t my cloud session see my latest code?
Because it cloned your GitHub remote at your current branch, not your local checkout. Anything you have not pushed is invisible to it. Push first, then start the session. If the repository has no GitHub remote at all, Claude Code falls back to bundling and uploading the repository, but untracked files are excluded and the bundle has to stay under 100 MB.
What happens if my laptop sleeps during a Remote Control session?
Claude Code reconnects automatically when the machine comes back online, and queues status updates from subagents and workflows while the connection rebuilds. The harder failure is the process ending rather than the network dropping. If you close the terminal or quit the editor, the session goes offline until you bring it back, which is why long-running sessions on a remote box are best started inside `tmux` or `screen`.
Does either mode cost extra?
Not as separate compute. Anthropic states there is no separate compute charge for the cloud virtual machine, and that Claude Code on the web shares rate limits with all other Claude and Claude Code usage on your account. Running several cloud tasks in parallel consumes those limits proportionately, so the cost shows up as capacity rather than as a line item.
Is anything stored on Anthropic servers?
Yes, in both remote modes. While Remote Control is connected, the session transcript including your messages, Claude’s responses and tool activity is stored on Anthropic servers to keep devices in sync and allow reconnection after a network drop. Execution and filesystem access stay on your machine. Cloud sessions run on Anthropic infrastructure by definition. Organizations with Zero Data Retention cannot use either.
Which one should a small team standardize on?
Neither, exclusively. Local remains the default because it has your state and no preconditions. Add Remote Control when people want to approve steps away from their desk, since it changes nothing about where work happens. Add cloud sessions when the value is parallelism or a repository nobody has cloned. What does need standardizing is the policy decision, because both remote modes are organization-level toggles and both put transcripts on vendor infrastructure.
