Keeping Your Work Alive Across SSH Drops with tmux Detach and Reattach

The problem: losing work when a connection drops

You are debugging a remote server over SSH, have a long‑running build or log tail in a terminal, and the network hiccups. When the SSH client disconnects, the shell and everything running inside it vanish, forcing you to start over.

Thesis: tmux’s client‑server design lets you detach a session and reattach later, preserving state without keeping the SSH connection alive

By separating the UI (the client) from the session state (the server), tmux keeps your windows, panes, and running programs alive even after you log out. This works for a single user sharing a session across multiple terminals, for surviving intermittent network loss, and for scripting interactions via tmux send-keys.

How tmux achieves persistence

• The tmux server is a background process that owns all sessions, windows, and panes.
• Clients connect to the server through a Unix socket (typically under /tmp/tmux-*) to send commands and receive output.
• Detaching a client (Ctrl‑b d) tells the server to stop sending UI to that client, but the server continues to run the session.
• Another client can later reattach with tmux attach -t <session> (or simply tmux attach if there is only one session) and regain full control.

Worked example: detach, survive SSH drop, reattach

1. Start a named tmux session: tmux new -s work
2. Inside the session, launch a long‑running command, e.g., top or tail -f /var/log/syslog.
3. Detach cleanly: press Ctrl‑b then d. You return to your original shell; the tmux server remains running.
4. Log out of the SSH connection or close the terminal window.
5. Later, open a new terminal (or reconnect via SSH) and reattach: tmux attach -t work. You should see the same top or log tail still running, exactly as you left it.

You can verify that the server persisted by checking the socket and process:

# List tmux socket files (shows the server is alive)
ls -l /tmp/tmux-$(id -u)
# Confirm the server process
ps -ef | grep '[t]mux'

Trade‑offs and limitations

• Server loss kills sessions: If the tmux server process is terminated (e.g., pkill tmux), all attached sessions are lost unless you have a restoration plugin like tmux-resurrect that periodically saves state to disk.
• Nested sessions need prefix discipline: Running tmux inside tmux means each layer intercepts the prefix (Ctrl‑b) by default. To send a command to the inner session you must press the prefix twice (Ctrl‑b Ctrl‑b) or reconfigure prefixes to avoid confusion.
• Minimal performance overhead: The server merely forwards input/output; heavy computation stays in the client’s shell or programs, so latency is usually negligible.

Actionable closing: make detach/reattach part of your workflow

• Always start a tmux session at the beginning of a remote workday: tmux new -s $(date +%Y%m%d).
• Use a short, memorable session name or rely on the default (tmux attach) when you only need one session.
• If you work on multiple projects, create separate sessions (tmux new -s projA, tmux new -s projB) and switch with tmux switch -t projA.
• Consider adding a lightweight restoration plugin (tmux-resurrect) if you fear accidental server kills.
• Periodically verify the server is still running with the socket/process checks above, especially after system updates that might restart services.