Learn Tmux - Core Concepts & Main Architecture

#Introduction

In episode 1 we covered the history and background: how GNU Screen (1987) solved the problem of sessions dying when connections dropped, and how Nicholas Marriott modernized it with tmux (2007) using a client-server architecture. In this episode we dissect how the machine works — because understanding the architecture is the key that makes all the keybindings, configuration, and scripting in later episodes feel logical, not memorized.

Why does this matter in the real world? When you leave a tmux session attached to a production process (a deploy script or log streaming), you need to know exactly what happens behind the scenes: is the process still running? Does the session belong to the same server? How can two terminals "share" the same screen? The answers lie in the architecture.

#Client-Server Architecture

#One Server, Many Clients

This model is the heart of tmux. There are two truly separate entities:

When you run tmux new or tmux attach for the first time, a server is launched in the background (if one doesn't exist yet). This server is what actually runs all the shells. The client is just a viewing port — you can close its window (detach), but the building and everyone working inside it stays standing.

This is what enables multi-client: two terminals, even two different machines (over SSH), can attach to the same session and see identical screens.

#The Process Behind the Scenes

Prove it yourself. Open a terminal, run tmux, detach, then from the shell prompt:

ps -ef | grep tmux
 
devnull   1234      1  0 08:00 pts/0  00:00:00 tmux: server
devnull   1235   1234  0 08:00 pts/1  00:00:00 -bash

Notice two things: the tmux: server process runs as a child of init (PID 1), not of the terminal — so closing the terminal doesn't touch it. And the -bash shell you use is a child of the server, not of the client. Detaching affects neither.

#Session → Window → Pane Hierarchy

All tmux state lives in a three-level hierarchy:

Session (paling luar; wadah kerja, bisa punya nama)
└── Window 0: [zsh]
│   └── Pane 0.0 (satu layar penuh)
├── Window 1: [code]─ Pane 1.0 │ Pane 1.1 (split vertikal)
├── Window 2: [logs]─ Pane 2.0 │ Pane 2.1 │ Pane 2.2
└── Window 3: [ops]─ Pane 3.0 (atas) / Pane 3.1 (bawah)

#Session

A session is the unit of persistence — this is what you detach and attach. A single server can run many sessions at once, each with a unique name. We'll study the full lifecycle in episode 3.

#Window

A window is like a tab: one session can have many windows, each with a number (0, 1, 2, ...) and a name. Each window has its own working directory and pane layout.

#Pane

A pane is an area within a window. Each pane runs one process (usually a shell) on its own PTY, and can be split again recursively. This is what makes tmux a "window manager" inside the terminal.

#PTY & Screen Cell Grid

Behind every pane there's a PTY (pseudo-terminal) — a kernel device that separates terminal input/output from the physical screen. The shell writes output to the PTY, and tmux captures it into a grid: an array of screen cells (character + color attributes) sized rows × columns. This grid is what gets rendered to the client screen and saved when you detach.

#Communication Through a Unix Socket

Server and client don't communicate over the network — they communicate over a Unix domain socket on the file system. Its default location:

/tmp/tmux-<uid>/default

<uid> is your user ID (id -u), so each user gets a separate directory. Take a look inside:

ls -la /tmp/tmux-$(id -u)
 
drwx------ 2 devnull devnull  120 Aug  2 08:00 .
srwxr-xr-x 1 devnull devnull    0 Aug  2 08:00 default

The default file has type srwxr-xr-x — a socket. When you run tmux ls, the client sends a request to the server over this socket. This socket is the technical answer to why two terminals can share a session: both connect to the same socket.

#Core Components

#Status Bar

The status bar is the single line at the bottom of the screen that shows the session state live: the window list (active window highlighted), session name, hostname, time, and custom segments. The status bar is rendered from a format string — we'll build one from scratch in episode 10.

#Modes: Command, Copy, and Zoom

tmux works in several modes:

#Prefix Key

Because tmux lives inside the terminal, it must share input with other processes. The solution: the prefix key. Every tmux command starts with the prefix — Ctrl+B by default — followed by one key. Ctrl+B then d = detach; Ctrl+B then % = vertical split. This prefix is the "trigger" that tells the server the following input is a tmux command, not input for the pane's process.

#Event Model & Status Line

How does tmux know what to render? There are two mechanisms:

1. Grid rendering. Every time a process inside a pane writes output, tmux captures the bytes from the PTY, updates that pane's grid, then sends the delta (changed cells) to attached clients. This keeps scrollback output re-readable in copy mode even after it's scrolled off screen.

2. Periodic status line update. The status bar isn't re-rendered on every keystroke — tmux checks the status periodically (default 15 seconds, controlled by status-interval) and on important events (window changed, active pane switched). That's why the clock in the status bar isn't always precise to the second — that's intentional to save resources.

#Verification: Get to Know Your Environment

tmux ls
 
0: 1 windows (created Mon Aug  2 08:00:00 2026)
1: 2 windows (created Mon Aug  2 08:01:00 2026)

This output format carries information: session number/name, window count, and creation time. All of this is programmatically accessible through format strings — the foundation of episode 10.

#Common Pitfalls

1. Thinking client and server are the same thing. Closing the terminal doesn't close the session — it only detaches. The server keeps running until all its sessions are killed (episode 3).

2. Pressing prefix and key simultaneously. Ctrl+B then d means two separate presses. Press Ctrl+B, release, then d.

3. Looking for the process on the client, not the server. Use ps -ef | grep tmux to see the tmux: server process — not tmux attach, which is only a temporary client.

4. Manually deleting the tmux socket. Deleting the file in /tmp/tmux-<uid> doesn't clean up the server — the server is still alive and will create a new socket. Use tmux kill-server to kill all sessions.

5. Changing the status format then wondering why it doesn't change immediately. The status line is updated periodically (status-interval, default 15 seconds). Give it time, or use tmux refresh-client -S.

6. Ignoring the PTY. Understanding that each pane is a process on a PTY helps when debugging weird output or an empty scrollback — usually related to history-limit or a restarted process.

#Conclusion

In episode 2 we dissected the tmux architecture: the client-server model with one background server managing all sessions, the session → window → pane hierarchy each mapping to a PTY and a screen cell grid, communication over a Unix socket at /tmp/tmux-<uid>/default, and the grid rendering plus periodic status bar update mechanisms.

Key points to take away:

• Server vs client: the server runs all processes; the client is just a viewing port.
• Hierarchy: session (container) → window (tab) → pane (split viewport).
• The Unix socket is the client-server communication path; one socket enables multi-client.
• The prefix key (Ctrl+B) is the trigger for all tmux commands — press, release, press.
• The status bar is rendered periodically, not on every keystroke.

The architecture is now clear — time to drive the machine. In episode 3, we'll cover Session, Window & Pane Lifecycle Basics — creating, attaching, detaching, and destroying sessions; managing windows with c, n/p/0-9, rename, and find; and splitting and navigating panes. Stay excited, because starting in episode 3 you'll really "live" inside tmux.