Claude Code Remote Control: what it is, and what it doesn't do

You searched for "Claude Code remote control" and Google gave you a Reddit thread, three content farms, and a related-searches row that reads like a list of things nobody has answered: "not available", "vs Dispatch", "security", "Pro", "Windows", "app".

That's six different confusions under one term, and they all come from the same root: Anthropic shipped five different ways to work away from your terminal in six months, and the names don't tell you which is which.

This post is the map. What Remote Control actually is, how it differs from Channels and Dispatch, and the limits the docs state plainly but nobody quotes.

TL;DR

At a glance: Remote Control launched 2026-02-25 as a research preview, Max first. It runs claude remote-control (or claude --remote-control, or /remote-control inside a session) on your machine, registers with the Anthropic API, and polls for work. You then drive that same local session from claude.ai/code or the Claude mobile app. Execution and filesystem access never leave your machine. The session transcript does get stored on Anthropic servers while the connection is live, which is how it stays in sync and how it survives a network drop.

The three things people get wrong: it's available on Pro as well as Max (API keys are not supported at all), the local claude process closing kills the session outright, and sleep is supposed to be survivable — though on my own machine it isn't, which I get into below.

Read that table one column at a time and the naming stops being confusing. Remote Control is about steering work that's already running. Channels is about events arriving while you're away. Dispatch is about delegating a task you haven't started. Same underlying idea — your machine does the work — three different entry points.

What Remote Control actually is

It's a connection, not a product surface.

You start Claude Code on your machine with Remote Control enabled. It registers with the Anthropic API and polls for work. When you open the session from your phone or a browser, Anthropic's server routes messages between that client and your local process over a streaming connection.

Your filesystem, your MCP servers, your project configuration, your CLAUDE.md — all still local, all still available. Typing @ on your phone autocompletes file paths from the project on your laptop. That's the part that makes it different from every "AI coding on mobile" product: nothing was uploaded and nothing was cloned.

Anthropic's docs put it in one line: "the web and mobile interfaces are a window into that local session."

Three ways to start it

Server mode. Stays running in your terminal waiting for connections, shows a session URL, spacebar toggles a QR code:

claude remote-control

Interactive mode. A normal Claude Code session you can also type into locally, with Remote Control attached:

claude --remote-control "My Project"

From inside a session you're already in, carrying the conversation history over:

/remote-control

In the VS Code extension it's the same /remote-control command, minus the name argument and the QR code.

Server mode is the one worth knowing about, because it has flags the other two don't:

claude remote-control --spawn worktree --capacity 8 --name "site"

--spawn worktree gives every on-demand session its own git worktree instead of sharing one working directory. --capacity caps concurrent sessions (default 32). --spawn session locks it to exactly one and rejects everything else. Press w at runtime to flip between shared-directory and worktree modes.

If you're running several agents in parallel, --spawn worktree is the difference between isolated sessions and eight agents fighting over the same files. Same isolation argument I made in the best terminal for Claude Code, just enforced by the server instead of by you.

The limits nobody quotes

This is the section the content farms skip, and it's the only part that changes how you use the thing.

Sleep is meant to be survivable. Mine isn't.

The common claim — that your machine has to stay awake and anything sent while it's down is lost — isn't what the docs say about Remote Control. They're explicit:

"if your laptop sleeps or your network drops, the session reconnects automatically when your machine comes back online. Claude Code queues status updates from subagents and workflows while the connection is rebuilding and delivers them once it recovers."

That claim is true for Dispatch, which is probably where the confusion started. Dispatch's own help article says your computer must be awake and the Desktop app open, and that tasks cannot continue when your computer is offline. Two features, opposite behaviour, adjacent names.

Here's where my own experience parts company with the docs. I drive Remote Control from a Mac mini, and it sleeps early. When it does, everything closes. Not paused, not reconnecting: gone. I pick up my phone, the session isn't there, and there's nothing to come back to.

I haven't fixed it, which is the honest version of this. The fix is a power-settings change I keep not making.

So take the auto-reconnect as documented behaviour that assumes your machine lets the process live through the sleep. On a desktop with aggressive sleep settings, don't rely on it. Either stop the machine sleeping for the duration of a run:

