Remote coding: the four patterns, and which one survives a dropped connection

The question that picks the pattern

Every remote setup answers three failure cases, and most people only think about the first one. What happens when the network drops? What happens when the client device goes away? What happens when the host sleeps?

Pattern one: SSH, tmux, and mosh

The oldest answer and still the most portable. You get a real shell on a real machine with your real toolchain, and every tool you already know works unchanged.

# on the host: a named session that outlives the SSH connection
ssh you@host
tmux new -s work
claude          # or codex, or whatever the agent is

# connection dies. reconnect and pick it up:
ssh you@host
tmux attach -t work

# roaming between wifi and cellular: mosh instead of ssh
mosh you@host -- tmux attach -t work

The three pieces do different jobs and are strongest together. tmux keeps the process alive when the connection dies. mosh keeps the interactive terminal usable across IP changes, which is what actually happens when you walk out of the building. Tailscale makes the host reachable without a public SSH port.

The limits are honest ones: it is a terminal, so no rendered diffs, no clickable file tree, and typing a long prompt on a phone keyboard through a mobile SSH client is genuinely unpleasant. See running Claude Code over SSH for the setup in detail.

Pattern two: cloud IDEs and Codespaces

Move the development machine into a datacentre and reach it with a browser or a thin local editor. GitHub Codespaces, Gitpod, and the browser IDEs bundled with several agent vendors all sit here.

What you gain: a machine that never sleeps, reproducible from a devcontainer definition, reachable from any browser including a locked-down one. What you lose is more specific than people expect.

• Untracked files. Anything not committed does not exist there. Local scratch scripts, .env files, and half-finished work stay behind.
• Local services. The database on your laptop, the VPN into staging, the hardware you were testing against.
• Latency on the inner loop. Fine for an agent run, noticeable when you are typing.
• Cost while idle. Most bill by the minute the machine is up, not the minute you use it. Set an aggressive idle timeout on day one.

Pattern three: cloud agents

You describe a task, a container spins up somewhere with a clone of the repository, an agent works, and a pull request appears. You were never connected to anything. Cursor background agents, Codex cloud tasks, and Claude Code on the web all work this way.

This is the pattern that made the phrase "remote coding" mean something new. There is no remote session to keep alive, because the unit of work is the run and the artifact is the PR. The trade is that the environment is not yours: it has whatever the setup script installed, no access to your VPN, and no knowledge of the local state that was never committed.

Pattern four: session continuity

The newest pattern and the one that fits how agent work actually behaves. The agent runs wherever it should, and every device you own is a client onto the same live run rather than a separate copy of it.

This matters because agent work is bursty in a way that human work is not. You start a twenty-minute run, walk away, and the interesting moment arrives while you are somewhere else. What you need at that moment is not a terminal, it is a decision: approve this plan, read this diff, kill this run, answer this question.

The catch is the one from the first section: a paired Mac that goes to sleep stops working, phone app or not. If you want a run that continues regardless, the host has to be something that stays awake.

Security, briefly and non-negotiably

Remote coding in the agent era exposes something categorically worse than a shell: a service that runs arbitrary commands inside your repositories, often with credentials attached. T3 Code’s own documentation puts it as plainly as anyone: bind to "a trusted private address, such as a Tailnet IP, instead of exposing the server broadly," and "treat pairing URLs and pairing tokens like passwords."

• No public bind. Never --host 0.0.0.0 on a machine with a public IP. Bind to loopback behind an SSH tunnel, or to a Tailnet address.
• Keys, not passwords. Disable password auth on SSH entirely and use keys with a passphrase.
• Treat pairing tokens as credentials. They usually grant session creation until revoked, which is equivalent to shell access.
• Scope the agent’s permissions. A remote surface multiplies the blast radius of an over-permissive allow list. See agent security.
• Assume the phone will be lost. Whatever the mobile client can approve, someone holding the unlocked phone can approve.

Questions people ask

Keep reading

Continue through Agentic coding with What is an agentic development environment? The ADE, defined properly.