An agent can print thousands of lines while you read one. A terminal that stutters, drops a frame or sends your keystroke to the wrong pane breaks your trust quickly. So every pane in Agent Interface is drawn natively, and the window never waits on a terminal.
This post follows output from tmux to the screen, and keystrokes from your keyboard back to the right pane.
No web view
The window is built with GPUI, a native toolkit that draws on the GPU. Terminal emulation comes from Ghostty's terminal core, libghostty-vt, the same engine that interprets escape sequences inside the Ghostty terminal. It sits behind one boundary in the code, the term crate, so nothing else depends on engine types.
There is no web view for terminals and no app daemon. The only web content in the app is the reader for rich HTML documents on macOS, which runs in its own isolated surface and never touches a terminal.
From tmux to pixels
Each pane connects to tmux as a control-mode client. From there, output passes through three stages, and only the last one runs on the UI thread.
screen
A background reader decodes tmux's control messages into pane output, command replies and layout events. It queues output only for panes in the window it is following. A terminal worker owns the Ghostty engine handles and feeds that output into each pane's terminal state.
Owned snapshots
When a pane's state changes, the worker copies it into an owned Screen and publishes it. The UI thread draws that snapshot. It never borrows a live engine and never waits for I/O.
Copies are all or nothing. A partially copied frame never replaces the last complete one. If copying fails, the worker reports a connection failure and stops publishing, rather than drawing something half true.
Hidden panes keep their workers running. That costs some memory for their state and scrollback, and it means a tab you return to shows exactly what the program printed while you were away.
Keys go to the right pane
Input runs the same path in reverse, with one rule above all: a keystroke goes to the pane it was meant for.
Keys are encoded for the destination pane's reported modes, such as application cursor keys, extended keys and bracketed paste. Switching panes never redirects input that is already queued, and input waits until a newly selected pane is ready.
Input is bounded too: at most 64 outstanding operations and 8 MiB per view, and 4 MiB for a single paste. Anything beyond that is rejected visibly instead of freezing the window. If an older tmux cannot report whether bracketed paste is on, a multiline paste is refused with a visible message until the shell turns that mode on; single-line paste still works.
Readable by assistive tools
The focused terminal exposes its active pane and input caret through the platform's native accessibility bridge. Text ranges keep terminal characters and cell positions intact, so dictation tools can find where you are typing and paste into it like any other text field.
Building Ghostty's core
Ghostty's core is built from a pinned Ghostty commit plus a small patch, and the build checks both digests before using them. Release packages compile it with ReleaseFast for a baseline CPU, so packages do not depend on newer processor features.
You do not need any of that to use the app. The installer downloads a compiled build and verifies its checksum, with no Rust, Zig or Python toolchain required. Ghostty's core is MIT licensed, and its notices ship with every package.
Input methods and key-release events are not wired into the product yet, and recovery can only restore the state tmux reports, so a full-screen program may need a keypress to redraw.
The architecture guide covers the terminal pipeline and its boundaries in full.