caffeinate -s claude remote-control

or turn off automatic sleep in System Settings and take the power hit. Check what your own machine does before you plan a workflow around reconnecting — one lid-close is a cheap experiment.

The local process closing is fatal

"If you close the terminal, quit VS Code, or otherwise stop the claude process, the session ends."

That's the real constraint, and it's a process constraint, not a power constraint. Anthropic's own recommendation for keeping a session alive on a machine you SSH into is to start it inside tmux or screen. Which is the same answer terminals have had for twenty years and the reason tmux is still in every one of these conversations.

Ten minutes offline while awake kills it

The one that will actually bite you:

"if your machine is awake but unable to reach the network for more than roughly 10 minutes, the session times out and the process exits."

This is a separate failure from sleep: a machine that's awake and can't phone home — hotel wifi that authenticates but doesn't route, a VPN flap, a long tunnel on a train. Ten minutes and the process is gone, not paused. You run claude remote-control again and start over.

Which gives you two ways to lose a session without touching the terminal, and only one of them is the one people warn you about.

One remote session per process

Outside server mode, each Claude Code instance supports one remote session. Run three instances, get three remote sessions. Want many from one process, use server mode.

Some commands only work locally

/plugin and /resume are terminal-only. Plenty of others work from mobile and web but need the value passed as an argument instead of opening a picker — /model sonnet, /effort high, /config key=value. /mcp from the phone returns a text summary instead of the interactive picker.

Worth knowing before you try to change models from your phone and wonder why nothing happened.

"Remote Control is not available" — why

This is the most-searched confusion on the term, and it has at least six separate causes. The docs list them all; nobody has put them in one place.

You're on an API key. Remote Control requires a claude.ai login. claude setup-token and CLAUDE_CODE_OAUTH_TOKEN produce model-request-only tokens that can't establish a session either. Run claude auth login and pick the claude.ai option.

You disabled telemetry. This is the cruel one. DISABLE_TELEMETRY, DO_NOT_TRACK, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC, and DISABLE_GROWTHBOOK each disable the feature-flag evaluation that Remote Control availability depends on. Set any of them — in your shell or in the env block of a settings.json — and the feature silently isn't there. The developers most likely to set DO_NOT_TRACK are exactly the developers most likely to end up on a forum asking why Remote Control doesn't appear.

You're not pointed at api.anthropic.com. Not available on Amazon Bedrock, Google Cloud's Agent Platform, or Microsoft Foundry. Since v2.1.196 it's also disabled when ANTHROPIC_BASE_URL points anywhere else, including an LLM gateway or corporate proxy.

Your org hasn't enabled it. On Team and Enterprise it's off until an Owner flips the Remote Control toggle in Claude Code admin settings. A separate managed setting, disableRemoteControl, turns it off per-device regardless.

Zero Data Retention. Organizations with ZDR or similar compliance configuration can't enable it at all — the admin toggle is greyed out. That's a direct consequence of the transcript being stored server-side.

The rollout hasn't reached you. It's still a research preview. claude doctor tells you which specific eligibility check failed, which is a much better first move than guessing.

Security: what's actually exposed

Better than the shape of the feature suggests, with one caveat that matters.

No inbound ports. Your local session makes outbound HTTPS requests only. Nothing listens on your machine. All traffic goes over TLS through the Anthropic API, using multiple short-lived credentials each scoped to one purpose and expiring independently.

The transcript is stored on Anthropic servers. While Remote Control is connected, your messages, Claude's responses, and tool activity are stored server-side. That's what keeps devices in sync and what lets a session survive a network drop — but it's a real change from a purely local session, and it's why ZDR organizations are excluded. Retention follows Anthropic's data usage policy.

Trusted Devices (beta, Team and Enterprise) ties Remote Control access to an enrolled device plus a sign-in no older than 18 hours, refreshed with Face ID, Touch ID, Windows Hello, or a passkey. Biometrics stay on the device; Anthropic stores only the public key and metadata like platform and enrollment time. It applies to Remote Control only — regular Claude chat, the terminal, and API usage are untouched.

