Open a terminal. A dark rectangle, a blinking cursor, a prompt waiting. Most people call the whole thing "the terminal" and leave it there.

But three separate programs are stacked inside that rectangle, written decades apart by people solving different problems. One draws. One interprets. One remembers. Confusing them is harmless until the day something you were running disappears, or an agent you left working goes quiet, and you have no idea which layer let you down.

This page pulls the three apart. Then it looks at what changed when a fourth participant started typing at the same prompt.

A lecture worth watching

In January, during MIT's Independent Activities Period, a few instructors run a short course called The Missing Semester of Your CS Education, built on an honest observation: universities teach algorithms and compilers but rarely teach the tools people use every day to get work done. The 2026 edition's second lecture, Command-line Environment, is the clearest hour on this subject we know of. It covers streams, signals, remote machines, multiplexers, and, in a section new this decade, what it means to have a language model in the shell.

"A terminal emulator is a GUI program that provides the text-based interface where your shell runs."

— Missing Semester, Command-line Environment lecture notes (2026)

Course materials are licensed CC BY-NC-SA 4.0. This page embeds the lecture and quotes a sentence; the mental model below is ours.

Three layers you've been calling one thing

From the outside in: the window you look at, the session that may or may not be holding your work, and the interpreter that actually runs your commands.

The stack
  1. Terminal emulator draws
  2. Multiplexer holds · optional
  3. Shell interprets
  4. Your programs, and now your agents run
Without a multiplexer, the shell hangs directly off the window and dies with it.
Emulator
Draws

Terminal.app, iTerm2, Ghostty, cmux, Windows Terminal. It owns the window: fonts, colors, scrollback, the clipboard. It turns your keystrokes into bytes and the bytes coming back into glyphs. It is called an emulator because it still pretends to be a piece of 1978 hardware, the DEC VT100, whose escape codes every modern program still speaks. Swap emulators and nothing about your commands changes. Only how they look.

Shell
Interprets

bash, zsh, fish, PowerShell. The program on the other end of the emulator's bytes. It reads your line, expands the *, finds the program you named, launches it, and wires its output into the next program's input. Pipes, variables, aliases, scripts: all shell. The prompt you see belongs to the shell, not the terminal.

Multiplexer
Holds

screen, tmux, zellij. Optional, and the one most people have never met. It sits between the window and the shell and keeps sessions alive on its own, independent of any window. Split one terminal into many panes. Detach, close the laptop, come back tomorrow, reattach: everything is still running. Multiplex is the old telecom word for carrying many signals over one line.

Here is the test that makes the third layer real. Start something long, then close the lid, or let the SSH connection drop. Without a multiplexer, the window goes, the shell goes with it, and everything the shell started receives the hangup signal and dies. With one, the window was only ever a view. The session was living somewhere else, and it is still there when you open the lid.

A short history of the terminal

Each layer exists because an earlier one ran into its own limit.

  1. Teletype Model 33 (1963). The first "terminal" was a printer with a keyboard. You typed, the computer typed back, on paper. tty, the name Unix still uses for a terminal, is short for teletype. Wikipedia ↗
  2. DEC VT100 (August 1978). A screen instead of paper, and a standard set of escape codes for moving the cursor and coloring text. Every emulator you use today still speaks VT100. vt100.net ↗
  3. xterm (1984). Written the summer the X Window System began, first as a standalone emulator for the VS100, then retargeted to X. The terminal became a window among windows. xterm FAQ ↗
  4. GNU screen (1987). Oliver Laumann and Carsten Bormann at TU Berlin. For the first time a session could detach from its window and be picked up later. Wikipedia ↗
  5. tmux (November 2007). Nicholas Marriott's rewrite of the idea, in OpenBSD's base system by 2009. Sessions, windows, panes: the vocabulary most people mean when they say multiplexer. Wikipedia ↗
  6. Ghostty 1.0 (December 2024). Mitchell Hashimoto's GPU-rendered emulator, built around libghostty, a core designed for other terminals to embed. mitchellh.com ↗
  7. Agent-native multiplexers (2025 to 2026). cmux, Herdr, Superlogical. The layer starts rebuilding itself around a user who never sleeps.

