What Is tmux? The Terminal Multiplexer, Explained

You've probably had the moment this article exists for: an SSH connection drops, and the compile job or model training you left running on the server dies with it. Hours gone, back to zero. What is tmux? Short answer: a terminal multiplexer — a small open-source program that keeps terminal sessions alive on the machine where they run, even after you disconnect. You attach to a session, do your work, detach, fly home, attach again from another computer, and everything is still there, exactly as you left it.

That's the pitch. The rest of this tutorial explains what a terminal multiplexer actually is, why the disconnect trick works (the mechanism is genuinely interesting), and how to get your first session running in about five minutes.

What Is tmux, Exactly?

The official wiki defines tmux in one sentence: it lets you switch easily between several programs in one terminal, detach them — they keep running in the background — and reattach them to a different terminal. The name is just a squashed version of terminal multiplexer.

The basics, quickly. tmux is free and open-source software, first released on 20 November 2007, written in C by Nicholas Marriott and born in the OpenBSD project — it still ships in the OpenBSD base system today. It runs on every Unix-like platform: Linux, macOS, the BSDs, and Windows through WSL. Development is very much alive; the current stable release is 3.7c, published in August 2026.

So what does "multiplexer" mean here? Think of it as a window manager that lives inside your terminal. A window manager takes one physical screen and gives you many virtual workspaces; tmux takes one terminal connection and gives you many terminals inside it — tabs, split screens, the works. And it adds one thing a window manager doesn't: those terminals keep running when you walk away.

Why Your Processes Die When SSH Drops

To understand what tmux buys you, it helps to know why things break without it.

When you run a command in a terminal, that command is a child process of your shell, and the shell is tied to the terminal session. Here's the cruel part of Unix that most people never get told: when a terminal closes — you close the window, or your SSH connection drops — the shell sends a SIGHUP signal to every child process. The name literally means "hangup", a relic from modem days, and the default response to it is to die. Your compile job didn't crash. It was told to shut down, politely, by a system that assumed a lost connection means an abandoned session.

Maybe you've reached for nohup in this situation. It works, after a fashion: nohup ./long-job & tells the process to ignore SIGHUP, so it survives the disconnect. I used this for years before accepting its limits. You can't send the process new input once it's backgrounded this way. Output piles into a nohup.out file you have to tail separately. And if you're juggling three or four long tasks, you're now managing a zoo of orphaned processes with no way to see them side by side.

When the terminal goes, it takes your work with it. tmux is the fix: it moves your programs out from under the SSH session entirely.

How tmux Works: One Server, Many Clients

tmux is built on a client-server model, and this is the one piece of theory worth holding on to.

The first time you run any tmux command, a background process called the tmux server starts. This server holds all the state — every session, every window, every running program, every byte of pending output. When you type tmux in a terminal, you're actually starting a client that connects to that server through a socket file in /tmp and "attaches" to a session. The official getting-started guide describes this architecture in depth.

Now the disconnect story makes sense. Your SSH session only owns the client. When the connection drops, the client dies, but the server — and everything it manages — keeps running untouched. Reconnect, start a new client, attach, and you're back. The same protection applies to closing your terminal window by accident, which I have done more times than I'll admit.

A few consequences fall out of this design:

• Multiple clients can attach to the same session at once, from different computers — that's how pairs do real-time terminal sharing.
• The server exits on its own when its last session ends, so it won't linger as a zombie process. There's also a kill-server command for forcible cleanup.
• Exiting works in cascade: close the shell inside a pane and the pane dies; when a window's last pane dies the window goes; when a session's last window goes the session goes; and when the last session goes, the server shuts down.

Sessions, Windows, and Panes

tmux organizes everything into three nesting levels, and getting these terms straight makes every tutorial and man page easier to read.

A session is a persistent, independent workspace — think of it as a project. Sessions hold windows, which behave like browser tabs: you see one at a time and switch between them. Each window fills the whole terminal and can be divided into panes, the rectangular splits that each run their own program. The tmux basics come down to this hierarchy: session contains windows, windows contain panes, panes contain your running programs.

The green bar at the bottom is the status line. On the left it shows the session name and the window list — numbers, names, and a * marking the active window. On the right, typically the hostname, date, and time. It's fully customizable; people go wild with it.

Sessions get numbered 0, 1, 2 by default, which is fine until you have five of them. Name them when you create them (tmux new -s build) and your future self will thank you.

