Close the window, keep the work: how Agent Interface uses tmux

Agents are long-running by nature. A refactor, a test suite, a review pass: any of them can outlast your attention, your battery or your patience with a window. So Agent Interface was built around one rule. Closing the app must never stop the work.

That rule is easy to state and easy to break. This post walks through how the app keeps it, from the line between the window and tmux to what really happens when you close a pane.

Two owners, one clear line

Agent Interface draws the window and keeps your saved arrangement: workspaces, tabs and split layouts, stored in a library, a folder containing layouts.db. tmux owns everything else: the sessions and every process inside them.

There is no app daemon in between. When the window goes away, nothing of Agent Interface is left running, and nothing needs to be, because tmux was holding the processes all along.

One control-mode client per pane

Each pane talks to tmux through its own control-mode client, tmux -C. The connection opens the first time the pane is displayed and stays open while you move between tabs and workspaces.

A background reader decodes tmux's control messages into pane output, command replies and layout events. A terminal worker feeds that output into Ghostty's terminal core and publishes finished screens for the UI to draw. The UI never waits on tmux, and a half-copied frame never replaces the last complete one.

Hidden is not stopped

Switch to another tab and the panes you left keep consuming output. That costs some memory for their workers and scrollback, and buys you something important: when you come back, the screen is exactly where the program left it, not where you left it.

Hidden clients also step out of tmux's window sizing with ignore-size, so a pane you are not looking at never squeezes the window for anyone else. The next time it is drawn, it takes part again at its real size.

What close and detach really do

This is where the rule is kept. Detach, Close Pane and Close Tab never send a command that ends a session. Closing a window detaches its clients and nothing more.

a pane     let queued input drain (up to 1 s), then detach its client
a tab      detach every client in the tab
the window detach the window's clients
never      end a session or stop its processes

A session you attached from elsewhere keeps its own lifetime policy, including tmux's destroy-unattached option, so the app never overrides a choice you made in tmux. Even the rare client that refuses to detach is handled carefully: after a second it is terminated, and its session is not.

Coming back

Reopen Agent Interface and your workspaces load from the library. Each pane reconnects when it is shown, captures its current state and the history its scrollback keeps, then carries on with new output.

What this means for your agents

Start a long Claude Code or Codex run, close the lid or quit the app, and come back later. The workspace returns, the pane reconnects, and the run is still going, or finished with its output waiting for you.

That is the whole idea: the window is disposable, the work is not. If you want to go further, the architecture guide covers the connection model in full.