Remote Control is the Claude Code feature I misjudged hardest. I filed it under "coding on a phone," which sounded like a gimmick, because nobody wants to write a migration on a 6-inch screen. That is not what it is for. Remote Control fixes session fragility: the fact that a long-running Claude Code session has always been chained to one terminal, one screen, and your physical presence in front of it. Once I understood that, it went from novelty to a permanent part of how I run agent sessions.
Here is the mental model, the honest setup, and the two habits (one config, one tool) that decide whether this feature works for you or frustrates you.
What Remote Control actually is
The name is precise. Your Claude Code session keeps running on your local machine, with your filesystem, your MCP servers, and your project configuration exactly as they are. Remote Control opens a live, bidirectional window into that session from another device: the Claude mobile app, a tablet, any browser via claude.ai/code. You can read the conversation, approve actions, and send new instructions. The computation never leaves your machine.
That distinction carries two practical consequences:
Your local environment is available. Whatever your project depends on locally, database, MCP servers, custom skills, files outside the repo, keeps working, because nothing moved. Cloud coding environments strip all of that away. Remote Control does not touch it.
Your terminal must stay alive. The session runs in your local process. Close the terminal, shut the lid for good, kill the process, and the session ends. This is a "step away without breaking flow" feature, not a "turn off your computer and keep working" feature. The tool for the second job is Claude Code on the web, which runs in Anthropic's cloud against a GitHub repo; I compare all the options in my mobile workflows guide.
On security, the architecture is sane: your machine makes outbound HTTPS requests only, with no inbound ports opened, and traffic routes through the Anthropic API over TLS with short-lived scoped credentials. I read the docs on this before pointing it at anything client-related, and the model is the same transport security as a normal Claude Code session with a routing layer on top.
At the time I am writing this, the feature is a research preview for Pro and Max subscribers, so you need a subscription login rather than an API key.
Setup: genuinely two minutes
From inside a running session, which is how I use it 90% of the time:
/remote-control
or the short alias:
/rc
Your full conversation history carries over. The terminal shows a session URL and a QR code; scan it with your phone and the session opens in the Claude app.
To start a session that exists only to be driven remotely, run it from the shell instead:
claude remote-control
This runs in a server-like mode: the process waits in your terminal for remote connections, and pressing spacebar shows the QR code.
Two small quality-of-life details worth adopting on day one. First, /rename your session before going remote; "auth-refactor" is findable in the session list from another device, "Remote Control session" is not. Second, if you find yourself using this daily, /config has an option to enable Remote Control for all sessions so you stop thinking about it.
The workflows where it earns its place
Kicking off long agent runs and leaving the desk. This is the big one for me. I run batch content and refactoring pipelines where Claude works through a queue for twenty or more minutes at a stretch. Before Remote Control, those runs pinned me to the desk purely to approve the occasional action. Now I start the batch, walk away, and approve from the phone. My background agents post covers how those longer runs are structured; Remote Control is the supervision layer on top.
End-of-day review from somewhere that is not a desk. A session with generated code I need to look over does not require a monitor. High-level review, directional feedback, "this file is wrong, redo it with X" all work fine from the couch. Deep line-by-line review still waits for the morning and a real screen, and pretending otherwise leads to sloppy approvals.
The glance-monitor while working on something else. With Claude grinding on machine A and me working on machine B, the phone becomes a status dashboard that costs less attention than a window switch.
And the honest boundary: composing complex, multi-constraint instructions on a phone keyboard is miserable. Remote Control mobile sessions work best when the hard thinking already happened at the desk and the phone only steers.
The permission-prompt problem nobody warns you about
Here is the thing I learned only by using it: the bottleneck of a phone-driven session is not the screen size. It is permission prompts.
A default Claude Code setup asks approval for a large share of tool actions. At the desk that is a keystroke. On the phone, an agent mid-refactor can turn your session into a tap-storm, and worse, an unattended session stalls at the first prompt and waits for you, sometimes for the whole duration of your walk.
The fix is to curate your permission allowlist before you rely on remote sessions. I keep read-only and routinely safe commands pre-approved in my project settings, so remote sessions only interrupt me for things that genuinely deserve a human: file writes outside expected paths, deploys, anything destructive. Tuning that list turned my remote sessions from constant babysitting into two or three meaningful approvals per run. If you do nothing else from this post, do that; it is the difference between the feature demoing well and actually working.
The failure modes, tested
Laptop sleeps: the session reconnects when the machine wakes. In my testing a closed-and-reopened MacBook picked the phone session back up within seconds, with nothing lost.
Brief network drops: tolerated gracefully on both ends. Airplane mode for half a minute did not kill anything.
Extended outage: if your machine cannot reach the network for around ten minutes, the remote session times out. Conversation history survives and you can resume, but the live link has to be re-established.
Terminal closes: session over. This is the one unrecoverable case, so remove it: run Claude Code inside tmux.
tmux new -s claude
cd /path/to/project
claude remote-control
# detach: Ctrl+B then D — the session keeps running
# later: tmux attach -t claude
With tmux holding the process, an accidentally closed terminal app, a dropped SSH connection, or a crashed window costs you nothing. Five minutes of setup deletes the feature's worst failure mode; tmux also happens to be first on the list of CLI tools I use daily with Claude Code for exactly this reason.
Remote Control versus the alternatives
The one-line rule: Remote Control extends your desk. Claude Code on the web replaces it.
Use Remote Control when a local session exists and you want to stay attached to it while moving. Use the web version when there is no local machine involved: it clones a GitHub repo into a cloud sandbox and hands you a PR at the end, which is the right shape for a quick fix from anywhere. And if what you actually want is one workflow per situation, phone-first, cloud, SSH, all of it, that is a bigger map than this post; the mobile workflows guide is the umbrella piece. For the narrower case of shipping deploys from a phone without any agent involved, I wrote up a mobile deployment pipeline a while back and it still holds up.
Where it landed in my routine
Morning: tmux session up, Claude Code running in the main project, Remote Control enabled by default. Through the day, the desk sessions are normal desk sessions. When something pulls me away mid-run, /rc was already done, so I just go, phone in pocket, approvals arriving as they arrive. End of day, one last look from wherever I am, instructions queued for tomorrow, laptop left running.
The cumulative effect is subtle: no single feature moment, just the disappearance of the tax I used to pay every time life interrupted a session. The chain between me and the desk got long enough that I stopped noticing it.
Most of what I build these days, this site included, gets shipped through sessions run exactly this way. If you are curious what that workflow actually produces, the projects page is the output side of everything described above.
