Running Claude Remote Control on an Always-On Machine

Remote Control runs as a process on your machine, so the machine has to stay awake and the process has to stay alive. That rules out closing your laptop lid and expecting the session to survive. It does not rule out a session that runs for days, as long as you put it somewhere that stays on.

The important distinction: Remote Control is not a hosted service. If you want Claude Code running without any machine of your own, that is Claude Code on the web, which executes in Anthropic’s infrastructure instead.

A machine you reach over SSH

This is the most common setup: a home server, a spare desktop, or a cloud VM that stays on. The catch is that closing your SSH connection normally kills whatever you started, Remote Control included. The fix is a terminal multiplexer.

tmux new -s claude
cd ~/projects/my-app
claude remote-control

Detach with Ctrl-b then d. The Remote Control session keeps running and stays reachable from your phone. Reattach later with tmux attach -t claude. screen works the same way if you prefer it.

Anthropic’s documentation names this explicitly as the way to keep a session running on a remote machine after you disconnect from SSH, so it is the supported pattern rather than a workaround.

What the machine actually needs

  • Outbound HTTPS on port 443. That is all. Remote Control never opens an inbound port, so you do not forward anything or touch your firewall’s inbound rules.
  • A claude.ai login. API keys are not supported, and neither are long-lived tokens from claude setup-token or CLAUDE_CODE_OAUTH_TOKEN. You authenticate with /login.
  • Workspace trust accepted in the project directory. Run claude there once first. Trust is never saved for your home directory, so start from a real project folder.
  • A direct path to api.anthropic.com. A corporate proxy or gateway set through ANTHROPIC_BASE_URL disables Remote Control from v2.1.196.

The login requirement is the one that catches people out on a headless box. /login is an interactive browser flow, so you need a way to complete it on that machine before Remote Control will start. Plan for that rather than discovering it mid-setup.

Hosting many sessions from one process

If the always-on machine is doing real work, server mode is a better fit than a pile of terminal windows. One process, many sessions, default capacity 32.

tmux new -s claude
cd ~/projects
claude remote-control --spawn worktree --capacity 6

--spawn worktree gives each on-demand session its own git worktree, so parallel sessions do not fight over the same files. The default, same-dir, shares one working directory and will conflict when two sessions edit the same file. Details in sessions.

The Desktop app as the host

The Claude Desktop app can host sessions too, and pairs with Dispatch so you can message a task from your phone and have Desktop spawn a session to handle it. If you keep a desktop machine on anyway, that is less setup than a VM.

One version note: from v2.1.207 Desktop-hosted sessions send subagent and workflow progress to connected devices. On earlier builds they did not, so a phone watching a Desktop session showed less than it should. See version compatibility.

What still ends the session

An always-on machine removes the most common cause, not all of them.

CauseSurvives on an always-on box?
You closed your laptopYes, the session is not on your laptop
SSH disconnectYes, if you used tmux or screen
The claude process was killedNo. The session is the process
Machine offline more than roughly 10 minutesNo. The session times out and exits
Machine rebootedNo. Restart Remote Control after boot

Because a reboot ends it, treat Remote Control as something you start deliberately rather than a daemon. There is no supported service mode.

A note on sandboxing

If the machine holds code you would rather Claude not touch freely, server mode accepts --sandbox to enable filesystem and network isolation. Sandboxing is off by default, and the flag is not available with the /remote-control slash command. Worth considering on a shared or long-lived box. See security.