SSH connections die — hotel WiFi, a sleeping laptop, a router having a moment. tmux keeps your shells, deploys, and long builds running server-side so reconnecting just picks up where you left off. Here's the sane setup and the gotchas that bite everyone exactly once.

Every operator has a scar story. Mine: a kernel upgrade on a production VPS, apt full-upgrade halfway through configuring grub, and then — silence. The café WiFi dropped. I reconnected to find the shell gone and dpkg in that special state where it refuses to do anything until you run dpkg --configure -a and pray.

The lesson wasn't "get better WiFi." It was: never run consequential work in a naked shell. tmux is the cheapest insurance policy in the Linux toolbox, and this is the playbook I wish someone had handed me before that afternoon.

What tmux actually does

tmux is a terminal multiplexer, but that phrase undersells it. The useful mental model: tmux runs a server process on the machine that holds your sessions, windows, and panes. Your terminal is just a client attached to it. When your SSH connection dies, the client dies — the server doesn't care. It keeps everything running exactly as it was.

Reconnect, reattach, and you're staring at the same prompt, the same half-finished rsync, the same log tail. The dropped connection becomes a non-event.

Install it first — it's in every distro's repos:

sudo apt install tmux        # Debian/Ubuntu
sudo dnf install tmux        # Fedora/RHEL
sudo pacman -S tmux          # Arch/CachyOS

The five minutes that matter

Start a named session for the work you're about to do:

tmux new -s deploy

Run your command. When you want to step away — or when the network forces you to — detach with Ctrl-b then d. (The prefix Ctrl-b is tmux's way of saying "the next key is for me, not the shell.")

Later, from anywhere:

tmux ls              # list sessions
tmux attach -t deploy  # reattach; "tmux a -t deploy" works too

That's the whole core loop. Everything else is refinement.

The config worth having

tmux works out of the box, but a small ~/.tmux.conf removes years of minor irritation. Here's mine, with a reason for every line:

# Mouse: click to select panes, scroll naturally, drag to resize
set -g mouse on

# Scrollback you can actually search: default is a measly 2000 lines
set -g history-limit 50000

# Keep window numbers tidy when you close one in the middle
set -g renumber-windows on

# Fix the infamous vim "laggy Esc" inside tmux
set -sg escape-time 10

# Proper 256-color support (tmux 3.2+)
set -g default-terminal "tmux-256color"

# Vi keys in copy mode, because your fingers already know them
setw -g mode-keys vi

Apply with tmux source-file ~/.tmux.conf, or just start a fresh session.

One deliberate non-choice: I keep the default Ctrl-b prefix. Half the internet remaps it to Ctrl-a, and I get the appeal — until you remember Ctrl-a is "jump to start of line" in every readline shell, which you press roughly four hundred times a day. Remapping steals a key you already use constantly. Ctrl-b is two keys you'll press rarely, and it never collides with anything. Boring wins.

Panes, windows, and the layout habit

Inside a session, you get windows (like tabs) and panes (splits inside a window). The keys that matter:

  • Ctrl-b c — new window
  • Ctrl-b n / Ctrl-b p — next / previous window
  • Ctrl-b % — split vertically
  • Ctrl-b " — split horizontally
  • Ctrl-b + arrow key — move between panes
  • Ctrl-b z — zoom pane to fullscreen (toggle)
  • Ctrl-b x — kill current pane
  • Ctrl-b , — rename window

My habit on a server: window 1 runs the actual work, window 2 tails the logs, window 3 is a scratch shell. Renamed windows (Ctrl-b ,) so tmux ls reads like a dashboard instead of a mystery.

Copy mode: your scrollback is searchable

This is the feature people sleep on. Press Ctrl-b [ and you're in copy mode — the pane freezes into a buffer you can navigate with vi keys (j/k, / to search, q to exit). On a remote server where you can't just scroll with a mouse, this is how you find the error line from three thousand lines ago without re-running anything.

With mouse on, scrolling with the wheel enters copy mode automatically. With mode-keys vi, /error then n walks you through matches. It becomes muscle memory within a day.

The gotchas that bite everyone once

1. Nested sessions: the double prefix. If you ssh from inside tmux into another machine and start tmux there, your Ctrl-b gets eaten by the outer session. Send it through with Ctrl-b Ctrl-b followed by the command. Honestly, the saner rule: run tmux on the remote only, not on both ends.

2. "no server running" doesn't mean tmux is broken. It means exactly what it says — no sessions exist, usually because you killed the last pane instead of detaching, or you're a different user (or under sudo) than the one that started the server. The attach-or-create idiom sidesteps the whole question:

tmux new -A -s main   # attach to "main" if it exists, create it if not

Make that your default reattach command.

3. Colors look wrong. If your carefully themed prompt renders as gray mush inside tmux, it's the TERM variable. The default-terminal "tmux-256color" line in the config fixes it for tmux 3.2+. Outside tmux, make sure your terminal emulator advertises a 256-color or truecolor term (xterm-256color, not plain xterm).

4. Esc feels sluggish in vim/nvim. tmux waits 500ms after Esc to distinguish it from an Alt key sequence. The escape-time 10 line kills the lag. If you use neovim, 10ms is plenty.

5. Detach, don't exit. Closing the last pane or typing exit in it kills the session — your safety net included. Build the detach habit (Ctrl-b d) for any session holding real work. Check what's alive with tmux ls before you log out for the night.

6. Set history-limit before you need it. Scrollback size is fixed when the pane is created. Bumping the config after a 40,000-line build already scrolled past won't bring those lines back. Set 50000 once and forget it.

The deploy pattern

Here's the shape this takes in real operations work:

tmux new -s upgrade
sudo apt update && sudo apt full-upgrade -y
# Ctrl-b d — go make coffee, lose WiFi, whatever
# later:
tmux attach -t upgrade

And for scripted starts, launch detached from the beginning:

tmux new -d -s backup 'restic -r /mnt/backups backup /srv/data'

The job runs inside a session you can attach to anytime to watch progress — no nohup, no redirecting output to a file you'll forget to check, no wondering whether the process survived your logout.

Cleanup is just as deliberate: tmux ls to see what's alive, tmux kill-session -t old-deploy for finished work, and tmux kill-server only when you mean "nuke everything" (you rarely do).

The boring superpower

tmux isn't exciting. It doesn't have a dashboard, a web UI, or an AI assistant. It's a thirty-year-old idea — your terminal session should outlive your connection to it — implemented so well you forget it's there. The café WiFi will drop again. The laptop will sleep mid-transfer. The difference is whether that costs you an afternoon or a keystroke.

tmux new -s deploy. Detach. Reconnect. That's the whole playbook — the rest is just making it comfortable.

Sources: tmux GitHub repository · tmux manual page · Arch Wiki: tmux