Keep Claude Code Running After SSH Disconnects: A tmux Recipe

The agent is working on your server. You close the laptop. When you return, there is no process to return to.

We received exactly this request: persistent remote sessions that survive a client disconnect, so the user can continue from another machine. Our SSH launch already ran the CLI on the host. That was insufficient: the process still depended on the interactive SSH terminal.

We shipped the change in AgentsRoom 1.198.0. Here is the manual recipe first, then what the app does with it. The same lifecycle issue applies to Claude Code, Codex and other interactive coding CLIs.

The terminal needs to outlive the connection

Our ordinary remote launch used an SSH channel with a terminal attached. If that channel disappears, the host can send a hangup signal and the agent dies. A process being remote does not by itself make it persistent.

tmux gives the process a terminal that lives on the host independently of the viewer. Its getting-started guide describes this exact use: protecting remote programs from connection drops and accessing them from another computer.

This is about keeping a process alive. For the broader choice between cloud sessions, a phone remote and your own server, read the three meanings of remote agents.

Start tmux before the agent

On a Unix-like host, connect with your usual SSH alias. Replace the repository path with yours:

ssh my-server
tmux -V
tmux new-session -s coding
cd ~/projects/my-repo
claude

For Codex, use codex in the last line instead. The CLI needs to be installed and signed in on the server. Start with a repository you can afford to experiment on.

Detach with Ctrl+B, then D. Reconnect later:

ssh my-server
tmux list-sessions
tmux attach-session -t coding

The tmux manual documents detach and attach. Reattachment returns to the live terminal. It does not send the task again or launch another agent.

Check the lifecycle before giving it real work

You can check the recipe without consuming an agent quota. Inside the new tmux session, run this finite command instead of a CLI:

python3 -u -c 'import time; [(print(i, flush=True), time.sleep(1)) for i in range(60)]'

Detach, disconnect SSH and attach again within a minute. The numbers should have advanced while you were away. This is a procedure for your host, not a benchmark we ran across every server configuration.

Next, try a short agent task. After reconnecting, check the files it changed and whether it needs an answer. A session can survive while the agent waits at a permission prompt. Keeping it alive does not make it autonomous.

What we changed in AgentsRoom

Open the saved SSH connection and enable Keep agents running on this host when AgentsRoom closes. It is off by default. The host needs tmux 3.0 or later.

Now open a remote project and launch an agent there. The CLI runs inside a named tmux session on the host. Quitting AgentsRoom, sleeping the laptop or losing the connection leaves that session alone. Opening the same saved agent again attaches to it, including from another computer on your account.

We made four implementation choices because each one changes what a user experiences:

• The session name follows the agent identity. Reopening that agent finds its process; a new agent gets a new session.
• The app uses a separate tmux server and skips your personal tmux configuration. It does not rearrange the sessions you manage by hand.
• The tmux prefix is disabled inside the app. Ctrl+B remains available to the coding CLI, and Escape reaches it without tmux's usual delay.
• An explicit agent restart replaces the remote process. Quitting the app detaches its viewer. Those gestures must have different effects.

The last distinction matters most. Closing the agent tab is not the way to leave it working. Quit the app or disconnect the viewer. If you explicitly close or restart the agent, AgentsRoom attempts to stop the remote session too; if the host is unreachable, it cannot guarantee that stop.

If tmux is absent or too old, the app launches as it did before. Do not assume the checkbox alone proves persistence: check the host and do the disconnect exercise. These details were checked against the published implementation on 7 October 2026.

Where nohup and Mosh fit

nohup makes a command ignore hangup signals, as its manual explains. It does not give you an interactive terminal to attach to later. It suits a batch command with redirected input and output better than an agent that may ask a question.

Mosh handles intermittent connections and changes of network. Its documentation also warns that it synchronizes the visible screen rather than complete scrollback. It can be used with tmux; keeping a session available after deliberately exiting the client is a separate concern from roaming between networks.

What persistence does not solve

The host still has to stay on. A reboot ends its live processes. A quota limit, a CLI crash or a permission question can still stop progress. You reconnect to the current screen; the console history your other computer displayed is not promised to reappear in full.

Keep the work in files the next session can read: a short task note, the changes themselves and the verification result. A surviving terminal is useful. A task whose state exists only in that terminal is still fragile.

The remote-access page covers how to reach your agents. This recipe covers the next question: whether there is still an agent to reach after the connection goes away.

Questions

Does a coding agent on a server survive an SSH disconnect?

A plain interactive SSH terminal is not a persistence mechanism. Losing its terminal can stop the agent. Run it inside tmux on the server before disconnecting, then attach to that session again. The server must remain running, and the agent can still stop for its own reasons.

Can I reconnect from another computer?

Yes, connect to the same server as the same host user and attach to the named tmux session. In AgentsRoom, enable persistent sessions for the SSH connection, then open the same saved agent from another computer on your account. Starting a different agent creates a different session.

Is reconnecting the same as resuming a conversation?

No. Attaching to a live tmux session returns to a process that never stopped. Resuming a saved conversation launches a process that reads the CLI's history. A conversation file cannot restore a running command or a terminal process that has died.

Does closing AgentsRoom stop a persistent remote agent?

Quitting the app leaves it running when the SSH connection's persistent-session option is enabled and tmux 3.0 or later is available on the host. Explicitly closing or restarting the agent asks to stop or replace its process; an unreachable host cannot confirm that action. Without a supported tmux, the launch falls back to the ordinary SSH behavior.