You ask Claude to refactor a large codebase -- restructuring 40 files across six modules. The estimated time: 40 minutes. You need to pick up your kids from school in 10 minutes. Without Remote Control, you have two bad options: cancel the task and lose the progress, or leave your laptop open on the kitchen table and hope nothing needs your approval while you are driving.
Remote Control gives you a third option. You type /rc in your running session, scan the QR code with your phone, and walk out the door. From the school parking lot, you watch Claude work through your phone. When it asks "Should I also update the import paths in the test files?", you type "Yes, update all test imports too" from your phone screen. The session never pauses. The work never stops. Your laptop is at home running the actual code; your phone is just a window into that session.
That is the core idea: your machine does the work, and any device with a browser becomes a remote control for that work. Your local filesystem, MCP servers, tools, and project configuration all stay available -- nothing moves to the cloud.
Navigate to your project directory and run:
The process stays running in your terminal, waiting for remote connections. It displays a session URL and you can press spacebar to show a QR code for quick phone access.
Output:
This command supports two optional flags:
Already deep into a conversation and realize you need to leave? Use the slash command:
Or the shorthand:
This starts Remote Control within your current session, carrying over your entire conversation history. The --verbose, --sandbox, and --no-sandbox flags are not available with the slash command -- those only work with claude remote-control.
Naming tip: Use /rename before /remote-control to give the session a descriptive name like "refactor-auth-module". This makes it easy to find in the session list when you open claude.ai/code on another device.
Once a Remote Control session is active, connect from any device in three ways:
The conversation stays in sync across all connected devices. You can send messages from your terminal, browser, and phone interchangeably.
Subscription requirement: Remote Control requires a Pro or Max plan. It is not available on Team or Enterprise plans, and API keys are not supported. If you are not on a supported plan, the command will not work.
When you run claude remote-control, your local machine does all the work. It reads your files, runs your MCP servers, executes tool calls, and writes changes to your filesystem. None of that moves to the cloud.
The web or mobile interface you connect from is a thin client -- it displays the conversation and sends your messages back to your local machine. Think of it like a TV remote: the remote sends signals, but the TV does the processing.
Your machine is like a CI/CD self-hosted runner. A self-hosted runner sits on your infrastructure, does the actual build and test work, but communicates with GitHub through an outbound connection. GitHub never reaches into your network -- the runner calls out.
Remote Control works the same way:
Your local Claude Code session makes outbound HTTPS requests only and never opens inbound ports on your machine. When you start Remote Control, it registers with the Anthropic API and polls for work. When you connect from another device, the server routes messages between the web or mobile client and your local session over a streaming connection. All traffic travels through the Anthropic API over TLS using multiple short-lived credentials, each scoped to a single purpose and expiring independently.
Because code runs locally, everything you have configured locally keeps working:
Nothing needs cloud configuration. If it works in your terminal, it works through Remote Control.
Remote Control has one critical limitation: it runs as a local process. If you close the terminal or stop the claude process, the session ends. For a 5-minute task, this does not matter. For a 2-hour refactor, it matters a lot.
The fix is tmux -- a terminal multiplexer that keeps processes running even after you close the terminal window.
Step 1: Start a tmux session:
Step 2: Inside tmux, start Remote Control:
Step 3: Detach from tmux (the session keeps running):
Press Ctrl+B, then D.
Step 4: Close your terminal entirely. The Claude session is still running inside tmux.
Step 5: When you return, reattach:
Output:
Why this matters: Without tmux, closing your laptop lid or your terminal application kills the Claude process and ends your Remote Control session. With tmux, the process survives because it is not attached to your terminal window -- it is attached to the tmux server process, which runs independently.
This is essential for long-running tasks. Start the session in tmux, enable Remote Control, and monitor from your phone. Your laptop can sleep, your terminal can close, and the session persists.
Remote Control and Claude Code on the Web both use the claude.ai/code interface, but they are architecturally different. Here is how to choose:
The decision rule: If you need your local environment accessible from another device, use Remote Control. If you want to work without any local machine at all, use Claude Code on the Web. If you are at your desk with full terminal access, use your terminal.
In Lesson 22, you learned that worktrees let you work on multiple branches simultaneously without switching. Combined with Remote Control, you get isolated, monitorable parallel work.
The pattern:
Now scan the QR code and monitor the feature work from your phone while your main branch stays untouched in the original directory. The worktree gives you isolation; Remote Control gives you mobility.
For even more resilience, wrap it in tmux:
This gives you: isolated branch work (worktree) + persistent process (tmux) + mobile monitoring (Remote Control). Each piece solves a different problem; together they create a workflow where long-running tasks run safely in isolation while you stay informed from anywhere.
What it looks like: You close your terminal, open claude.ai/code on your phone, and the session shows as offline.
Why it happens: Remote Control runs as a local process. No terminal process means no session.
Fix: Use the tmux survival trick described above. Always start long-running Remote Control sessions inside tmux.
What it looks like: Your laptop is awake but your WiFi drops for 15 minutes. When you reconnect, the session is gone.
Why it happens: If your machine is awake but cannot reach the network for roughly 10 minutes, the session times out and the process exits.
Fix: Run claude remote-control again to start a new session. For environments with unreliable network, consider whether Claude Code on the Web (fully cloud-hosted) might be a better fit.
What it looks like: You start claude remote-control in two different terminal tabs and wonder why only one shows up.
Why it happens: Each Claude Code instance supports one remote session at a time. Multiple instances each get their own independent session.
Fix: Use /rename to give each session a descriptive name before enabling Remote Control. This makes it easy to identify which session is which in the claude.ai/code session list.
What it looks like: You run claude remote-control and get an error, or the session starts but no remote device can connect.
Why it happens: Remote Control requires a Pro or Max plan. It does not work with API keys, Team plans, or Enterprise plans. You also need to be logged in via /login.
Fix: Verify your subscription tier. Run claude and use /login to authenticate through claude.ai. Make sure you have accepted the workspace trust dialog by running claude in your project directory at least once.
Exercise 1: Start Remote Control and Connect from Your Phone
In your terminal, navigate to any project directory and run:
When the session URL appears, press spacebar to show the QR code. Scan it with your phone (or open the URL in any browser). Send a message from your phone and watch it appear in your terminal. Then type a response in your terminal and see it appear on your phone.
What you're learning: The basic Remote Control lifecycle -- starting a session, connecting from another device, and seeing the bidirectional sync between terminal and mobile. This is the foundation for all remote workflows.
Exercise 2: The tmux Survival Trick
In your terminal:
Connect from your phone by scanning the QR code. Then:
Verify the session continued running the entire time.
What you're learning: How to make Remote Control sessions survive terminal closure. This is the single most important technique for long-running tasks -- without it, closing your laptop kills the session.
Exercise 3: Power Combo — Worktree + Remote Control + Phone Monitoring
In your terminal:
Once the Claude session starts, type /rc to enable Remote Control. Connect from your phone, then paste this prompt into your phone:
Detach from tmux (Ctrl+B, D) and verify you can still interact from your phone.
What you're learning: Combining three tools -- worktrees for isolation, tmux for persistence, and Remote Control for mobility. Each solves a different problem; together they create a resilient workflow for parallel feature development monitored from anywhere.
Exercise 4: Decision Framework Practice
Start a normal Claude session and paste this prompt:
Compare Claude's answers against the decision table in this lesson. Do you agree with its reasoning?
What you're learning: The decision framework for choosing between Remote Control, Claude Code on the Web, and terminal access. Matching the right tool to the scenario prevents frustration and wasted time.