Finished reading? Continue your journey in AI with these hand-picked guides and tutorials.
Boost your workflow with our browser-based tools
Share your expertise with our readers. TrueSolvers accepts in-depth, independently researched articles on technology, AI, and software development from qualified contributors.
TrueSolvers is an independent technology publisher with a professional editorial team. Every article is independently researched, sourced from primary documentation, and cross-checked before publication.
Anthropic just launched Remote Control for Claude Code, and if you're wondering whether picking up your phone means uploading your codebase to the cloud, here's what matters: it doesn't. The feature routes control messages through Anthropic's API, but your code, files, and execution environment stay exactly where they are on your machine. Understanding why this architecture exists and what it means for security reveals both the capability and the constraints.
Every developer who has used Claude Code for more than an hour has faced the same friction: a session is mid-flight, something comes up away from the desk, and the choices are to abandon the work, carry the laptop, or jury-rig a tunnel that breaks half the time. Remote Control is Anthropic's answer to that specific scenario, and the first question it raises is an obvious one: does your code have to leave the machine for this to work?
It does not. The most important architectural fact about Remote Control is also the most specific one: only two things travel through the Anthropic API relay. When you send a message from your phone and Claude Code responds, the conversation text and the tool results that Claude generates move through the relay. That is the complete list. Your source code does not. Your filesystem structure does not. Environment variables, MCP server configurations, the contents of your .claude/ settings directory, project credentials, none of it enters the relay at any point during the session.
Claude Code continues executing on your local machine throughout. The phone becomes a viewport into a process that was already running on your laptop before you walked away. When you type a prompt on mobile and Claude Code opens a file, edits a function, and runs a test suite, those operations happen against your local disk. The API relay routes the instructions down and the results back up over an encrypted connection. It never sees what the function contained or what was on that disk.
This matters because the relay carries no memory of what passed through it. Each request arrives, gets routed, and leaves no residue on Anthropic's infrastructure. If someone were to compromise the relay itself, they would observe conversation messages and tool outputs for the duration of the session. They would not gain access to your repository, your environment variables, your SSH keys, or your project structure. That is a meaningful boundary, and it is the one the architecture is genuinely designed to protect.
The connection design reinforces this. The local Claude Code process makes outbound HTTPS requests only. No inbound ports open on your machine. When you activate Remote Control, the session registers with Anthropic's API and begins polling for instructions. The machine reaches out continuously rather than waiting to receive traffic. All of those approaches required opening the local machine to inbound connections. Remote Control does not.
Every Remote Control session operates through multiple short-lived credentials, each scoped to a single purpose. Session initiation uses one credential. Message routing uses a separate one. Tool execution confirmation uses another. Each expires independently. According to Anthropic's official security documentation, this compartmentalization is designed specifically "to limit the blast radius of any single compromised credential." That phrase is worth sitting with: the architecture anticipates that credentials may be compromised and builds the system so that any single compromise yields limited access rather than broad access.
Short-lived credentials cannot be replayed after they expire. A session token captured mid-connection provides no ongoing access once it expires. The design means that credential theft has a narrow window and a narrow scope simultaneously.
All traffic moves over TLS. This is the same transport security used in standard Claude Code sessions. Remote Control does not introduce a new encryption regime; it extends the existing encrypted transport to include the mobile relay path.
The permission model carries over from desktop to mobile without modification. Every file edit, test run, and bash command still requires explicit approval from whoever is holding the connected device. One specific flag deserves attention here: the --dangerously-skip-permissions option that allows unattended operation is deliberately not supported with Remote Control. Every action requires a human to confirm it. Anthropic's stated rationale is that unattended Remote Control sessions making changes without oversight would undermine the fundamental purpose of the permission model. You can use Remote Control while doing something else, but Claude Code will pause and wait for your approval before taking consequential actions.
Credential scoping limits what any single compromised credential can reach; permission preservation ensures that unattended execution is blocked by design. Together, these two properties mean the credential compromise scenario and the unattended execution scenario are both explicitly addressed. What the architecture does not address is a different threat entirely, which the next section covers.
Session URLs should be treated as credentials. The URL or QR code generated when you start Remote Control is the access key to your session. Sharing it through Slack messages, screenshots, or screensharing tools exposes the session to anyone who receives it.
Most coverage of this feature addresses only one column of the security ledger: the outbound-only design successfully eliminates network-level intrusion. That is accurate. But Remote Control adds a new item to the other column that is not present in standard local Claude Code usage: account-level compromise now yields local machine access.
In a standard local Claude Code session, an attacker who compromises your Anthropic account credentials gains no access to your running session. The session is local. There is no remote entry point. With Remote Control active, a phished or stolen Anthropic login can give an attacker entry into any currently running session. That is a real expansion of what account security means in this context. The architecture does not protect against it because authentication is how legitimate access works. The defense is account hygiene, not the session design.
The same logic applies to the session URL. If the URL generated at session start is captured through screensharing or a sent message, whoever has it has a valid session credential for the duration of that session's life. This is not a flaw in the design; it is how any authenticated remote access system operates. It is a new exposure that purely local usage did not create.
Sandboxing adds a layer here worth understanding. Sandboxing is off by default for Remote Control sessions; the command supports --sandbox and --no-sandbox flags, and users must opt in explicitly. When enabled, sandboxing uses OS-level isolation primitives to restrict the Claude Code process to your project directory and prevent arbitrary network access. The protection requires both filesystem and network isolation to be effective; each component addresses a different escape path. For sessions involving sensitive codebases or credentials stored in the project environment, the --sandbox flag is the appropriate default, not the optional add-on.
Mobile context introduces a softer risk that official documentation acknowledges: approval fatigue. Anthropic's sandboxing documentation addresses the scenario where permission prompts arrive faster than a user can meaningfully evaluate them. Remote Control sessions are more likely to produce that dynamic than desktop sessions, because approvals may arrive while you are walking, in a meeting, or otherwise not focused on what Claude is doing. The permission system is only as strong as the attention paid to it.
The limitations of Remote Control and its core security property are the same thing viewed from different angles. These constraints are not engineering shortcomings but structural consequences of the design choice that keeps code off cloud infrastructure.
Remote Control supports one active remote connection per Claude Code instance, and extended network outages of approximately ten minutes cause the session to time out and require a full restart. The ten-minute figure is the most practically significant constraint for mobile workflows. Brief disruptions reconnect automatically; sleeping your laptop for a few minutes reconnects in under ten seconds with no lost context. But a sustained outage, a network failure, or closing the lid of a machine that enters deep sleep and loses its connection for longer than the timeout window terminates the session entirely.
Why does this constraint exist? Because there is no cloud execution layer to hold state. When you connect via Remote Control, you are connecting to a process on your local machine. If that process loses its connection to the relay for long enough, the relay drops the session. If the local terminal exits for any reason, the session ends immediately and completely, there is nothing remote to reconnect to. Resume capability would require cloud infrastructure to hold the execution context, which would require moving code to cloud infrastructure, which is precisely what the architecture is designed not to do. The constraint and the security property are the same thing viewed from different angles.
The practical implications for remote workflows:
Terminal must stay open on the local machine; closing it ends the session immediately
One active remote viewer per Claude Code instance; multiple running instances each maintain separate sessions independently
Network interruptions under approximately ten minutes reconnect automatically; anything longer requires restarting Remote Control from the local machine
Workspace trust must be established before Remote Control is available, run Claude in the project directory at least once from the local terminal
Requires Claude Code version 2.1.52 or later; authentication uses claude.ai credentials, not API keys
Sessions can be configured to start automatically via /config settings
The tmux workaround is the most practical mitigation for the terminal requirement. Wrapping the terminal in a persistent tmux session (tmux new -s claude-rc) means the terminal process survives even if the terminal application closes or the window crashes. Reconnect with tmux attach -t claude-rc from any terminal on the same machine.
The research preview designation is accurate rather than promotional. At launch, Pro plan access was staggered behind Max, and multiple documented issues in the official Claude Code repository confirmed that Pro accounts received access errors even when official documentation listed Pro as supported. Rate-limit reconnection failures represented a separate class of documented bug. As of this writing, Pro access has expanded but the rollout has not been without friction.
Remote Control shipped the same week as Cursor's cloud agents, and the two products take opposite architectural directions entirely. Cursor can run 10 to 20 cloud agents simultaneously, each operating inside its own remote virtual machine with its own isolated environment. Remote Control is a single-thread model: one active remote session per Claude Code instance, running on the developer's own hardware. The launch timing makes the wager explicit: local execution as a durable value rather than a transitional state.
Neither approach is universally correct. Cloud agent parallelism is genuinely valuable for autonomous tasks against codebases that are already on cloud infrastructure or easily cloned there. Local-first execution is genuinely valuable when the project depends on a configured environment: custom MCP servers, proprietary toolchains, locally stored credentials, CLAUDE.md configurations that encode months of team context, development certificates, or databases that cannot be replicated in a cloud VM for compliance reasons. Claude Code on the Web, a separate Anthropic product that does run sessions on cloud VMs, serves the former case. Remote Control serves the latter.
The business context makes the enterprise availability gap more interesting than it first appears. By February 2026, Claude Code's annualized run rate had exceeded $2.5 billion, more than doubling since the start of the year, with 4% of all public GitHub commits worldwide attributed to Claude Code and enterprise customers representing over half of all Claude Code revenue. The customers with the strictest data residency requirements and the most complex configured environments, exactly the customers who would benefit most from guaranteed local execution, are the same customers currently excluded from Remote Control. The feature is available as a research preview on Max and Pro plans only; Team and Enterprise plans do not currently have access.
There is no announced timeline for Team and Enterprise availability. Given that enterprise now accounts for the majority of Claude Code revenue and Anthropic closed a $30 billion Series G round at a $380 billion post-money valuation in the same period, broader availability seems probable over the medium term. But it remains unconfirmed.
What the current state reveals about the architecture: Remote Control requires Anthropic to manage a relay that routes authenticated sessions at scale. Extending that infrastructure to enterprise plans involves trust architecture, audit logging, and data handling commitments that differ meaningfully from individual developer accounts. The availability sequence, Max, then Pro, then presumably Team and Enterprise, maps to increasing complexity in the authenticated relay requirements, not to arbitrary rollout ordering.
The local-first philosophy extends across Anthropic's product line. Claude Cowork, the desktop tool for non-developer file and task management, follows the same principle: automation runs on the user's machine rather than requiring cloud migration of assets. Remote Control fits this pattern. Whether that architectural philosophy proves durable in a market where cloud-native parallelism has significant performance advantages depends on how many developers prioritize environment fidelity and data residency over the convenience of cloud-managed execution.
Does Anthropic store the messages that pass through the relay? The relay is stateless within a session, it functions as a message pipe rather than a data store. Anthropic's standard data handling policies apply to any content that flows through the API. If your organization has data residency or retention requirements, those requirements apply to the session traffic that moves through the relay, even though source code itself does not.
Can I use Remote Control while my laptop is asleep? Sleep mode is supported for brief periods. Brief lid closures (under approximately five minutes in testing) reconnect automatically in under ten seconds. Sustained network outage or deep sleep that exceeds approximately ten minutes terminates the session and requires restarting Remote Control from the local machine. Wrapping the terminal in a tmux session mitigates the terminal-exit risk but does not extend the network timeout window.
Is Remote Control the same as Claude Code on the Web? They are separate products. Claude Code on the Web runs sessions on Anthropic-managed cloud VMs with sandboxed environments, credential proxying, and automatic cleanup. Remote Control preserves your existing local environment (MCP servers, filesystem, toolchains, configurations) by keeping execution on your machine. Use Remote Control when the project depends on a configured local environment; use Claude Code on the Web for quick tasks against repos accessible from a fresh cloud environment.
Why can't I use Remote Control with an API key? Remote Control requires a claude.ai authenticated account (Pro or Max) because the relay connects to Anthropic's session infrastructure, which is tied to account identity rather than API credentials. API key access is designed for programmatic Claude integration, not for authenticated relay sessions.