tmux vs GNU Screen vs Zellij: Choosing a Terminal Multiplexer

Every terminal multiplexer solves the same two problems: your shell dies when the connection drops, and one terminal window only shows one thing at a time. A multiplexer puts a long-lived server process between your terminal emulator and your shells, so those shells survive a disconnect, and it carves one screen into several independently addressable terminals.

The three real options are GNU Screen, tmux, and Zellij. They overlap heavily — all three detach and reattach, all three do windows and splits — so the choice comes down to where you work, what is already installed there, and how much config you're willing to write. None of them is strictly better than the others, and this guide tries to say where each one actually wins.

## What persistence actually buys you

Before comparing feature lists, it's worth being precise about the thing all three do, because it's the only part that's non-negotiable:

• A long build, database migration, or rsync keeps running when your laptop sleeps or the VPN drops.
• You reattach from a different machine and land in the same working state — same scrollback, same directories, same running processes.
• One SSH connection carries several shells, so you stop opening five terminal tabs into the same box.
• Two people can attach to one session and watch the same terminal, which is the primitive most pairing setups are built on.

Everything else — status bars, layout files, plugins — is convenience stacked on top. Judge the tools on the convenience layer only after they clear the persistence bar, and all three clear it.

## GNU Screen: the incumbent

Screen predates the others by a wide margin, and that shows in both directions. It's small, it's stable, and it's sitting on an enormous number of machines you didn't provision: old enterprise Linux boxes, appliance shells, hardened images, embedded systems, anything whose package list was frozen years ago. When you SSH into a server you don't control and can't install to, screen is frequently the only multiplexer present, and that alone is reason enough to still know it.

screen -S deploy      # start a named session
# Ctrl-a d            detach, leave it running
screen -ls            # list sessions
screen -r deploy      # reattach
screen -x deploy      # attach alongside another client

Screen also owns serial consoles, which isn't a niche if you touch network gear or embedded hardware: screen /dev/ttyUSB0 115200 is still the shortest path to a serial terminal, and neither tmux nor Zellij competes there.

The weaknesses are equally real. Splits exist but are second-class — Screen splits the display into regions and then leaves it to you to put a window in the new region. There's no meaningful layout management, .screenrc syntax is idiosyncratic, and copy mode feels dated next to tmux's. Development is maintenance: portability and bug fixes, not new capability. Nobody is building an ecosystem on it, and that's unlikely to change.

## tmux: the default choice

tmux is what most people should learn. It runs a client/server model: a server process owns the sessions, clients attach to them, and every action available through a key binding is also a command you can issue from a plain shell. That symmetry between interactive use and scripting is the whole story of why tmux won.

tmux new -s work        # create a session named work
# Ctrl-b d              detach, everything keeps running
tmux ls                 # list sessions
tmux attach -t work     # reattach

Learn those four cold and pick up the rest as you need it. Ctrl-b % and Ctrl-b " split the current pane, Ctrl-b plus an arrow key moves between panes, Ctrl-b c opens a new window, and Ctrl-b z zooms a pane to full screen and back — that last one is the binding people wish they'd learned on day one.

The scripting surface is what you can't get elsewhere. A session is just a process on the machine, so anything that can run a shell command can build you a workspace:

tmux new-session -d -s api -c ~/src/api
tmux send-keys -t api "make watch" Enter
tmux split-window -t api -h -c ~/src/api
tmux send-keys -t api "tail -f log/dev.log" Enter
tmux attach -t api

That script can live in a Makefile, a dotfiles repo, or a CI job, and you attach later to something already warmed up. tmux new-session -A -s work is idempotent — attach if it exists, create it otherwise — which makes it safe to drop straight into a shell profile. if-shell and %if let one config file behave differently per host, and tmux -C exposes a control-mode protocol that other programs can drive directly. Session managers like tmuxinator and tmuxp are thin layers over these same primitives.

The ecosystem is the other half of the answer. tmux is in every mainstream distro repository and in Homebrew, plugin managers and plugin collections are mature, and — more usefully — almost every problem you'll hit has already been asked and answered somewhere public. That matters more than any single feature.

The cost is that the defaults are spartan. Out of the box you get a plain status bar, no mouse support, and nothing on screen telling you what any key does; you press Ctrl-b ? and read a list. The Ctrl-b prefix is awkward if you have readline habits, so nearly everyone remaps it to Ctrl-a or Ctrl-Space, which is one more thing to configure. Budget an evening for .tmux.conf and expect to read the man page, which is thorough and dense in equal measure.

