Keep Remote Shells Alive With Tmux Named Sessions

The problem: a dropped SSH connection kills your build

You start a long-running deployment or database migration over SSH, step away for coffee, and return to a frozen terminal. The network blip closes your SSH connection, and the shell—along with every process inside it—receives a hangup signal and stops. You lose output, progress, and context.

The useful takeaway: tmux separates the terminal emulator from the shell process. The tmux server keeps running after your client disconnects, so you can detach from a session, close your laptop, and reattach later to find everything exactly as you left it.

How tmux keeps processes alive

Tmux uses a client-server model. The tmux server is a background process that owns sessions, windows, and panes. Your terminal emulator runs a tmux client that connects to that server. When you close the terminal or lose your SSH connection, the client disappears, but the server and the shell processes inside it keep running.

A session is a named container for one or more windows. Naming a session makes it easy to find and reattach to later, especially when you manage several projects on the same host.

Start, detach, and reattach a named session

Run these commands on the remote host over SSH. You do not need root or sudo; a regular user account can start and manage its own tmux server.

1. Create a named session:

tmux new-session -s deploy

Replace deploy with a short, descriptive name such as build-main or db-migration. This starts a new shell inside the session.

1. Run a long-running command:

npm run build

Or any command that should survive a disconnect, such as a migration script or log tail.

1. Detach without stopping the process:

Ctrl-b d

Press the Ctrl-b prefix, then release and press d. The client detaches, but npm run build keeps running inside the server.

1. Verify the session still exists from a new connection:

tmux ls

Expected output includes your named session, for example:

deploy: 1 windows (created Tue Nov 11 08:45:00 2026)

Do not treat this as guaranteed output; the timestamp and window count depend on your actual session.

1. Reattach to the session:

tmux attach-session -t deploy

Your terminal returns to the exact state you left, including the running build and its output. If the build finished, you see its final output and the shell prompt.

Risks and checks

• If the tmux server process stops—such as after a host reboot—all sessions end. There is no built-in recovery across reboots.
• If you forget to detach and simply close the terminal, the session remains associated with the disconnected client until the server cleans it up, but reattaching still works.
• Check that tmux is installed before relying on it: which tmux should return a path such as /usr/bin/tmux.

Limitation: shared sessions resize to the smallest terminal

Tmux allows multiple clients to attach to the same session at once, which is useful for pairing or observing a colleague's terminal. However, by default all clients share the same window size, and the display is often constrained by the smallest terminal window. If you attach from a large monitor and a colleague attaches from a small laptop, both views may shrink to fit the laptop.

Practical check: run tmux list-clients -t deploy to see how many clients are attached. If you need independent window sizes, use separate sessions or accept the shared-layout trade-off.

Closing: make named sessions a default habit

For remote development, start a named tmux session as soon as you connect over SSH. Use a consistent naming scheme so you can find the right context after a disconnect. Detach when you step away, and reattach when you return. Verify with tmux ls before assuming a session survived, and remember that a server reboot clears the state unless you set up separate persistence outside tmux.