Compare that to the Channels model, which is a different trust story entirely: your messages route through Telegram's or Discord's servers, you're running a bot token you created, and the allowlist is the whole access-control model. Worth reading the Channels security section before you point a bot at a machine with your credentials on it — anyone on the allowlist who can reply through the channel can also approve or deny tool use in your session if the channel relays permission prompts.

I should be straight about which of these I actually run. I've never used Channels. I did build the bolted-on version of it before Channels existed: a Telegram bot wired up through OpenClaw, with Hermes driving Claude. I don't recommend that pairing to anyone — running Claude through a third-party harness has its own history, which I covered in Pi vs Claude Code.

I don't run a bot at all now. I open the Claude app on my phone and remote-control the session directly. Fewer moving parts, no bot token, no third-party server in the path, and nothing to keep patched. That migration is most of why this post exists.

If your reason for wanting a Telegram bot is "message my agent from my phone", check whether Remote Control already does what you want before you build the bridge. Channels earn their place when something other than you needs to push events in — CI, an error tracker, a deploy pipeline. For a human on a phone, the native path is shorter.

Remote Control vs Channels vs Dispatch

Same premise, three entry points. Pick by what starts the work.

Reach for Remote Control when

Reach for Channels when

Reach for Dispatch when

Dispatch's constraints are the sharpest of the three: Pro or Max only, not available on Team or Enterprise, one continuous thread rather than many, and your computer must be awake with the Desktop app open. Dispatch has no reconnect story at all — sleep ends the task. Remote Control at least tries, which on a machine with sane power settings is the difference between the two.

Remote Control vs Claude Code on the web

Both live at claude.ai/code, which is most of why people conflate them.

The difference is where the work happens. Remote Control executes on your machine, so your local MCP servers, tools, and project configuration are all in play. Claude Code on the web executes in Anthropic-managed cloud infrastructure against a repo cloned from GitHub.

That gives you a clean rule. If the work depends on your machine — uncommitted changes, local services, a database on localhost, an MCP server holding credentials — you want Remote Control. If it doesn't, the web is better, because it keeps running after you disconnect and your laptop can close.

The web version is the one that survives you shutting the lid entirely. Remote Control is the one that knows about the branch you haven't pushed.

Where the naming came from

A short timeline, because the names only make sense in order.

2026-02-25: Remote Control ships as a research preview, Max plan first, later reaching Pro. The pitch is continuing a local session from your phone.

2026-03-20: Channels ships as a research preview with Telegram and Discord. The press framing is "OpenClaw killer" — Anthropic building in what people had been bolting on with bot wrappers.

2026-03-26: iMessage joins Channels, macOS only, reading ~/Library/Messages/chat.db directly and replying through AppleScript. No bot token, no external service.

Since then: Dispatch, Slack, and scheduled tasks fill out the rest of the away-from-terminal matrix, and Anthropic publishes the comparison table reproduced at the top of this post.

Three research previews in five weeks, overlapping problem space, no shared naming convention. That's the whole reason "claude code remote control" has a related-searches row full of "vs" queries.

The verdict

Remote Control is the least ambitious and most useful of the three. It doesn't try to be an agent you delegate to. It's a screen and a keyboard for a process already running on your laptop, and it gets the hard part right: nothing leaves your machine except the conversation.

Use it when you want to keep steering. Use Channels when you want events to reach a session you left open. Use Dispatch when you want to hand off a task you haven't started and you're happy to leave the machine awake with Desktop open. Use Claude Code on the web when the work doesn't need your machine at all — that's the only one that keeps going after you close the lid.

And if it's "not available", check DO_NOT_TRACK before you check anything else.

Start by doing this

5 mins: Run claude doctor before anything else. If Remote Control isn't showing up, it names the eligibility check that failed, and the answer is usually an environment variable you set yourself.

15 mins: Start a session with claude --remote-control, open the QR code, and connect from your phone. Then let the machine sleep properly, wait a few minutes, and wake it. Either the session reconnects or it's gone — and which one you get is a fact about your power settings, not about the feature. Find out on a session you don't care about.

30 mins: Try claude remote-control --spawn worktree on a git repo and open two sessions from the web client. Each one gets its own worktree. That's the setup worth having before you try running agents in parallel from your phone.