blog

You ssh into a server, start Claude Code on a long refactor, and the train goes into a tunnel. When you get the connection back the agent is gone and so is everything it had in its head. Here is what killed it, what each of the usual fixes actually fixes, and the one thing none of them do.

What actually kills it

Not the network. When your ssh connection drops, the server tears down the pseudo-terminal it gave you, and the kernel sends SIGHUP to the foreground process group attached to it. Your login shell gets it, forwards it to its children, and Claude Code, which is one of those children, exits.

The word is literal: a hangup, from the days when the terminal was a modem and the phone line dropped. Everything below is a different answer to the same question, which is how to stop your agent being downstream of a phone line.

tmux: detach the process from the terminal

tmux starts a server on the remote machine and runs your shell inside it. Your ssh session attaches to that server rather than owning the processes, so when the connection drops, the pty that goes away is the one between you and tmux. The agent is on the far side of it and never hears the hangup.

• tmux new -s agent starts a named session. Run Claude Code inside it.
• Ctrl-b d detaches on purpose. A dropped connection does the same thing without asking.
• tmux attach -t agent from your next ssh session puts you back in front of the same run, scrollback included.

mosh: fix the connection, not the process

mosh replaces the ssh transport with one that survives an IP change and a sleeping client. Change wifi, close the laptop for an hour, open it on a tethered phone: the session is still there, because mosh is not holding a TCP connection open, it is resynchronising a screen over UDP.

What it does not give you is detach and reattach. There is one client per session, and if the server-side process ends, the session ends with it. This is why the two get used together rather than instead of each other: mosh for the link, tmux for the lifetime. mosh into the server, attach to tmux, and both classes of interruption are covered.

nohup, setsid, systemd-run: right idea, wrong shape

nohup claude ... makes the process ignore the hangup. setsid goes further and puts it in a new session with no controlling terminal at all. Both keep the process alive, and both are the wrong tool here for a reason that has nothing to do with signals: they take away stdin.

A build does not mind. A coding agent does. It stops and asks whether to overwrite the file, whether the plan is right, whether to run the migration. An agent backgrounded with no terminal asks that question into a log nobody is reading, and waits. You come back three hours later to a process that has been alive and idle for two hours and fifty minutes.

What none of them fix

Every option so far protects the process from the connection. Two things are still open, and with agents they are the ones that cost you the afternoon.

• The machine itself. tmux does not survive a reboot, an out-of-memory kill, or a host migration. Whatever the agent knew, and every line of scrollback you would have needed to reconstruct it, goes with the process.
• Knowing it needs you. An agent waiting for an answer looks exactly like an agent working hard, right up until you attach and read. tmux has no opinion about which one is happening and no way to tell you.

The option that skips the whole category

reachpad runs your agents on Linux workspaces where disk and memory are sealed to object storage. The connection dropping is not interesting, and neither is the machine going away: a paused workspace resumes mid-session rather than from a fresh boot, so the run you left is the run you get back.

• reachpad attach <id> is a terminal in the workspace. Ctrl-] detaches and leaves everything running.
• reachpad attach <id> --new opens a second terminal in the same workspace, so you can watch one agent from beside it instead of interrupting it.
• Status says which agents are waiting on you and which are working, so you answer the one that is blocked instead of attaching to all of them to find out.

1,000 one-time trial credits, 16 hours 40 minutes of active workspace time are shared across up to 10 workspaces, and there is no card. The quickstart is five steps, or the CLI page covers attach, run, forks and rewind in full.