Claude Code Remote Control for Client Work: Steer a Client Build From Your Phone

What Claude Code Remote Control Does

Remote Control lets you continue a local Claude Code session from another device. You start the session on your computer, then open it from the Claude app for iOS or Android, or from claude.ai/code in a browser, and keep working. Claude keeps running on your machine the whole time, so your filesystem, MCP servers, tools, and project configuration all stay available. The conversation stays in sync across every connected device, so you can type from the laptop, then the phone, then the laptop again.

For a builder with clients, the value is simple. Client builds have long stretches where Claude is working and you are waiting: a migration, a test run, a refactor across a dozen files. Those stretches used to mean staying near the laptop or coming back to a session that had been stuck on a question for an hour. With Remote Control, the question reaches your phone, you answer it, and the build keeps moving while you are on a discovery call or out of the office.

How to Turn It On From the Desktop App

In the desktop app's Code tab, open a local session and type /remote-control or /rc in the prompt box. Once it connects, the session appears in the session list at claude.ai/code and in the Code tab of the Claude app on your phone. Remote Control sessions show a computer icon with a green dot when they are online. To disconnect, run /remote-control again. If you want every new session to be reachable without typing the command, turn on Settings, Claude Code, Connect new sessions to Remote Control.

• Install the Claude app on your phone and sign in with the same account and organization you use for Claude Code. Running /mobile in a session shows a QR code that opens the right app store.
• Start Remote Control in the client's session with /rc, ideally after you have named the session by client so you can find it in the list.
• Open the Claude app, tap Code, and pick the session. Photos and files you attach from the phone reach the session on your machine.
• Turn on push notifications: run /config and enable Push when actions required, Push when Claude decides, or both. You can also ask for one directly, such as 'notify me when the tests finish'.

If you also work in the terminal, claude --remote-control (or --rc) starts an interactive session that is also reachable from your phone, and claude remote-control runs a server that can host several sessions at once. The desktop path covers what most client work needs.

Remote Control vs Cloud Sessions vs Dispatch

The Claude app reaches Claude Code in more than one way, and picking the wrong one causes most of the confusion. The difference is where the work runs.

My default for client work is Remote Control, because most client builds depend on things that live only on my machine: a database connection, an API key in an untracked file, a local MCP server for the client's tools. Cloud sessions are the better fit for small, self-contained fixes on a repository that is already on GitHub. Dispatch is useful for starting something new from the phone, but on client work I would rather start the session at the desk, where I can check which folder and branch it is in.

The Leash Rule: Steer, Approve, Never Ship

A phone screen is a bad place to review a client's code. You cannot read a long diff properly, you cannot run the app, and you are usually answering between other things. So the Profit Room rule is short. From the phone, you steer: answer Claude's questions, redirect it, tell it to stop. From the phone, you approve what you can read in full. You do not ship. Merging to the client's main branch, deploying, and anything that touches production waits until you are back at a real screen.

• Set the permission mode before you leave the desk. Remote Control sessions offer Manual, Accept edits, and Plan from the app. Bypass permissions and Auto cannot be selected from the app for a Remote Control session. For client work, Manual or Plan is the right leash while you are away. [Claude Code permissions for client work](/blog/claude-code-permissions-for-client-work) covers what each mode allows.
• Run the session in a worktree, so nothing it does lands on the client's main branch until you merge it yourself. [Git worktrees for client work](/blog/claude-code-git-worktrees-for-client-work) covers the setup.
• Name the session by client before you connect. On a phone, a session list of auto-generated names is how you end up answering one client's question in another client's build. [Claude Code sessions for client work](/blog/claude-code-sessions-for-client-work) covers the naming habit.
• Use the diff pane, not trust. When the session's folder is a git repository, a connected device shows a diff of the changes. Skim it to confirm Claude is working in the right place, then do the real review at your desk.

The rule also protects the client relationship. A client never sees that you answered a question from a parking lot, but they do see a bug that shipped because a diff was approved on a five-inch screen. Remote Control is for keeping a build moving, not for finishing it.

Client Data and Remote Control

Read this before you turn Remote Control on for a client with sensitive data. According to the Remote Control documentation, your local session makes outbound HTTPS requests only and never opens inbound ports on your machine, and all traffic goes through the Anthropic API over TLS. Execution and file access stay on your computer. But while Remote Control is connected, the session transcript, including your messages, Claude's responses, and tool activity, is stored on Anthropic's servers so it can stay in sync across devices. Stored transcripts are retained under Anthropic's data usage policy.

For most client builds that is fine. For a client whose contract restricts where their data can go, it is a question to settle before you connect, not after. Organizations with compliance requirements such as Zero Data Retention cannot enable Remote Control at all, and the disableRemoteControl setting turns it off entirely. If a client's project needs that boundary, set it in that project and keep that client's work at the desk. The broader rules are in [is it safe to use Claude Code with client data](/blog/is-it-safe-to-use-claude-code-with-client-data).

Where Remote Control Fits in a Client Week

The best use I have found for Remote Control is the long, boring middle of a build. I start the session at the desk with a clear plan, a named session, a worktree, and Plan or Manual mode. Then I leave for a call or an errand, and the phone tells me when Claude needs an answer. When I get back, the work is further along than it would have been, and nothing has shipped without me looking at it on a real screen.

Pair it with the rest of your delivery system. [Background tasks](/blog/claude-code-background-tasks-for-client-work) keep long-running commands going inside the session, [checkpoints](/blog/claude-code-checkpoints-for-client-work) let you rewind a bad turn when you are back at the desk, and your [weekly client update](/blog/weekly-client-update-prevents-fires) is where the progress becomes visible to the client. If you are juggling several clients, [running multiple Claude Code client projects at once](/blog/run-multiple-claude-code-client-projects-at-once) covers the scheduling side.