Blog

Claude Code from your phone: what actually works in 2026

The question people actually mean is one of two things, and they have completely different answers: run the agent somewhere else, or reach the one already running on your Mac.

There are three distinct answers and picking the wrong one wastes an afternoon. Claude Code on the web runs the session on Anthropic's cloud VMs from a GitHub clone, not your working copy. Remote Control keeps the session on your machine and connects claude.ai or the Claude mobile app to it, so your filesystem and MCP servers stay local. A third-party bridge does the same attaching trick for agents that have no remote story of their own. The deciding question is not which is most convenient, it is what leaves your machine: all three send conversation text to a server, and they differ in how much.

First, which question are you asking

Two different problems get typed as the same search, and the answers do not overlap.

  • Run it elsewhere: you want work happening while your laptop is shut. That is a cloud session, and the code it edits is a clone of your repository, not your working copy.
  • Reach what is already running: the agent is on your Mac, it stopped to ask something, and you are not at your desk. That is remote control of a local session, and nothing moves.

Claude Code on the web, and the mobile app

Anthropic runs sessions on their own cloud VMs at claude.ai/code, and you can monitor them from the Claude mobile app. The VM clones your repository's GitHub remote at your current branch, so local commits you have not pushed are not there, and a repository with no GitHub remote is uploaded as a bundle instead.

It is the right answer when the work is self-contained and you want it running while you are away. It is the wrong answer when the task depends on your machine: your local uncommitted state, a service running on localhost, a tool you have installed and not committed.

Worth knowing for anyone reading a security policy: sessions run in isolated Anthropic-managed VMs, network access is limited by default, and git credentials stay outside the sandbox with a proxy authenticating on the session's behalf. That is a serious design, and it is theirs rather than something you configure.

Remote Control: the local session, from your phone

This is the one most people are actually looking for, and it is first-party. Running claude remote-control, or /remote-control inside a session, connects claude.ai/code and the Claude iOS and Android apps to a session running on your machine. Claude keeps executing locally the whole time, so your filesystem, your MCP servers and your project configuration stay available, and you can send messages from the terminal, the browser and the phone interchangeably.

It is available on Pro, Max, Team and Enterprise, though not with API-key authentication, and an Owner has to enable it on Team and Enterprise. If you run Claude Code and want to answer it from the couch, start here rather than with anything else on this page.

The trade is stated plainly in Anthropic's own documentation, and it is the thing to read before turning it on: while Remote Control is connected, the session transcript, including your messages, Claude's responses and tool activity, is stored on Anthropic servers. Execution stays on your machine; the record of it does not. Organisations with Zero Data Retention cannot use it at all.

What is left for a third-party bridge

Given that, the honest question is what a non-Anthropic tool adds, and there are two answers.

The first is the other agents. Remote Control is for Claude Code. If your afternoon is a Codex pane, a Gemini CLI pane and an Aider pane, none of them has a remote story, and the one that stopped to ask you a question is as likely to be one of those as it is to be Claude.

The second is how much leaves the machine. A bridge that only needs to render a conversation and route a reply does not need your tool output or your scrollback, and can delete what it held once the session stops being live. That is a smaller surface than a synced transcript that includes tool activity, and it is worth comparing directly rather than assuming any option is the private one.

How this works in Forkbench

Forkbench is a Mac app for running coding agents, and Talk is its remote surface. It attaches to a conversation already open on your Mac from any browser or phone, so you read what the agent asked and reply, and it routes back to that terminal. It is attach-only by design: it cannot start a session, because a remote surface that can start work is a remote surface that can start work you did not ask for.

What it adds over the first-party option is that it does not care which vendor's agent is in the pane, and that a Thread shows you which of its panes is blocked rather than leaving you to check each one. Sleep Control keeps the Mac awake with the lid shut so the session is still there when you look.

What crosses the network, stated as plainly as Anthropic states theirs: to render a conversation in a browser and route your reply to the right terminal, the readable text of that live conversation and its title pass through us. Raw tool output and terminal scrollback are never sent at all, and a conversation that is not on a shared board is deleted a few minutes after it stops being live. Your notes and Vault secrets are sealed under keys we do not hold and never work this way. Talk is part of Pro.

Related: Answer a blocked agent from your phone

Frequently asked

Keep reading