Does Rust-built Zellij actually replace tmux? Both are client-server, so surviving a disconnect is table stakes rather than a differentiator — the real dividing lines are Session Resurrection (built in since 0.39), KDL layouts you can commit to your repo, and what Wasm plugins actually buy you (sandboxing and permissions, not speed — the runtime moved to the wasmi interpreter in 0.44). We correct the widespread `Ctrl+Z`-hides-the-UI myth against `default.kdl`, note that tmux has had `display-popup` since 3.2, and close by working out whether herdr can be nested with either — where the direction of nesting is the whole answer.
In the terminal multiplexer world, tmux has long been the default choice and the industry benchmark. In recent years a challenger written in Rust — Zellij — has gained ground fast on the strength of a usable-out-of-the-box experience, a modern UI, and a WebAssembly-based plugin system.
The real argument underneath this changing of the guard is "minimalism plus deep customization" versus "works immediately, on a modern architecture." This article compares the two on architecture, configuration and ecosystem, and session persistence — then answers a question that keeps coming up: how does herdr, the AI-era newcomer, actually fit alongside them?
Every keybinding and behavior below was checked against Zellij v0.45.1's
default.kdl(released 2026-08-28), tmux 3.2+, and the official docs for herdr v0.4.0. This tooling moves quickly — when you read this, trust your ownzellij --versionover this article.
1. Architecture and Performance: the C Veteran vs the Rust Newcomer
tmux (C): rock-solid minimalism
tmux uses the classic client-server architecture. When your terminal emulator crashes or SSH drops, the background server process still holds the session. After nearly two decades of refinement its footprint is tiny, and it stays stable on old servers, 1-core/1GB boxes, and high-latency links.
Zellij (Rust): a sandboxed modern design
Zellij is also client-server. So on "your session survives a disconnect," neither tool has an edge — that is table stakes for a multiplexer, not anyone's selling point.
Zellij's real architectural difference is plugin isolation. Plugins are not shell scripts running as child processes; they are compiled to WebAssembly and executed in a sandbox with an isolated memory space and an explicit permission system. A misbehaving third-party plugin therefore has a hard time taking the whole session down with it.
That sandbox also enables a distribution model tmux has no equivalent for: a plugin can be loaded straight from a URL, with no repo to clone, no plugin manager to install, and no config reload.
The costs deserve equal billing. Zellij's binary size and resident memory are both noticeably larger than tmux's, and on genuinely constrained machines tmux remains the safer bet. That said, Zellij ships as a single static binary with no external dependencies — on a box where you have no root, scp-ing one binary across is often faster than installing a package.
2. Interaction Model and Learning Curve
- tmux (steep): the design philosophy is "provide nothing by default." A new user faces a black rectangle and has to memorize
Ctrl+b(the default prefix) plus assorted letters before they can split or switch anything. The ceiling is very high; so is the dropout rate. - Zellij (gentle): an interactive status bar sits at the bottom by default, showing the current mode and the keys available in it. You can work without opening the manual. Mouse support (click to focus, drag to resize) is on by default, whereas tmux needs
set -g mouse on.
The difference is not merely "one has a hint bar." The interaction models themselves differ. tmux is a prefix model: every action means pressing Ctrl+b and then an action key, after which you are back in the normal state. Zellij is a mode model (Vim-like): Ctrl+p puts you in Pane mode and leaves you there, so you can press n, d, r in sequence to open three panes, then leave with Esc or Ctrl+p.
For sustained work like rearranging a layout, the mode model is clearly easier on the fingers — but it requires you to always know which mode you are in. The status bar is displayed by default precisely to absorb that cognitive load. Conversely, tmux's prefix model is more verbose but almost never produces mode confusion, which is a genuine reason many veterans decline to migrate.
A widespread myth about "hiding the UI"
You will often read that "Ctrl+Z in Zellij hides the UI and gives you a clean terminal." This is wrong. Ctrl+Z is not bound to anything in Zellij's default configuration, and its traditional meaning in a terminal is SIGTSTP — suspending the foreground process.
Checked against default.kdl, the correct operations are:
| Goal | Actual keys |
|---|---|
| Toggle pane frames | Ctrl+p then z (TogglePaneFrames) |
| Fullscreen the pane with no UI | Ctrl+p then Shift+f |
| Permanently minimal UI | Set pane_frames false / simplified_ui true, or use the built-in compact layout |
Two things tmux users should know
First, in Zellij's normal mode Ctrl+b is bound to Tmux mode — an official tmux-compatible keyset ships in the box, so migrating does not mean resetting your muscle memory to zero.
Second, Zellij's defaults consume a great many Ctrl combinations and collide badly with Vim, Emacs, and TUI shortcuts generally. This is a real pain point, and the project addressed it in 0.41 with the Unlock-First preset: the interface stays locked so keys pass straight through to your application, and you "unlock" only when you want to drive Zellij. Heavy TUI users should switch to that preset immediately, or at minimum memorize Ctrl+g for Locked mode.
3. Configuration and Extensibility: the Real Cost of KDL and Wasm Plugins
| Dimension | tmux | Zellij |
|---|---|---|
| Config file | Bespoke .tmux.conf syntax (3.x also reads ~/.config/tmux/tmux.conf) | Structured KDL |
| Layout presets | Needs external tooling (tmuxinator et al.) | Native layout files |
| Key logic | Prefix key + action key | Mode switching (Vim-like) |
| Plugin form | Shell scripts (managed by TPM) | WebAssembly / WASI sandbox |
| Ecosystem size | Large and mature | Small and young |
Layout as code: what KDL actually looks like
The row in that table with the largest day-to-day impact is layout presets. A Zellij layout is a KDL file you can commit to your repository:
1layout {
2 tab name="web" focus=true {
3 pane split_direction="vertical" {
4 pane command="npm" {
5 args "run" "dev"
6 }
7 pane split_direction="horizontal" {
8 pane command="npm" {
9 args "run" "test:watch"
10 }
11 pane
12 }
13 }
14 }
15 tab name="logs" {
16 pane command="docker" {
17 args "compose" "logs" "-f" "mysql"
18 }
19 }
20}After that, zellij --layout ./dev.kdl brings up frontend, tests, a spare shell, and database logs in one command. Commit the file to the project and a new teammate gets your exact workspace from a git clone.
Doing the same in tmux generally means hand-writing a script of new-session / split-window / send-keys calls, or adopting tmuxinator's YAML. The former is fragile with respect to pane ordering; the latter adds a Ruby dependency. This is Zellij's most concrete practical advantage, and it has nothing to do with the UI looking nice.
Wasm plugins: the win is the sandbox, not the speed
Zellij's Wasm plugin system genuinely is its most distinctive design. Plugins can be written in any language that compiles to WASI (Rust is the first-class citizen, with the official zellij-tile SDK), they talk to the host over Protocol Buffers, and they run in a sandbox with explicitly granted permissions.
One widely repeated claim needs correcting, though: Wasm plugins do not mean "high performance."
Zellij's plugin runtime has in fact been swapped twice: from wasmer to wasmtime in 0.41, and then in 0.44 to wasmi — an interpreter. The release notes are explicit about why: it removes the need for an explicit compilation step and for caching compiled plugins. The stated cost is that it "might incur a slight performance penalty," which plugin authors are advised to offset with lto = true, strip = true, and codegen-units = 1 in Cargo.toml.
So the real payoff of Wasm is sandboxed isolation, a permission model, language freedom, and compile-free distribution — not raw speed. In the other direction: tmux plugins may be "dated" shell scripts, but the TPM ecosystem still dwarfs Zellij's in both size and maturity. When you want some niche capability, the odds that someone already wrote it are better on tmux.
4. Session Persistence: Disconnects, Reboots, and "Resurrection"
This is the scenario developers care about most, and the one most often waved away with "both handle it fine." In reality the two tools' capability boundaries are not the same.
SSH disconnect: a tie
Both are client-server, so after a dropped connection tmux attach and zellij attach both get you back. No winner here.
Machine reboot: Zellij wins natively
Zellij has shipped Session Resurrection since 0.39. Sessions are serialized to the cache directory by default, and re-attaching to an exited session rebuilds it — whether it ended through a deliberate quit or a crash.
Several design details are worth noting:
- The serialized artifact is a human-readable Zellij layout, so it can be shared with a colleague or carried to another machine.
- By default it restores the pane/tab layout and the command running in each pane; configuration can extend this to the viewport and scrollback.
- Resurrected commands do not run automatically — they wait behind a "Press ENTER to run..." prompt. That guard exists so something like
rm -rfis not silently replayed after a reboot.
Getting the equivalent in tmux means installing two third-party plugins, tmux-resurrect and tmux-continuum, via TPM:
# ~/.tmux.conf
set -g @plugin 'tmux-plugins/tmux-resurrect'
set -g @plugin 'tmux-plugins/tmux-continuum'
set -g @continuum-save-interval '15' # autosave every 15 minutes
set -g @continuum-restore 'on' # restore automatically on tmux startFetch the plugins with prefix + I; saves land in ~/.tmux/resurrect/. The approach is mature and genuinely good, but it remains an external part you assemble yourself rather than a built-in capability. The practical difference: on a fresh machine Zellij has this behavior the moment it is installed, while tmux needs that configuration synced over first.
One boundary is easy to miss. What both restore by default is layout and commands, not process memory state. A half-finished compile and an unsaved REPL session are not coming back after a reboot. Session resurrection solves "rebuild my workspace," not "freeze my processes" — do not mistake it for CRIU.
Floating panes: not a Zellij exclusive
The claim that floating windows are Zellij's killer feature is also inaccurate. tmux has had display-popup since 3.2.
The difference is semantic. A tmux popup is a transient overlay drawn by the display layer; it disappears when the command finishes or you press Esc. Zellij's floating panes are first-class panes: you can move one between floating and embedded (Ctrl+p then e), toggle them as a group (Ctrl+p then w), and even pin one (Ctrl+p then i). Zellij additionally has stacked panes (Ctrl+p then s), which tmux does not.
"tmux is the only option"? Also not true
On an unfamiliar machine, GNU Screen is actually preinstalled more often than tmux, and dtach and abduco exist as well. The accurate framing is that tmux has the lowest installation cost and by far the richest body of documentation and accumulated experience — not that it is the only answer.
5. Sidebar: Can Zellij / tmux Be Used With herdr?
With AI-assisted programming booming, herdr — an agent multiplexer written in Rust — has drawn a lot of attention. Its hierarchy goes one level deeper than tmux's (session → workspace → tab → pane → agent), a sidebar rolls each agent up into one of 🔴 blocked, 🟡 working, 🔵 done, or 🟢 idle, and it exposes a CLI and a socket API for scripts to drive, plus a remote mode that runs the server on another machine.
More than "another pane splitter," herdr's value is that it understands the agent lifecycle: you no longer have to click through panes one at a time to find out which agent is blocked waiting on you and which has finished. It can also restore an agent's actual conversation (using something like Claude Code's own resume capability) rather than just reopening an empty pane. That is the part an ordinary multiplexer cannot reach — tmux can keep your shell alive, but not your conversation.
Which raises the question: can you use Zellij and herdr together?
The answer is yes, and herdr positions itself as complementary rather than as a replacement.
This corrects a claim that circulates widely: that the two are alternatives, and that nesting them leaves herdr blind. herdr's own README says of tmux that "tmux gives you persistence and panes, but it was built before agents existed," and its comparison table presents stacked capabilities rather than an either/or. On the other side, Zellij v0.45.1 specifically fixed nested session detection over SSH. Nesting is a supported, acknowledged scenario.
What actually matters is direction — which is where the "the TTY state gets intercepted" explanation goes wrong. herdr detects state through process-name matching plus terminal-output heuristics, while officially integrated agents report semantic state directly over the socket API.
- herdr running inside a Zellij/tmux pane (herdr on the inside): this works fine. Zellij is not sitting between herdr and the agent; herdr still owns the agent's PTY directly, so detection is unaffected. The only real cost is prefix-key contention, which Zellij's
Ctrl+gLocked mode, the Unlock-First preset, or a changed tmux prefix resolves. - Zellij/tmux running inside a herdr pane (herdr on the outside): this is the direction that breaks. The inner multiplexer now sits in the middle, so what herdr sees is its redraw traffic rather than the agent's output, and the output heuristics degrade accordingly. Process-name matching sees
zellij, notclaude.
A selection strategy for the AI era
- Traditional development flow (writing code, running services): pick Zellij or tmux on the merits from the first four sections.
- AI-driven development flow (running several agents in parallel, responding to confirmation prompts as they arrive): putting herdr at the outermost layer is the path of least resistance. If you already have a heavily customized Zellij or tmux setup, nesting herdr inside it works just as well.
Two practical caveats. herdr is currently v0.4.0 and pre-1.0, so protocol upgrades can require restarting the server. And it is dual-licensed under AGPL-3.0-or-later plus a commercial option — worth running past legal before it goes into a closed-source workflow.
6. Choosing
| Your situation | Recommendation |
|---|---|
| Frequent SSH into unfamiliar or old servers | tmux (lowest install cost, deepest body of experience) |
| Severely resource-constrained machines | tmux |
| Heavy Vim / Emacs / TUI user | tmux, or Zellij's Unlock-First preset |
| Local primary machine, fixed cloud dev box | Zellij (native layouts + session resurrection) |
| Multi-process microservice workspaces | Zellij (one command from a KDL layout) |
| Want the workspace restored automatically after reboot | Zellij natively; tmux needs resurrect + continuum |
| Managing several AI coding agents in parallel | herdr (standalone, or nested with either of the above) |
tmux is still the dependable veteran that will pull you out of trouble in any hostile environment. Zellij is the modern workstation that meaningfully lowers the cognitive load. And herdr fills in a layer that did not exist when either of the other two was born: awareness of agent state.
There is no absolute winner, only the tool that best fits the workflow you have today. If your tmux muscle memory is already complete, there is no need to migrate for the sake of being modern. But if you are setting up a new development machine, this is genuinely a good moment to try Zellij.
コメント
コメント (0)