Remote Control turns your phone into a console for your dev box

By Daniel S. · September 1, 2026

The usual disclosure: the research below was done by an AI agent against Anthropic's official docs, and the field experience is ours — Remote Control was the only console we had during a datacenter outage weekend. This post is what we wish we'd read before using it: what the feature actually is, what it's genuinely good for, and where the sharp edges are. Facts from the docs, marked as such; where the docs go quiet, we say so instead of guessing.

What it actually is

Remote Control connects your phone (Claude app) or any browser (claude.ai/code) to a Claude Code session running on your own machine. That sentence carries the whole architecture: unlike Claude Code on the web, which spins up a cloud VM and clones your repo into it, Remote Control is a window into a local process. Execution, filesystem access, MCP servers, project config — all of it stays on your box. The phone is a remote keyboard and screen.

You start it explicitly: claude remote-control (a server that waits for connections), claude --rc (a normal terminal session that's also reachable remotely), or /rc inside a session you're already in. It prints a session URL and a QR code. Scan it, and your couch — or a datacenter parking lot — is a terminal.

What it's actually for

The docs pitch "start at your desk, continue from the couch." Our real use case was sharper: a machine in a rack, a long-running task, and a human who had to physically leave. The phone session let us watch the task, answer its questions, and approve permission prompts from wherever we were standing. Push notifications fire when Claude needs a decision or a long task finishes — so instead of babysitting a terminal, you get tapped on the shoulder.

Honest assessment after a weekend of real use: for monitoring and steering long-running work, it's genuinely good. This is the class of feature you don't miss until a machine is installing itself 40 minutes from your keyboard.

The good — and these are real design decisions, not marketing

• Execution stays local. Your code never leaves your machine. The cloud sees the conversation, not the repo (with one big caveat below).
• Outbound-only. The docs are explicit: the session "makes outbound HTTPS requests only and never opens inbound ports on your machine." Your LAN attack surface does not grow. No port forwarding, no tunnel daemon, no new listening service.
• Short-lived, scoped credentials. The connection uses "multiple short-lived credentials, each scoped to a single purpose and expiring independently," and a stopped server's sessions die for good after about four hours.
• Off by default, and fail-safe in a smart place. Remote Control only activates when you ask for it. Better: a settings file checked into a repo can force auto-connect off for everyone who opens that repo, but a checked-in true is ignored — so a malicious or careless repo cannot silently turn your sessions remotely reachable. Somebody thought about that failure mode, and it shows.
• A global kill switch exists (disableRemoteControl in settings), and server mode can isolate each remote session in its own git worktree.

The bad — also real, and the docs mostly admit it

• The session URL is a credential, and the docs say exactly that — then stop. "Treat session URLs like credentials" is a direct quote. What a leaked URL alone gets an attacker — without your account password — is not documented anywhere we could find. When a vendor tells you to handle an artifact like a credential, believe them: assume a leaked link is a leaked key until documented otherwise. Don't paste session URLs into chats, notes, screenshots, or scripts.
• Your claude.ai account is the entire perimeter. A connected device gets the session's full capability surface — filesystem, tools, and crucially the ability to approve permission prompts. So anyone holding an authenticated claude.ai session (a stolen unlocked phone, a browser you stayed logged into) holds a console adjacent to your shell. Anthropic built a real answer to this — Trusted Devices, which binds access to enrolled devices with biometric step-up — but it's Team and Enterprise only. On Pro and Max plans, your account password and 2FA are the whole story. Go set the strongest 2FA you can, today.
• The transcript lives on Anthropic's servers while connected. Messages, responses, and tool activity — which for infrastructure work means hostnames, IPs, paths, and command output — stored server-side under the standard retention policy, to keep devices in sync. The sharpest tell is in Anthropic's own docs: organizations with Zero Data Retention requirements can't enable Remote Control at all. The vendor is telling you which axis is sensitive.
• No documented audit trail distinguishes remote actions from local ones. After an incident, you could not tell from the record whether a command came from your keyboard or a phone. Combined with the point above, that's the gap we'd most like to see closed.

How we actually run it now

We're a security-minded shop, so our default for remote-anything is off — and after the weekend proved the feature's worth, we didn't just shrug it into the toolbox. We wrote it down as a scoped exception, which took twenty minutes and is the part of this post you can steal:

1. Per-session opt-in only. No auto-connect, ever. You should know every moment a session is remotely reachable, because you asked for it.
2. Never combine it with permission-bypass modes. The phone being able to approve prompts is the feature; that only means something if prompts exist.
3. Treat the URL like an SSH key, because the vendor told you to.
4. After a trip: sign out everywhere and review the device list in your account settings. Sessions die in hours; logged-in browsers don't.
5. Don't attach it to sensitive sessions. While connected, the transcript is off-box. Decide what class of work that's acceptable for before the convenient moment arrives.
6. On machines that should never be remotely drivable, set the kill switch — one line of settings, and that class of risk stops existing there.

The verdict

Remote Control is a well-built version of a thing you should still think twice about. The architecture makes several genuinely good calls — local execution, outbound-only, short-lived credentials, fail-safe settings precedence. And it collapses to one honest sentence: your phone becomes a console for your dev box, gated by your claude.ai account. If that sentence fits your threat model, use it deliberately and it will earn its keep the first time you're forty minutes from a machine that needs one keypress. If it doesn't fit, disableRemoteControl is one line.

What we'd push Anthropic on: document the leaked-URL failure mode explicitly, bring Trusted Devices below the Enterprise tier, and give remote actions a distinguishable audit trail. The feature deserves its own paper trail.

Sources: Anthropic's Remote Control documentation, security docs, data-usage docs; Help Net Security's coverage. Related here: why local AI is a security decision.