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

By Meffysto · updated October 4, 2026

You hand a long job to an agent, close the 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, the four details that separate "it survived" from "I can't find anything", and what to check when it doesn't work.

Why it dies

A command-line agent is a process attached to a terminal. Close the terminal, the app or the lid, and the terminal goes away, the process gets dismissed, and the session is lost, often halfway through an edit. It isn't the agent's fault. That'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 only attaches to it. That machine can be a rented server, a mini PC in a cupboard, or a desktop Mac that stays on.

The basic recipe

On any machine you can reach over SSH, with the agent installed and logged in:

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 and attaches to it if it does. That little -A is what turns the command into "open or resume".
claude is the agent itself, now running inside tmux and safe from your connection dropping.

Close the laptop and tmux keeps going on the server. Run the same command tomorrow from another Mac and you land back in the live session, history included. Swap claude for codex, gemini or any other CLI; the recipe doesn't change.

Detail 1: the session name must be stable

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 pile up ghost agents quietly eating your quota with nobody watching.

A stable name derived from what you're opening is enough. Fauconnier prefixes every remote session with fauconnier-: fauconnier-claude, then fauconnier-claude-2 if you deliberately want a second agent of the same CLI on the same machine. Asking again to "open a claude agent on falcon-prod" reattaches the existing session instead of creating another one.

Detail 2: folder trust lives on the server

Most agents ask, the first time they run in a folder, whether they're allowed to work there. That answer is stored on the machine running the agent, which means the server, not your Mac. Prepare nothing and your first remote session opens on a prompt instead of starting work, and anything you send meanwhile goes nowhere.

You can set that permission ahead of time in the agent's config on the host: hasTrustDialogAccepted for the folder in ~/.claude.json, trust_level in ~/.codex/config.toml. Fauconnier does it before the first launch, adding only that field, leaving it alone if it's already set, and never blocking the launch if the write fails. Worst case you get the prompt on screen, and one keypress answers it.

Detail 3: passwords don't get stored

A tool offering to remember your SSH password "for convenience" is handing you a problem. The boring, safe setup: your SSH agent holds the keys (ssh-add), and if SSH wants a passphrase, it asks you on screen, at that moment. Nothing kept, nothing to leak.

Same idea: your ~/.ssh/config already lists your hosts, users and ports. A decent tool reads it instead of making you type everything again, and skips wildcard blocks like Host *, which are rules, not machines.

Detail 4: know whether the host answers before offering it

Offering to open an agent on an unreachable machine gets you a window that takes thirty seconds to fail. A short non-interactive probe (BatchMode=yes, a few seconds of timeout) lets you grey out what doesn't answer.

Be careful what "greyed out" means. A non-interactive probe also fails when the key isn't loaded or a password is required. So greyed out means "not reachable without interaction", not "machine down". And "not probed yet" isn't "unreachable": only block what you've actually seen fail.

When it doesn't work: three questions, in order

Does the host answer without asking anything? Try ssh -o BatchMode=yes my-server true. If it fails, load your key (ssh-add) or connect once by hand to accept the host fingerprint.
Does the session still exist? ssh my-server tmux ls lists the live sessions. It's the most reliable information you'll get, straight from tmux.
Did you reattach, or recreate? If you see two sessions where you expected one, your name wasn't stable (detail 1).

Cleaning up

A tmux session doesn't die on its own; that's the whole point. The flip side: an agent you forgot three days ago is still running, and if there's a subscription behind it, it may still be using it. Get into the habit of a tmux ls now and then, and close what's finished with tmux kill-session -t <name>. With a common prefix for all your agents, cleanup takes a glance: everything starting with fauconnier- is yours, the rest belongs to something else.

What it changes day to day

Once it's in place, the way you work shifts more than you'd expect. You start a heavy migration before lunch, close everything, and reattach from the sofa or from your phone to see where it got to and answer a question. Your agents no longer depend on the lifetime of your desktop session, only on the server's.

The same trick works on your own Mac: if local agents run inside tmux too, your iPhone can attach to them. That's what the guide Claude Code from your iPhone covers.

Frequently asked questions

tmux or screen for a coding agent?

Both keep the session alive. tmux is more common today, and its new -A option (create or attach) makes the command idempotent, which prevents duplicate sessions.

Does the agent keep running if I close my Mac?

Yes if it runs on another machine inside tmux: closing the lid only cuts your connection. An agent running on the Mac itself stops with the Mac, unless the Mac stays awake and the agent runs in tmux.

Do I need to install the agent on the server?

Yes. The CLI (claude, codex, gemini…) has to be installed and logged in on the remote machine. Your Mac only displays the terminal.

How do I find a lost session?

Run ssh my-server tmux ls to list sessions, then reattach with tmux attach -t and the name. If it isn't listed, the agent wasn't running inside tmux.

Fauconnier does all of this for you. "Open a claude agent on falcon-prod" creates the window, brings up SSH, gives the tmux session a stable name, sets folder trust on the host and reads your machines from your ~/.ssh/config. No password is ever stored. And Perchoir, the free iPhone app, reattaches the very same sessions.

Discover Fauconnier