## Zellij: the modern take

Zellij starts from the premise that a multiplexer's defaults should teach you the tool. It draws a keybinding hint bar at the bottom of the screen: enter a mode and it lists what's available in that mode. A new user is productive in minutes without reading anything, which is emphatically not true of the other two.

Layouts are first-class and declarative. You describe a workspace in a layout file — tabs, panes, sizes, and the command each pane runs — then start it by name. tmux reaches the same result with a shell script; Zellij treats the layout as data rather than a sequence of imperative commands, which is easier to read, diff, and share with a team.

zellij -s work                # start a named session
# Ctrl-o d                    detach
zellij list-sessions
zellij attach work
zellij --layout ./dev.kdl     # start from a layout file

It also ships floating panes, pane stacking, a good scrollback search, and a plugin system built on WebAssembly, so plugins are sandboxed and language-agnostic instead of being shell scripts with full filesystem access. If you spend your day in one local terminal and want something closer to an editor's panel layout, Zellij is genuinely nicer to live in.

The costs are all about ubiquity. It isn't preinstalled anywhere you didn't install it, and on a locked-down server you may not be able to add it at all. Its runtime is heavier than tmux's, which is irrelevant on a laptop and not irrelevant on a memory-tight VM. And its default bindings don't match tmux's, so if you run Zellij locally and tmux on servers, your fingers will fight you several times a day. Zellij ships a tmux-compatible mode that softens this, but you're still maintaining two mental models.

## Head-to-head on what actually matters

### Availability on machines you don't control

Screen first, tmux a close second, Zellij a distant third. tmux is one package-manager command away on any current system and preinstalled on many, but Screen is the one already sitting on the oldest boxes. Zellij you bring yourself, every time.

### Defaults out of the box

Zellij by a wide margin — mouse support, sane copy mode, visible hints, a useful status bar, all without touching a config file. tmux is functional but plain and expects you to invest. Screen's defaults are the most dated of the three, and its split model needs explaining before it makes sense.

### Discoverability

Zellij again, and it isn't close. The hint bar means you learn the tool by using it. tmux hides everything behind Ctrl-b ? and a long man page. Screen assumes you read the manual once, years ago, and remember.

### Scripting and automation

tmux, decisively. send-keys, split-window, if-shell, #{...} format strings, and control mode make sessions programmable from the outside by anything that can run a command. Zellij's CLI and layout files cover the common cases well but expose a smaller surface. Screen can be poked with screen -X, and that's roughly where it stops.

### Sharing a session

All three let multiple clients attach to one session. tmux is the most flexible: separate clients can view different windows of the same session, and grouped sessions let two people work independently inside one process tree. Screen's screen -x and multiuser ACLs still work but are fiddly to set up on modern systems. Zellij supports multiple clients too. For pairing across a network, you'll typically pair whichever multiplexer you use with a dedicated sharing tool rather than exposing the multiplexer itself.

### Resource footprint

Qualitatively: Screen is the lightest, tmux is light, Zellij is the heaviest of the three. On a laptop or an ordinary server this is noise and shouldn't drive the decision. On a memory-tight VM, a router shell, or a deliberately minimal container, it's a real reason to stay with tmux or Screen.

## Pick by how you actually work

• You SSH into many machines you don't control: tmux, with Screen as the fallback for boxes where tmux isn't installed and you can't install it. Learn both detach keys — Ctrl-b d and Ctrl-a d — and you'll never lose work to a dropped connection again.
• You live in one local terminal and want IDE-like layouts: Zellij. Discoverable, layouts as files, floating panes, and no muscle-memory conflict as long as remote boxes aren't part of your day.
• You script your environment — per-project sessions, dotfiles that build a workspace, CI that needs a live terminal: tmux. Nothing else has the same automation surface.
• You work on ancient, air-gapped, or locked-down systems: Screen. It's already there and it works.
• You're introducing a multiplexer to a team that has never used one: Zellij if they work locally, tmux if they live on remote servers.

Running two of them is legitimate — Zellij locally, tmux on servers is a common split — but be honest about the keybinding tax before you commit to it. Plenty of people try it and end up standardizing on tmux everywhere just to stop mistyping prefixes.

## The part that matters more than the choice

All three keep your processes alive when the connection dies, and that single behavior is most of the value. Layouts, plugins, and status bars are worth optimizing only once detaching and reattaching are automatic for you. So pick one, learn detach and reattach until you do them without thinking, and get back to work. Switching later costs you an afternoon of remapping keys — not a rewrite.