Steering agents from my phone: a terminal stack vs Claude Code Remote Control

I run long agent jobs on a host at home and want to steer them from my phone, from a train or a café, whatever network I am on. Anthropic now ships a built-in answer for this, Remote Control, which connects a phone or browser to a Claude Code session on your machine. In this note I examine why I still reach a terminal instead, and why I expect that choice to flip. My current setup is four ordinary tools, each doing one job.

The four-tool terminal stack

Tailscale gives the host a stable address I can reach from anywhere. It builds a mesh VPN (virtual private network) of direct encrypted tunnels between my devices, using STUN and ICE style hole punching to cross NAT (network address translation), and in its own words: “The private key never, ever leaves its node.” When a network blocks the direct path, traffic falls back to an encrypted relay, but the common case stays peer to peer.

mosh (mobile shell) handles the moving. It logs in over SSH, then runs its own server and connects over UDP (user datagram protocol), so the session survives what plain SSH cannot: “Mosh automatically roams as you move between Internet connections. Use Wi-Fi on the train, Ethernet in a hotel, and LTE on a beach: you’ll stay logged in.” I can sleep the phone and wake it an hour later with the session intact.

tmux keeps the work alive when every client is gone. Detached sessions “keep running in the background”, so the agent keeps working whether or not anything is attached. I have written about keeping orchestration on the lowest workable layer on its own; here it is the tmux orchestrator the other three reach.

Termux is the last piece, “an Android terminal application and Linux environment”, which is the keyboard and the screen. Nothing agent-specific runs on the phone; it is a plain TTY (teletypewriter) onto the mesh. Each layer is replaceable, and none of them knows what an agent is; that property is what keeps the stack tool-agnostic.

Remote Control and its limits

Remote Control is the more elegant idea. The local process makes outbound HTTPS requests only, never opens an inbound port, registers with the API and polls for work, so “nothing moves to the cloud” and typing @ autocompletes local file paths on the phone. For steering a session you left running it is less setup than anything I maintain: one command, a QR (quick response) code, done.

Three limits, taken from its own documentation, keep me on the terminal for now. (1) Commands that open an interactive picker, “such as /plugin or /resume, work only from the local CLI”, so part of my command surface is simply missing from the phone. (2) If the machine is awake but offline “for more than roughly 10 minutes, the session times out and the process exits”, which is exactly the failure a long unattended run has to survive. (3) It is gated to a claude.ai subscription on api.anthropic.com, with API keys and third-party endpoints unsupported, so it steers one vendor’s agent and not the others I run beside it.

The terminal’s advantages

In contrast, the terminal’s advantages are ordinary and, for my use, decisive. It is tool-agnostic: the same mesh steers a second agent running in the next pane as easily as the first, because it steers a shell rather than a product. It carries the complete command surface, every slash command and skill included, since it is the identical terminal I use at my desk. In addition, its persistence is owned by tmux and mosh rather than by a relay, so a run outlasts a tunnel that dropped for an hour, not one that dropped for ten minutes. Reaching all of that through a single vendor path, however, is not free; I rebuild reachability, persistence, and a mobile keyboard by hand on each new host.

Remote Control’s current advantages

I am not arguing against Remote Control. The vendor path already has what my stack cannot cheaply reach: push notifications when a “long-running task finishes or when it needs a decision” (Remote Control docs), a real mobile interface rather than a terminal viewed on a phone, device-level trust, and an active release cadence from the vendor. Once a pushed notification matters to me more than steering a second agent, I will move to Remote Control. On current trajectory, that is not far off.

TODO (2026-07): run a week with Remote Control as the only path to one host and count how often the missing picker commands and the 10-minute timeout actually cost me something, against how often a push notification saves a stalled run. The honest comparison is a measured one, and I have not measured it yet.