Claude Code Remote: Every Way to Run It, Compared

"Claude Code remote" usually means one of two different things, and mixing them up is the most common source of confusion. Sometimes it means run the work on a machine you control, reached over SSH or a similar connection, so you get your own filesystem, your own MCP servers, and no sandbox limits. Other times it means run the work on Anthropic's own infrastructure, so you never have to think about a machine at all. Both are legitimate, and as of this writing there are real, current options for each. This guide walks through them honestly, including where each one falls short.

The two categories, and why they are not the same thing

Every way to run Claude Code away from your desk falls into one of two buckets: it either executes on a machine you control, or it executes on cloud infrastructure Anthropic manages. That single distinction decides almost everything else about a given approach: whether your local MCP servers and credentials are available, whether the work keeps running when your machine is off, and who is responsible for uptime.

• Your own machine. SSH plus tmux or screen, Remote Control, and VS Code Remote-SSH all fall here. The work runs on hardware you own or rent, so it has your full local environment, but it only keeps running while that machine stays powered on and reachable.
• Anthropic's cloud. Claude Code on the web (claude.ai/code) falls here. Sessions run on Anthropic-managed virtual machines, persist even if you close your laptop, and need no server of your own, at the cost of working inside a sandboxed cloud environment rather than your actual machine.

SSH into an always-on box, with tmux or screen

This is the original pattern and still the most flexible one. You SSH into a box, whether that is a Mac mini on your desk or a cheap VPS, and run Claude Code inside a terminal multiplexer like tmux or screen instead of directly in the raw SSH session. The multiplexer keeps the process alive independent of the connection: detach with a key combo, close the laptop, and reattach later from any device with an SSH client, exactly where you left off.

The trade you are making is that you now own the operations. The box has to stay powered and network-reachable, you are responsible for its security hardening, and there is no built-in mechanism for auto-resuming a session that hits a usage wall while you are away. Nothing here is Claude Code specific: tmux and screen are decades-old Unix tools, and the pattern works identically whether the remote box is a VPS, a Mac mini, or a spare desktop.

Claude Code on the web

Claude Code on the web runs tasks on Anthropic-managed cloud infrastructure at claude.ai/code. You can kick off a cloud session from your terminal with the --cloud flag, from the browser directly, or from the Claude mobile app, and the session keeps running even after you close whatever started it. It is a genuinely good fit for work on a repo you do not have checked out locally, for running several tasks in parallel, or for starting something and checking back later without owning any infrastructure.

The trade-offs are the mirror image of the SSH approach. A cloud session is isolated in its own virtual machine, so it does not see your local filesystem, your locally configured MCP servers, or credentials you have not explicitly given it. Repository access generally goes through GitHub (a local repository can be uploaded directly as a fallback, with size limits); rate limits are shared with the rest of your Claude usage; and eligibility and exact limits depend on your plan and can change, so check Anthropic's own documentation for the current details before you rely on it for something important.

Remote Control: steer a session on your own machine, from anywhere

Remote Control is a third option that is easy to confuse with Claude Code on the web because both use the same claude.ai/code interface, but it works the opposite way. You start it on your own machine (claude remote-control, or the --remote-control flag, or /remote-control inside a running session), and it connects that local session to your phone or a browser on another device. Execution and filesystem access stay on your machine the entire time; the web or mobile client is only a window into it, and you can send images or files from your phone straight into the session as if you had dropped them in the terminal.

Because the work is still local, Remote Control has the exact same requirement as SSH and tmux: the process has to keep running on your machine. If your laptop sleeps or the network drops briefly, a Remote Control session reconnects automatically once it is back; beyond a sustained outage of roughly ten minutes, the session times out and you have to start a new one. That makes it a natural pairing with an always-on box rather than a laptop you carry around and close.

VS Code Remote-SSH driving Claude Code

If your workflow is editor-centric, VS Code's Remote-SSH extension connects your local editor window to a remote box over SSH, and the Claude Code VS Code extension runs there too, giving you inline diffs and full project context while the actual execution happens on the remote host. It is the same underlying SSH connection as the terminal approach, wrapped in an editor experience, and it benefits from the same tmux pairing: start Claude Code inside a multiplexed session on the remote box so a dropped VS Code connection does not kill the run.

What about your phone?

All three of the machine-side options above (SSH, Remote Control, and VS Code Remote-SSH) can be driven from a phone with the right client, and Claude Code on the web is reachable from the Claude mobile app directly. Typing long prompts on a phone keyboard is genuinely the limiting factor, not the connection. See our dedicated guide to Claude Code on your phone for what actually works on a small screen and what does not.

Comparing the options

Which one should you actually use

If you do not want to think about a server at all, start with Claude Code on the web. If you need your own MCP servers, your own credentials, or work that touches files outside any repository, you need a box, and the only question left is whether you reach it with raw SSH and tmux, with Remote Control for phone access, or with VS Code Remote-SSH for an editor-first flow. Most people who reach for their own box end up using more than one of these at different times: tmux for the long unattended run, Remote Control to check in from a phone, VS Code Remote-SSH when they actually want to read a diff properly.

Whichever you pick, the box itself needs to actually stay on, stay reachable, and survive a reboot without losing the running session. See our guide to turning a Mac mini into a Claude Code server for the specifics of getting that part right.

Security basics that apply to every option

A handful of practices apply no matter which method you choose:

• Key-only SSH authentication. Disable password login for SSH entirely and authenticate with a key pair instead.
• Prefer a mesh VPN to an open port. Tailscale or WireGuard gives a box a stable, private address reachable from anywhere, without forwarding a port on your router or exposing SSH to the public internet.
• Least privilege. Run the agent under a dedicated account rather than an administrator account, and scope its credentials to only what it needs.
• Keep the box updated. Operating system and security patches matter more, not less, on a machine that is reachable around the clock.

Frequently asked questions