Claude Code Remote Control: what it replaces, and what it does not
Remote Control lets you drive a Claude Code session on your machine from your phone or a browser. It is not a cloud session, and it does not make tmux obsolete. How to start it in the three modes, the requirements that trip people up, the "local process must keep running" rule that decides how to combine it with SSH, and how to pick between Remote Control, the web, and tmux.
Remote Control is the feature people are actually looking for when they search for ways to check on a Claude Code session from the couch. It connects claude.ai/code or the Claude mobile app to a session running on your own machine: you start a task at the desk, walk away, and approve a permission prompt or send the next instruction from your phone. The session never leaves your computer; the phone is a window into it.
That last sentence is the whole mental model, and it explains both what Remote Control is good at and the one limitation that shapes how you should combine it with SSH and tmux. We have written about surviving SSH disconnects and making hooks work on remote machines; this is the piece that fits Remote Control into that picture.
The three ways to start it
All three do the same thing (register the session with Anthropic and print a URL you can open elsewhere) and differ only in what your terminal does meanwhile.
Server mode. The process sits in your terminal waiting for remote connections, and you do all the driving from the phone or browser:
claude remote-control
claude remote-control --name "billing refactor"
Press spacebar to show a QR code for the phone. Without a name, sessions get an auto-generated one prefixed with your hostname, which matters once you have three machines in the session list.
Interactive plus remote. A normal terminal session that is also reachable remotely, so you can type at the desk or from the phone interchangeably:
claude --remote-control
claude --rc "billing refactor"
Mid-session. Already deep in a conversation and about to leave? Inside the session:
/remote-control
/rc billing refactor
The VS Code extension supports /remote-control too, minus the name argument and the QR code. When it is connected, an /rc active indicator sits below the input box; if the connection fails, the indicator turns into the failure reason, and reading it before reconnecting matters, because "another device took over the session" and "the network dropped" want different responses.
Two small conveniences worth knowing: during a long turn the terminal shows a Check in from your phone link, and after several permission prompts in a row it shows Approve tool calls from your phone. Those are the two moments the feature was built for.
Requirements, and who cannot use it
- A claude.ai subscription: Pro, Max, Team, or Enterprise. API keys do not work. On Team and Enterprise an Owner has to enable the toggle in admin settings first, and it is off by default.
- Anthropic's API directly. Bedrock, Google Cloud, Microsoft Foundry, and any
ANTHROPIC_BASE_URLthat points at a gateway or proxy are all excluded. If your company routes Claude through a gateway, this feature is not available to you. - Sign in with
/loginfirst. Without an eligible login,claude remote-controlexits with an error.
What it is not: a cloud session
Anthropic also offers Claude Code on the web, which runs sessions on their cloud infrastructure, and both use the same claude.ai/code interface, so the two get confused constantly. The difference is where the process runs:
- Remote Control: on your machine. Your filesystem, your MCP servers, your project configuration,
@autocompletes your local paths. The web is a window. - Claude Code on the web: in Anthropic's cloud, against a cloned repo. No local setup, and you can run several in parallel without your laptop being involved.
Use Remote Control when you are mid-task locally and want to keep going from elsewhere. Use the web when there is no local state worth preserving.
The rule that decides everything: the local process must keep running
Because the session lives on your machine, closing the terminal, quitting VS Code, or killing the claude process takes it offline. Sleeping the laptop is fine (it reconnects when the machine wakes, and queues status updates in the meantime), but the process itself has to survive.
This is why Remote Control does not replace tmux; it stacks on top of it. If your agent runs on a remote dev box over SSH, the SSH connection dying still kills the shell and everything in it, Remote Control included. The setup that actually works end to end:
ssh -t devbox "tmux new -As claude"
claude --rc "devbox: billing"
tmux keeps the process alive through the disconnect; Remote Control gives you the phone window into it. Each solves the half the other cannot. The full tmux setup, and the things that quietly break inside it, are in the tmux post.
If the process does stop, there is a recovery window. For about four hours after a server stops, claude remote-control brings back every session it was serving, --continue brings back just the one it started with, and --session-id <id> targets a specific one (the id is the segment of the session URL after /code/). Sessions started with --rc or /rc come back through the ordinary claude --continue or --resume. Two timeouts to know: server mode gives up after roughly ten minutes of failed reconnection and exits, and an interactive session reports a disconnect after about thirty minutes of failed heartbeats, at which point /remote-control reconnects it.
Notifications: the phone covers away, hooks cover the desk
Remote Control comes with mobile push: in /config, Push when actions required fires for permission prompts and questions, and Push when Claude decides covers proactive updates. Claude Code suppresses pushes while you are typing in the connected terminal, and the CLAUDE_CLIENT_PRESENCE_FILE variable extends that to "any time you are at the machine, even in another window".
That covers the away-from-desk case well, and it is the honest answer to "how do I know when it finished" for anyone who leaves. It does not cover the at-desk case, where you are in another window on the same machine and a push to your phone is the wrong channel. That is still hook territory: a Stop and Notification hook that raises a desktop notification, per the five-minute setup, and if you want the wait itself to be useful rather than merely announced, Unwait listens to the same hooks and shows one flashcard while the agent works. Hooks fire on the machine running claude, which for a remote box means the reverse tunnel; Remote Control does not change that.
Security, briefly
Your machine makes outbound HTTPS requests only and opens no inbound ports; it registers with Anthropic's API and polls for work, and the server routes messages between your devices over TLS with short-lived, single-purpose credentials. Organizations can require Trusted Devices, a step-up check using Face ID, Touch ID, Windows Hello, or a hardware key before a device can connect. Compared with the alternative most people reach for first (exposing an SSH port to the internet so they can reach the box from a phone), this is a large improvement in attack surface for the same outcome.
How to pick
- Away from the desk, session already running locally: Remote Control. This is its home game.
- Away from the desk, no local state that matters: Claude Code on the web.
- Agent on a remote server: tmux for survival, Remote Control on top for the phone window, a reverse tunnel if you want hooks on your laptop.
- At the desk, in another window: hooks and desktop notifications, not push.
- API key, Bedrock, or gateway user: Remote Control is unavailable; tmux plus SSH remains the whole answer.
The feature is genuinely good at the narrow thing it does. Just keep the mental model: it is a window, not a relocation. Whatever keeps the process alive on the far side of the window is still your job.