Paper became a screen, the screen became a window, the window learned to let go of the session. None of it changed what a command is. All of it changed who could be running one, and for how long.

The fourth participant

The 2026 lecture notes describe three ways a language model can enter the shell: generating a command for you, sitting in a pipeline like any other filter, and a third that is new in kind. In the course's words, tools like Claude Code "act as a meta-shell that accepts English commands and translates them into shell operations, file edits, and more complex multi-step tasks."

A meta-shell. The agent sits in the shell layer, but it behaves like a user: it runs commands, reads output, decides what to run next. Three things change once that is true.

  • Sessions must outlive your attention. An agent working through a refactor for two hours cannot depend on your window staying open. The lid test stops being a curiosity and becomes the whole game.
  • There are many of them. The course recommends running parallel agents on separate git worktrees so they do not trip over each other. That is many shells at once, each with its own state, not one prompt.
  • They need to call you back. A person at a prompt knows when they are waiting on you. An agent has to signal it: a notification, a status, a ring around a tab.
  • They will be fooled. An agent reads whatever the world hands it, and the shell believes whatever the agent types. When that goes wrong, the question that matters is not what it meant but what it could reach.

tmux, nearly twenty years old, already does the first job. Start the agent inside a session, detach, and it keeps working after you disconnect. That is why the oldest multiplexer still in wide use is suddenly in every agent tutorial.

The newer tools rebuild the layer with agents as the first assumption. They also split on the fourth shift: how much to trust what lives inside the session. One of them, OpenAB, laid that spectrum out in a note in August 2026; we borrow the axis, not the verdict. This is a snapshot of a fast-moving layer, not a recommendation. OpenAB, Aug 2026 ↗

Emulator · holds nothing, so no trust question

A native macOS terminal built on libghostty, with vertical tabs, a notification ring when an agent wants attention, an embedded browser, and a socket API for scripting. Designed for running several agents side by side and watching all of them. Despite the name, it has nothing to do with tmux. Open source under GPL-3.0.

Full trust · local, runs as you

Calls itself "the runtime your coding agents live on." It owns the agents' terminals, so they persist after you close the laptop, and shows each one as working, blocked, or idle across workspaces. It runs the major agent CLIs without changing how they work. Apache 2.0, on macOS, Linux, and Windows.

Trust model unpublished · server-side session

A new company from Mitchell Hashimoto, the creator of Ghostty, with Jack Pearkes, Alasdair Monk, and Hector Simpson: "the multiplexer for all work." A long-lived multiplexer you can reach from the web or a native app, share with someone else, and reconnect to from any device, meant as the base for agents, background jobs, and operations alike. Pre-launch as of this writing.

OpenAB Connect connect.openab.dev ↗
Zero trust · remote sandbox

A remote shell that lives in a deliberately unprivileged container: an ordinary user, no sudo, a read-only root filesystem, no service-account token. Every path runs over a WireGuard tailnet, and each session's token carries a time limit and no signing key. The bet is that agents will break loose, so the environment assumes from the first day that whatever is inside it cannot be trusted. The runtime is MIT-licensed open source.

Where this meets the harness

The next two pages in this tier are about guiding a model: the harness that constrains it and the context that feeds it. Both of those happen here. An agent's tools are shell commands. Its context is files on disk. Its harness runs in a session you can watch, leave, and come back to. Learn the layer first and the craft has somewhere to stand.

It is also this site's front door. The ⌘K terminal at the top of every page is an emulator of sorts, with a model behind the prompt. Different plumbing, same shape: a place where a person, a machine, and a model meet.

Takeaways

  • "Terminal" is three programs. The emulator draws, the shell interprets, the multiplexer holds.
  • The lid test tells them apart. Whatever survives closing the window was living in a multiplexer.
  • Every emulator is still a VT100. The 1978 escape codes are the reason your tools work everywhere.
  • Agents made the multiplexer new again. A user who never sleeps needs a session that never dies.
  • This is where the harness lives. The next two pages happen inside this layer.

Explore Further

Theme
Language
Support
© funclosure 2025