Never Lose an SSH Session Again: Tmux Workflows for Remote Development

It's a familiar story. You're six hours into a long-running build on a remote server, your laptop sleeps on the train, and when you open it again the SSH connection is dead. The build died with it. You're back to square one.

Or worse: you're editing a config file over SSH, your wifi drops in an elevator, and your unsaved work vanishes because the shell that owned it was killed the moment the connection closed.

The root cause is simple. An SSH session is tied to your connection. When the connection ends, the shell on the server receives a hangup signal (SIGHUP) and every process in it — your editor, your build, your database migration — gets terminated.

Tmux fixes this by decoupling your shell from your connection. It runs a persistent server on the remote host. Your SSH session becomes just a viewport into that server. Disconnect, reconnect, switch machines, log in from your phone — the shell on the server never notices.

Why Not Just nohup or screen?

You may have seen people reach for nohup long-running-command & or the older screen utility. They work, but they're partial solutions.

• nohup detaches a single process. It doesn't give you a shell you can reattach to, and you can't interact with the process once it's running.
• screen does multiplexing and persistence, but its keybindings are clunky, its configuration language is awkward, and development has slowed to a crawl.
• Tmux is a modern, actively maintained terminal multiplexer with a clean plugin ecosystem, scriptable configuration, and split panes that actually work.

If you're starting from scratch, learn tmux. It's the industry standard for a reason.

The Mental Model: Sessions, Windows, Panes

Tmux has a three-level hierarchy that takes ten minutes to learn and years to master:

• Session — a persistent workspace on the server. This is what survives disconnection. You can have multiple sessions, each for a different project or context.
• Window — like a tab in a browser. A session contains one or more windows, usually one per logical task (editing, logs, database).
• Pane — a split within a window. Split a window vertically or horizontally to see your editor and your test runner side by side.

The key insight: when your SSH connection drops, only the viewport dies. The session, its windows, and its panes keep running on the server.

The Commands You'll Actually Use

You don't need to learn tmux all at once. These eight commands cover 95% of everyday use:

# Create a new session named "deploy"
tmux new -s deploy

# Detach from the session (it keeps running in the background)
# Press: Ctrl+b then d

# List all running sessions
tmux ls

# Reattach to a session
tmux attach -t deploy

# Kill a session you no longer need
tmux kill-session -t deploy

# Rename a session
tmux rename-session -t 0 work

Inside a tmux session, the prefix key (default Ctrl+b) unlocks all the other commands:

Shortcut	Action
Ctrl+b d	Detach (leave session running)
Ctrl+b c	Create a new window
Ctrl+b n / Ctrl+b p	Next / previous window
Ctrl+b %	Split pane vertically
Ctrl+b "	Split pane horizontally
Ctrl+b o	Jump to next pane
Ctrl+b [	Enter scrollback mode (use arrow keys, q to exit)

The scrollback mode deserves special mention. Without tmux, if output scrolls past the top of your terminal, it's gone. With tmux, you can scroll back through thousands of lines of history regardless of your local terminal's buffer settings.

A Real Remote Development Workflow

Here's how a typical day with tmux looks:

Morning, on your workstation:

ssh your-server
tmux new -s project-alpha
# You're now in tmux. Open three windows:
# Window 0: vim on the application code
# Window 1: tail -f logs/application.log
# Window 2: npm run dev
# Detach: Ctrl+b d
exit

Midday, laptop goes home, VPN drops, you close the lid. Everything on the server keeps running. The dev server hasn't restarted. The log stream hasn't stopped.

Evening, on your home machine or phone:

ssh your-server
tmux attach -t project-alpha
# You're right back where you were.

This is the magic. You move between networks, machines, and timezones, and your remote work follows you.

Configuration Worth Doing on Day One

The default tmux configuration works, but these tweaks make it feel native. Create ~/.tmux.conf on your server:

# Reject the escape delay (feels laggy otherwise)
set -sg escape-time 0

# Enable mouse: scroll, click to switch panes, resize
set -g mouse on

# 256-color support
set -g default-terminal "tmux-256color"

# Larger scrollback
set -g history-limit 50000

# Reload config without restarting tmux
bind r source-file ~/.tmux.conf \; display "Reloaded!"

The mouse support is a game changer for people coming from graphical terminals. You can scroll through panes, click between them, and drag borders to resize — no keybinding gymnastics required.

Tmux and SSH Keepalives Are Complements, Not Replacements

If you've read our earlier article on SSH keepalives, you might wonder why you need tmux at all. They solve different problems:

• Keepalives (server-side ClientAliveInterval and client-side ServerAliveInterval) prevent idle connections from being silently dropped by firewalls and NAT gateways. They reduce how often you get disconnected.
• Tmux ensures that when you do get disconnected, your work survives anyway.

You want both. Keepalives reduce disconnects; tmux makes them harmless.

Handling the "Binary Not Found" Problem

Most servers have tmux installed, but minimal containers and slim Docker images often don't. If you get tmux: command not found:

# Debian / Ubuntu
sudo apt install tmux

# RHEL / Fedora / Rocky
sudo dnf install tmux

# Alpine
sudo apk add tmux

For environments where you can't install packages, you can often extract a static tmux binary into your home directory and add it to your PATH.

Tmux and FoxTerm

FoxTerm's SSH terminal runs on the Ghostty engine and supports all standard terminal features, which means tmux works out of the box. Detach with Ctrl+b d, close the tab, reconnect later — the session is waiting on the server. FoxTerm's integrated system-monitoring sidebar shows the remote host's CPU, memory, and network usage in real time, so you can watch your long-running build without opening a second connection.

The Habit That Changes Everything

The single most important habit: always start work inside a named tmux session. Not tmux new (which assigns a number), but tmux new -s descriptive-name. When you come back later and run tmux ls, you'll see a list of meaningful labels instead of a mystery numbered list of sessions you don't remember creating.

Once this becomes automatic, you'll stop thinking about disconnections. They just stop mattering. Your shell lives on the server, your connection is disposable, and your work survives whatever the network does to it.