I once handed off a batch of dependency updates and left to run errands.
Thirty minutes later I came back to find Claude Code waiting quietly at the very first approval prompt. Actual work done in that half hour: maybe a minute's worth.
If you are an indie developer shipping apps on your own, this kind of "time spent only waiting" adds up fast. The decision itself takes three seconds, but those three seconds require you to be sitting at your desk. After it happens a few times, you start avoiding long-running handoffs altogether.
Remote Control exists to close exactly that gap. It landed alongside claude self-hosted-runner in v2.1.224 on August 7, 2026, and v2.1.229 on August 12 added --continue for picking a stopped session back up. It is a research preview, but it is available on every plan.
Remote Control does not move your work to the cloud
Let me clear up the most common misreading first.
Turning Remote Control on does not relocate anything to a cloud environment. Claude Code keeps running on your machine. Your phone and your browser simply become windows into that local session.
Because of that design, a few things stay true:
- File reads and writes happen against your own filesystem
- Your configured MCP servers and project-specific settings remain available
- Typing
@on your phone autocompletes file paths from your local project
So there is no "it behaves differently because it re-ran somewhere else" problem. It is closer to peeking at the Mac on your desk from across town and adding an instruction. The conversation stays in sync across terminal, browser, and phone, so you can switch between them mid-task without losing the thread.
The flip side is equally direct: if your machine is off, nothing happens. That one is easy to trip over if you assume the work lives in the cloud.
The shortest path to your first session
You need three things:
- Claude Code v2.1.224 or later
- A claude.ai subscription
- Authentication with a claude.ai account
If you currently authenticate with an API key, you will need to sign in again with the claude.ai option.
# Check your version
claude --version
# Sign in with a claude.ai account (pick the claude.ai option)
claude auth loginOnce that is done, start a session with Remote Control attached.
# Starting a fresh session
claude remote-control
# Attaching to a session that is already running,
# from inside Claude Code
/remote-controlThen open the Claude app on your phone and tap Code in the navigation, or open the Code view on claude.ai in a browser. Your running sessions are listed there. Tap one and you pick up the conversation where it stands.
If typing the command every time gets tiresome, you can leave it on permanently.
# Open /config inside Claude Code and enable
# "Enable Remote Control for all sessions"
/configOne note for teams: on Team and Enterprise plans this is off by default until an Owner flips the Remote Control toggle in the Claude Code admin settings. Personal accounts have no such gate.
What to check before you walk away
These are the details that tend to surprise people mid-errand. Knowing them in advance saves a small panic on the train.
| Area | What applies |
|---|---|
| Permission modes | You can pick Manual, Accept edits, or Plan. Bypass permissions and Auto are not selectable |
| Local-only commands | /plugin and /resume run from the terminal only, with or without Remote Control |
| Network | You need to reach the Anthropic API on port 443 |
| Interruptions | If your laptop sleeps or the connection drops, Claude Code reconnects automatically once the machine is back online |
| Timeout | If the machine is awake but cannot reach the network for roughly ten minutes, the session times out and the process exits |
The one that shapes daily use most is that Auto is not available as a permission mode. Auto mode only became the default on August 14, so if that is how you normally work, a Remote Control session will feel like it asks for confirmation more often than you expected.
Read that as a design hint rather than a limitation. Work you hand off over Remote Control should assume you are in the loop. If you shape the task so there are fewer approval points before you leave, you can handle the rest one-handed while you are out.
The ten-minute timeout is also more realistic than it sounds when you are moving around. Wrapping up a checkpoint before you head underground is a small habit that pays off.
Picking a stopped session back up
When you stop claude remote-control with Ctrl+C, the sessions it was serving stop responding from your phone or browser. They are not archived, though, as long as you were not running another claude remote-control in the same directory and did not start this one with --no-create-session-in-dir.
There are three ways back, and they differ in how much they restore.
| Command | What comes back | When to use it |
|---|---|---|
claude remote-control | Every session that server was serving | You had several tasks running in parallel |
claude remote-control --continue | Only the session the server started with; it exits when that session ends | One task, and you just want the thread back |
claude remote-control --session-id <id> | Only the session whose ID you pass | You already know which one you want |
# Bring back just the session this server started with
claude remote-control --continue
# Bring back one specific session by ID
claude remote-control --session-id <session-id>There is one deadline worth memorizing: these work for about four hours after the server stopped. Past that, run claude remote-control to start fresh. claude --resume and claude --session-id follow the same four-hour window.
If you archived a session in the meantime, --continue and --session-id will unarchive it on v2.1.228 or later. That is a meaningful improvement over having to hunt for it manually.
A session you started with claude --remote-control or /remote-control also comes back with Remote Control still attached when you resume the conversation using claude --continue or claude --resume. The condition is that Remote Control was still on when the session ended.
When a session refuses to restore at all, the cause is usually session management rather than anything Remote Control specific. In that case, start with what to do when Claude Code sessions won't restore.
Always on, or only when you need it?
You can enable it for every session through /config, but I keep it manual and deliberate.
The reasoning is plain: a session with Remote Control on is a session reachable from outside. For work that finishes in a couple of minutes at my desk, there is no reason to open that window at all.
I do turn it on before stepping away when the task looks like one of these:
- Bulk dependency updates, or anything with a long build in it
- Work I know will hit approval points a few times
- Work where I want to see a result before deciding what comes next
The test is a single question: is my judgment likely to be needed even once while I am away? If not, skip it. If yes, turn it on. That alone removes most of the wasted trips back to the desk.
If it is the connection itself that dies partway through a long reasoning step, the cause is often the path rather than your Remote Control setup. When a gateway or proxy sits in the middle, the piece on relays killing long-running streams walks through how to isolate it.
One thing to try next
If you do one thing today, make it this: start your next long-running task with claude remote-control.
Step away for a few minutes and check that the same conversation shows up in the Claude app on your phone. Once you have seen it work, the time you spend tethered to your desk for approvals becomes a choice rather than a given.
I only recently made this part of my routine, and I am still figuring out where it fits best. What I can say is that deciding to leave the desk got noticeably easier.