Claude Remote Control vs Claude Code on the Web: Which to Use and How They Differ

Open claude.ai/code and you can start a session two ways that look almost identical in the interface and are completely different underneath. One is a cloud session, often called Claude Code on the web: Claude runs on a virtual machine Anthropic manages, with your repository cloned into it. The other is Remote Control: Claude runs on your own computer, and the browser or phone is a window into that local process. The Remote Control documentation puts it in one sentence: “The key difference is where the session runs.” Everything else people ask about (why a session says it is connected to my computer, why another one kept going after the laptop was closed, why the cloud one could not reach localhost, which one burns usage) follows from that sentence. This post lays the two out side by side, from the official docs as of early November 2026.

What “connected to your computer” means

A Remote Control session is a claude process on your machine that has registered with the Anthropic API and is polling for work. In the session list at claude.ai/code and in the Claude mobile app, these sessions show a computer icon with a green status dot when online. When you type from the phone, the message travels to Anthropic and down to that process, which reads your files, runs your tools and MCP servers, and streams the result back. The docs are explicit about the consequence: “your computer has to stay on and the claude process has to keep running.”

The connection is outbound only. Your machine makes HTTPS requests to the Anthropic API and never opens an inbound port, which is why it works behind a home router or office NAT with no configuration. While connected, the transcript (your messages, Claude's replies and tool activity) is stored on Anthropic servers so that every device sees the same conversation and the session can reconnect after a network drop; execution and filesystem access stay on your machine. If you see Remote Control disconnected or Can't reach in the browser, that means the browser lost contact with Claude Code on your computer, and the docs note that neither message tells you whether Claude is still working there. You have to look at the machine.

What a cloud session is

A cloud session “runs on cloud infrastructure instead of on your machine.” In Anthropic-hosted environments each session gets a fresh VM running Ubuntu 24.04 on x86_64, whatever your own laptop runs, with the repository cloned and common toolchains pre-installed. It needs GitHub access to clone and push, granted either through the Claude GitHub App or by sending your local gh token with /web-setup; your GitHub credentials stay encrypted on Anthropic's servers and never enter the VM, because git operations go through a proxy that attaches them server-side. The session “keeps running after you close your laptop,” and you check on it from any device. When it is done you create a pull request from claude.ai/code, or pull the session and its branch into your terminal with claude --teleport <session-id>.

Every cloud session runs inside a cloud environment, a saved configuration with one of four network access levels: None, Trusted (allowlisted domains only: package registries, GitHub, cloud SDKs; this is the default), Full (any domain) and Custom (your own allowlist). Environment variables are set on the environment in .env format, and the docs warn that anyone who uses the environment can read them; an API key should be a network secret instead, which the agent proxy attaches to matching outbound requests so the key never appears inside the session. Resource ceilings are approximately 4 vCPUs, 16 GB of RAM and 30 GB of disk, and the docs say outright that for workloads beyond that you should use Remote Control to run on your own hardware.

Remote Control vs cloud sessions, side by side

The “laptop closed” row deserves the extra sentence. Remote Control is listed as surviving interruptions: if your laptop sleeps or the network drops, Claude Code reconnects automatically when the machine comes back online. That is reconnection, not continuation. A sleeping Mac is not running your test suite, and the phone will show the session as offline until it wakes. A cloud session is the thing that genuinely does not care whether your laptop exists.

Which one to use, in the docs' own words

The Remote Control page gives the rule directly: “Use Remote Control when you're in the middle of local work and want to keep going from another device. Use a cloud session when you want to start a task without any local setup, work on a repo you don't have cloned, or run multiple tasks in parallel.” A project combines the two: its threads run in the cloud, and it uses Remote Control to run a thread on your computer when you ask for one there. In practice the decision usually comes down to three questions.

• Does the task need something only your machine has? A local database, a service on localhost, a VPN-only host, a hardware device, an MCP server with local credentials, a build that needs more than 16 GB. Remote Control. Cloud sessions reach only their environment's allowed domains and run on a fixed VM.
• Do you need the work to continue when you are not there? Overnight, on a train, while the laptop is in a bag. Cloud session. Or keep the local machine awake and plugged in and accept that Remote Control depends on it; the server mode guide covers running claude remote-control under tmux on a box that stays up.
• Is the output a pull request? Cloud sessions are built around branch, push, PR, and can watch the PR for CI failures with auto-fix. Remote Control leaves changes in your working tree, where you commit them yourself, exactly as if you had typed at the terminal.

Moving between the two

Handoff from the CLI is one-way. claude --cloud "task" creates a new cloud session that clones your current directory's GitHub remote at your current branch, not your local checkout, so push first if you have local commits. If the repository has no remote, or the Claude GitHub App is not installed on it, Claude Code bundles the local repository and uploads it instead; on macOS, Linux and WSL it leaves uncommitted changes to files that look like credentials (.env, *.tfvars, id_rsa, *.pem) out of the upload and prints a Left on this machine: notice. Going the other way, claude --teleport pulls a cloud session into your terminal: it checks you are in a checkout of the same repository with a clean working tree, fetches the session's branch and loads the conversation. The terminal then has its own copy, and new work there does not appear in the cloud session; to keep steering from your phone after teleporting, start /remote-control in the local session.

# local work you want to keep steering from the phone
claude
/remote-control

# a task that should run without your laptop
git push
claude --cloud "Fix the flaky test in auth.spec.ts"

# bring a finished cloud session into the terminal
claude --teleport <session-id>

# queue a follow-up into a running cloud session, from any machine
claude -p "also update the changelog" --cloud <session-id>

One naming trap the docs call out themselves: --cloud creates cloud sessions, while --remote-control is unrelated and lets you steer a local session. The older --remote spelling is a deprecated alias for --cloud, which is presumably where some of the confusion between “remote” and “cloud” comes from.

Gotchas on each side

Remote Control. Closing the terminal, quitting the Desktop app or VS Code that hosts the session, or stopping the claude process takes the session offline until you bring it back. In server mode an extended network outage makes the process give up after roughly ten minutes and exit; an interactive session keeps retrying for as long as the outage lasts. Organisations with Zero Data Retention or the HIPAA configuration cannot enable it, and on Team and Enterprise an Owner has to switch it on in the admin settings first. Commands that only exist in the terminal interface, such as /plugin and /resume, do not work from the phone.

Cloud sessions. Idle sessions pause after a few minutes and a paused VM can be reclaimed; reopening restores the conversation but not background work that was still running, and Claude Code tells Claude which shell commands and subagents stopped so you can ask it to rerun them. Repository cloning and PR creation require GitHub (GitLab or Bitbucket repositories can be sent as a bundle with CCR_FORCE_BUNDLE=1 but the session cannot push back). If your organisation uses IP allowlisting, every Anthropic-hosted cloud session fails with an authentication error because it calls the API from Anthropic's network, not yours. And rate limits are shared with everything else on your account, so five parallel cloud sessions draw down the same pool five times faster.

The part both have in common

Whichever you choose, you are not watching the terminal, which is the whole point, and which is also the moment the session asks a question nobody answers. Remote Control forwards permission prompts to the connected device and keeps them open until you answer, and for push notifications on the phone it has the Push when Claude decides and Push when actions required options in /config. A cloud session that asks a question simply sits idle until you come back, up to environment expiry. On the machine that actually runs a Remote Control session, the terminal still shows the tool activity, and a desktop alert there is the thing that catches a stalled run before your phone does; our background session guide and the Remote Control guide cover the local-side setup.