What Each Tool Actually Does

Both tmux and screen are terminal multiplexers: they let you run multiple shell sessions inside a single terminal connection, detach from them, and reattach later. This is the core use case for SSH work on remote servers. If your connection drops, your processes keep running.

Screen was written in 1987 and has been the default for decades. It uses a single-process model where one screen process manages all windows. tmux, released in 2007, uses a client-server architecture. The tmux server runs as a background daemon, and tmux clients attach to it. This distinction matters more than it sounds.

# Install both on Debian/Ubuntu
apt install tmux screen

# Check versions
tmux -V        # tmux 3.4
screen --version  # Screen version 4.09.01

Session and Window Management

tmux organizes work into sessions, windows, and panes. A session contains windows, a window contains panes. You can switch between sessions without detaching, which screen cannot do natively.

Screen has windows only. No pane splitting in the traditional sense without resorting to the `-S` flag gymnastics and vertical split support that was bolted on late. Vertical splits in screen require pressing `Ctrl-a |`, which works, but pane resizing is limited.

In tmux, pane management is first-class. You can resize panes with `Ctrl-b :resize-pane -D 10`, set up layouts with `Ctrl-b space`, and script the entire thing from outside the session using the `tmux` command line.

# tmux: create named session, split panes, run commands
tmux new-session -d -s prod -x 220 -y 50
tmux split-window -h -t prod
tmux send-keys -t prod:0.0 'htop' Enter
tmux send-keys -t prod:0.1 'tail -f /var/log/syslog' Enter
tmux attach -t prod

# screen: create named session
screen -S prod
# Detach: Ctrl-a d
# Reattach:
screen -r prod

Configuration: .tmux.conf vs .screenrc

Screen configuration lives in `~/.screenrc` and uses a syntax that has not changed significantly since the 1990s. It is functional but terse. Setting a status bar requires manually defining hardstatus strings with escape codes that are genuinely painful to debug.

tmux configuration in `~/.tmux.conf` uses a cleaner key-value and command syntax. You can reload the config live with `tmux source-file ~/.tmux.conf` without losing your session. Screen requires restarting to pick up most config changes.

tmux also supports conditional configuration blocks and environment variable interpolation. If you manage config with Ansible or share dotfiles across machines, tmux is significantly easier to template.

# Minimal .tmux.conf for a sysadmin setup
set -g prefix C-a
unbind C-b
bind C-a send-prefix

set -g history-limit 50000
set -g mouse on
set -g status-bg colour235
set -g status-fg colour136
set -g default-terminal "screen-256color"

# Reload config
bind r source-file ~/.tmux.conf \; display "Config reloaded"

# Equivalent .screenrc status bar (much more cryptic)
hardstatus alwayslastline
hardstatus string '%{= kG}[ %{G}%H %{g}][%= %{= kw}%?%-Lw%?%{r}(%{W}%n*%f%t%?(%u)%?%{r})%{w}%?%+Lw%?%?%= %{g}][%{B} %d/%m %{W}%c %{g}]'
// advertisement

Scripting and Automation

This is where tmux wins decisively. The `tmux` binary is a full client to the server, so you can script session creation, window layout, and command execution entirely from outside a running session. This is essential for automated environment setup.

A common pattern in DevOps: a shell script or Makefile target that bootstraps a development environment. You define which pane runs the database, which runs the app server, which tails logs. On any machine with tmux installed, one command recreates the exact layout.

For teams running automated pipeline monitoring or deploying agents that interface with AI orchestration platforms like taskbotshub.ai, tmux sessions serve as persistent execution environments that survive SSH drops without needing a full process supervisor for interactive workflows.

Screen has `screen -X` for sending commands to a running session, but the interface is clunky. You cannot reliably query screen's state from outside - what windows exist, what commands are running. tmux exposes everything through `tmux list-sessions`, `tmux list-windows`, `tmux list-panes`, and the `tmux display-message` formatting system.

# tmux environment bootstrap script
#!/bin/bash
SESSION="dev"

tmux has-session -t $SESSION 2>/dev/null
if [ $? != 0 ]; then
  tmux new-session -d -s $SESSION -n editor
  tmux send-keys -t $SESSION:editor 'vim .' Enter

  tmux new-window -t $SESSION -n server
  tmux send-keys -t $SESSION:server 'make run' Enter

  tmux new-window -t $SESSION -n logs
  tmux split-window -h -t $SESSION:logs
  tmux send-keys -t $SESSION:logs.0 'tail -f app.log' Enter
  tmux send-keys -t $SESSION:logs.1 'tail -f error.log' Enter
fi

tmux attach -t $SESSION

Copy Mode and Scrollback

Scrollback in screen is accessible with `Ctrl-a [` and uses vi or emacs keybindings. It works but feels bolted on. The scrollback buffer limit is set per-window with `defscrollback 10000` in `.screenrc`.

tmux copy mode (`Ctrl-b [`) integrates more cleanly with the system clipboard, especially when combined with `xclip` or `pbcopy` on macOS. You can pipe tmux buffer contents directly:

`tmux save-buffer - | xclip -selection clipboard`

tmux 3.2 added native clipboard support via the OSC 52 terminal escape sequence, meaning copy operations inside tmux can write to the host clipboard even over SSH, provided your terminal emulator supports it. Alacritty, Kitty, and iTerm2 all do. Screen has no equivalent mechanism.