Your First Five Minutes

Enough theory. Here's the shortest path to a working session, from zero.

Install tmux with your platform's package manager — brew install tmux on macOS, sudo apt install tmux on Ubuntu or Debian, sudo dnf install tmux on Fedora or RHEL. Then:

tmux new -s test

You're in. The status line appears at the bottom, and you have a session named "test" with one window and one pane running your shell. Run something slow in it:

while true; do date; sleep 1; done

Now detach: press Ctrl+b, release, then press d. You're dumped back to your plain terminal, and the session is gone from view. Check that it's alive:

tmux ls

You should see test: 1 windows (...). The clock is still ticking in there. Reattach with:

tmux attach -t test

And there's your clock, never having stopped. That's the whole magic trick. Close the terminal window entirely, open a new one, attach again — same result.

Two more keys to play with while you're here. Ctrl+b is the prefix, a concept borrowed from vim's leader key: press it, release, then press a command key. Ctrl+b then % splits the window into left and right panes; Ctrl+b then " splits top to bottom. Careful with the wording you'll see around the web — some tutorials call % a "horizontal split" and others call it "vertical", and they mean opposite things. Just remember the keys: % gives you side-by-side, " gives you stacked.

One honest warning from someone who stared at this wall for a while: tmux ships with 85+ default key bindings, and trying to memorize them upfront is how people bounce off the tool. You need about six keys for a productive first week — new, detach, attach, split, switch pane, switch window. For everything else there's a cheat sheet on one page, and the full tmux(1) man page when you want to go deep.

What People Use tmux For in 2026

The classic use cases haven't moved. Long-running remote work — compiles, model training, database migrations, backups — where a dropped connection would otherwise cost hours. Multi-machine workflows: start something at the office, attach from home, pick up mid-thought. And plain window management on a local machine, no SSH involved, which is underrated; tmux works exactly the same locally, and "I closed the wrong terminal window" stops being a disaster.

What's new is the AI angle. A lot of developers now run AI coding agents — things like Claude Code — on remote or dedicated machines, and those agents work in sessions that stay alive for days or weeks while you check in periodically. That's a tmux-shaped problem if there ever was one: the agent keeps working whether or not you're connected, and you drop back in to see where it got to. If you're setting up something like this, our guide to running Claude Code covers the workflow.

Beyond that: system administrators use shared sessions for pair debugging, teams use them to watch the same logs during an incident, and anyone with a Raspberry Pi or home server in a closet uses tmux to admin it without keeping a terminal open forever.

tmux vs. Screen (and vs. Termux)

Two comparisons come up constantly, so let's settle both.

GNU Screen is the older tool tmux is most often compared to. tmux covers most of Screen's feature set with a more modern code base, and Screen has been deprecated in some Linux distributions. But they are not drop-in replacements for each other: the default command keys differ, so muscle memory doesn't transfer (tmux can be configured to use Screen-compatible bindings if you want it to). tmux also lacks built-in serial-port and telnet support that Screen has — irrelevant for most people, decisive for a few. My take: starting fresh in 2026, there's no reason to pick Screen first.

Termux is not tmux at all. Termux is an Android app — a terminal emulator for your phone. The names look similar, search results get tangled, and the two have nothing to do with each other. If you typed "tmux" into the Play Store, back out slowly.

Frequently Asked Questions

What is tmux used for? Three big things: keeping remote processes alive through SSH drops, managing multiple terminal programs in one window (tabs and split panes), and resuming work from any machine. Increasingly, also for hosting long-running AI agent sessions.

Does tmux work on Windows? Not natively — tmux targets Unix-like systems. On Windows you run it inside WSL (Windows Subsystem for Linux), where it behaves exactly as on Linux. On macOS it's a first-class citizen via Homebrew.

Is tmux hard to learn? The concepts take ten minutes; the default key bindings take longer. The prefix system (press Ctrl+b, release, then a key) feels odd at first, but you only need a handful of bindings to be productive, and everything is rebindable in ~/.tmux.conf.

Is tmux still maintained and worth learning in 2026? Yes on both counts. The current release is 3.7c from August 2026, development remains active after 18 years, and the rise of long-running AI agent workflows has given it a fresh wave of relevance.

Knowing what tmux is is table stakes; the muscle memory is what pays off. Start with the tmux cheat sheet — every command and shortcut from this article on a single page, ready for daily reference.