Remote coding agents with SSH and tmux: surviving a closed laptop

You hand a long job to an agent, close your laptop, get on a train: the agent died with the session. The fix is old, sturdy, and needs no third-party service — SSH plus tmux. Here's the recipe, and the four details that separate "it survived" from "I can't find anything".

Why it dies

A command-line agent is a process attached to a terminal. Close the terminal, the app, or the lid: the terminal goes away, the process is dismissed, and the session is lost — often mid-edit. None of this is the agent's fault; it's how terminals work.

So the fix is to move the terminal, not the agent: it has to live on a machine that doesn't close, and your screen merely attaches to it.

The basic recipe

On any machine you can reach over SSH:

ssh -t my-server -- tmux new -A -s agent-claude claude

Three pieces, each one load-bearing:

• ssh -t — forces a real terminal on the server side; without it, full-screen agent interfaces render like confetti.
• tmux new -A -s <name> — creates the session if it doesn't exist, attaches to it if it does. That little -A is what turns the command into "open or resume".
• claude — the agent itself, now running inside tmux, safe from your connection ending.

Close the laptop: tmux keeps going on the server. Run the same command tomorrow from another Mac and you land back in the live session, scrollback included.

Detail 1 — The session name must be deterministic

This is the most common mistake. If the name contains a timestamp, a random id or a window number, -A never reattaches to anything: it creates one more session every time, and you accumulate ghost agents quietly eating your quota. A stable name derived from what you're opening (agent-claude, agent-codex) is enough — with a numeric suffix only when you deliberately want two of the same kind.

Detail 2 — Folder trust is set on the server

Most agents ask, the first time they run in a directory, whether they're allowed to work there. That answer is stored on the machine running the agent — the server, not your Mac. If you prepare nothing, your first remote session opens on a trust prompt instead of starting work. Writing the agent's config file on the host ahead of time saves that round-trip on every new server.

Detail 3 — Passwords are not to be stored

A tool offering to remember your SSH password "for convenience" is handing you a problem. The boring, safe posture: keys are handled by your SSH agent, and if SSH wants a passphrase it asks you, on screen, at that moment. Nothing kept, nothing to leak.

Same spirit: your ~/.ssh/config already holds your hosts, users and ports. A decent tool reads it as a source instead of making you retype everything — while ignoring wildcard blocks (Host *), whose options must never leak onto the next machine.

Detail 4 — Know whether the host answers, before offering it

Offering to open an agent on an unreachable machine produces a window that takes thirty seconds to fail. A short probe (BatchMode=yes, result cached for a minute) lets you grey out what doesn't answer. Useful nuance: "not probed yet" is not "unreachable" — only forbid what you actually saw fail.

What it changes day to day

Once the mechanism is in place, the way you work shifts more than you'd expect: you start a heavy migration before lunch, close everything, then reattach from the sofa or from your phone to read where it got to and unblock a question. Your agents are no longer bound to the lifetime of your GUI session — they're bound to the server's.