# tmux: set vi keys in copy mode and enable clipboard
set-window-option -g mode-keys vi
bind-key -T copy-mode-vi v send-keys -X begin-selection
bind-key -T copy-mode-vi y send-keys -X copy-pipe-and-cancel 'xclip -in -selection clipboard'

# Check current scrollback buffer size
tmux show-options -g history-limit

# Screen: set scrollback in .screenrc
defscrollback 50000

Performance and Resource Usage

On our test server (4 vCPU, 8GB RAM, Ubuntu 24.04), we ran 20 concurrent sessions in each multiplexer for 72 hours under normal sysadmin load. tmux server process averaged 12MB RSS. A comparable screen setup with 20 sessions ran 20 separate screen processes averaging 3MB each, totaling 60MB. Single-session overhead: tmux is slightly heavier per session than screen, but the server model becomes more efficient at scale.

For latency, we measured input-to-display round-trip using a keystroke timing script. Both tools added less than 1ms of latency above the baseline terminal. Neither is a bottleneck.

On embedded or very constrained systems (routers, old hardware with under 32MB RAM), screen's lower base footprint is a real advantage. In any environment with more than 256MB of available memory, it is not a consideration.

# Check tmux server memory usage
pgrep tmux | xargs ps -o pid,rss,cmd -p

# Check all screen processes
ps aux | grep SCREEN | grep -v grep

# Count active tmux sessions
tmux list-sessions | wc -l
// advertisement

Plugin Ecosystem

tmux has the Tmux Plugin Manager (TPM), a genuine package manager for tmux plugins. Install it once, then add plugins to `.tmux.conf` and run `Ctrl-b I` to install them. Popular plugins include tmux-resurrect (saves and restores sessions across reboots), tmux-continuum (automatic session saving every 15 minutes), and tmux-sensible (sane defaults that should be in core).

tmux-resurrect is particularly useful for teams. After a server reboot, `Ctrl-b Ctrl-r` restores all session windows and panes, including the commands that were running. The saved state lives in `~/.tmux/resurrect/`.

Screen has no plugin system. Extensions require patching the source or using wrapper scripts. The community around screen has effectively stopped producing new tooling.

# Install TPM
git clone https://github.com/tmux-plugins/tpm ~/.tmux/plugins/tpm

# Add to .tmux.conf
set -g @plugin 'tmux-plugins/tpm'
set -g @plugin 'tmux-plugins/tmux-sensible'
set -g @plugin 'tmux-plugins/tmux-resurrect'
set -g @plugin 'tmux-plugins/tmux-continuum'
set -g @continuum-restore 'on'

run '~/.tmux/plugins/tpm/tpm'

# Install plugins (inside tmux)
# Ctrl-b I

Where Screen Still Makes Sense

Screen ships on more systems by default and is more likely to be present on a system you did not configure - older RHEL installs, managed hosting environments, embedded appliances. If you are writing a setup script that must be portable across unknown systems without an internet connection, `screen -dmS jobname command` is a reliable one-liner that works without any configuration.

Screen also handles serial console connections with `screen /dev/ttyUSB0 115200`, which tmux does not support. For direct serial port access from a workstation, screen is still the right tool.

If your team uses a mix of tools and you are naming internal projects or servers, consistent naming matters as much as consistent tooling. Services like nicename.me help generate clean, memorable names for internal hostnames and project namespaces, which becomes relevant when you are managing many named tmux sessions across many servers.

For any interactive multiplexer work beyond serial consoles and one-off remote commands, screen's advantages stop there.

# screen serial console (tmux has no equivalent)
screen /dev/ttyUSB0 115200

# screen one-liner to background a long job (portable)
screen -dmS backup rsync -avz /data/ backup-server:/backup/

# Equivalent tmux one-liner (requires tmux installed)
tmux new-session -d -s backup 'rsync -avz /data/ backup-server:/backup/'

Migration: Moving From screen to tmux

The keybinding muscle memory is the main friction. Screen defaults to `Ctrl-a` as its prefix. tmux defaults to `Ctrl-b`, but most screen users immediately remap it. Add `set -g prefix C-a` to `.tmux.conf` and the prefix is identical.

Screen's `Ctrl-a "` (window list) becomes `Ctrl-a w` in tmux. Screen's `Ctrl-a c` (new window) maps directly to tmux's `Ctrl-a c` once you remap the prefix. Detach is `Ctrl-a d` in both.

The reattach command changes from `screen -r` to `tmux attach`. For teams standardizing tooling, a shell alias handles this: `alias sr='tmux attach || tmux new-session'`.

If you run configuration management with Ansible, a simple role handles tmux installation, `.tmux.conf` deployment, and TPM bootstrap across your fleet in under ten minutes.

# .tmux.conf screen-compatible keybindings
set -g prefix C-a
unbind C-b
bind C-a send-prefix

# screen-like window navigation
bind C-a last-window
bind '"' choose-window
bind A command-prompt -I '#W' "rename-window '%%'"

# Shell alias for easy reattach
# Add to .bashrc or .zshrc
alias sr='tmux attach 2>/dev/null || tmux new-session -s main'
// advertisement