Coder’s Boo Brings GNU Screen’s Model to Modern Terminal Automation

Coder has introduced boo, a GNU Screen-style terminal multiplexer built on libghostty and written in Zig. The pitch is not another feature-packed terminal workspace. Boo is narrower by design: one session per task, a familiar Ctrl-A prefix, attach and detach behavior, and automation commands that can inspect and drive terminal sessions without requiring a live TTY.

The problem boo targets is old but newly relevant. Developers have long used GNU Screen or tmux to keep jobs alive after disconnecting, but modern terminal programs emit richer control sequences than older terminal emulators always handle well. That matters when a detached process is running a TUI, an installer, a build monitor, or an agent workflow that expects the terminal to answer queries correctly.

Boo’s technical bet is that a multiplexer should maintain an accurate model of the screen, not just save output bytes. Every session’s output is parsed through Ghostty’s terminal emulation core, so boo tracks contents, styles, cursor position, scrollback, terminal modes, window title, and related state. When a user reattaches, boo redraws from that state. When a script asks what is on screen, boo can return the rendered screen rather than a raw and often misleading byte log.

That distinction is the real product idea. In a conventional automation loop, scripts often send input, sleep for a guessed interval, scrape logs, and hope the program reached the expected state. Boo offers primitives such as send, wait, peek, and JSON output. A script can create a detached session, type into it, wait until output is idle or until text appears, inspect the reconstructed screen, then clean up the session.

The repository’s example is direct: boo new build -d -- bash, boo send build --text 'make' --enter, boo wait build --idle, and boo peek build --scrollback. That is a small interface, but it addresses a real source of fragility in developer automation. Terminal UIs were built for humans, yet modern coding agents and CI-adjacent tools increasingly need to operate them as if they had eyes on the screen.

Market positioning is where boo gets interesting. It does not appear to be trying to replace tmux for power users who rely on panes, tabs, shared sessions, and years of muscle memory. The project explicitly keeps closer to Screen’s mental model: persistent sessions, a prefix key, and a session manager UI. That restraint may help it find a niche among developers who want persistent terminal jobs without adopting tmux’s broader workspace model.

The AI-agent angle is also hard to miss. Coder’s core business sits around cloud development environments, and boo’s automation primitives fit the operational needs of remote coding sessions, unattended tasks, and agent-driven workflows. If an AI coding agent can read a terminal exactly as a person would see it, including screen redraws and TUI state, it can handle a wider class of tools without custom integrations for each one.

There is no funding amount, investor list, or project-specific financing disclosed in the boo repository. The traction signal available from the source is product-side rather than capital-side: an open source MIT-licensed release, prebuilt Linux and macOS binaries, a documented installation path, and a clear contributor workflow using Zig 0.15.2. For a young infrastructure tool, that is enough to evaluate the technical direction, but not enough to infer commercial adoption.

Boo is also candid about its limits. It is not a drop-in Screen replacement yet. It supports one attached client per session, one window per session, no splits or tabs inside a session, a non-configurable Ctrl-A prefix, and TERM=xterm-256color. Those constraints make the early release easier to reason about, but they also define the current buyer, or more likely adopter: someone who values reliable detached terminal state and automation more than multiplexing breadth.

The architecture is conventional in shape and modern in its terminal core. A boo client talks to a session daemon over a Unix socket. The daemon owns a PTY-attached child process, and that child’s output feeds a persistent Ghostty VT terminal stream. While attached, bytes pass through to the real terminal. On attach, boo sanitizes the terminal and replays the saved state using Ghostty’s formatter.

That design choice explains why terminal queries matter. Detached TUIs can ask questions such as cursor position, device attributes, or window information. If those queries go unanswered, tools may hang or behave oddly. Boo uses Ghostty’s stream handler to answer them while detached, then lets the real terminal answer while attached to avoid duplicate replies.

The trade-off is dependency on the correctness and coverage of libghostty’s VT behavior. That is a reasonable dependency if the goal is modern terminal fidelity, but it ties boo’s quality to a complex terminal emulation layer. The upside is obvious: instead of each multiplexer maintaining an aging private emulator, boo builds on a terminal project already focused on current escape sequences and rendering behavior.

For developers, the practical test will be whether boo handles messy real programs: package managers with progress bars, full-screen editors, flaky installers, test runners, REPLs, and TUIs that redraw aggressively. If peek --json gives scripts a stable view of those sessions, boo could become useful far beyond manual attach and detach workflows. If it only works well on simple command output, it will remain a neat Screen reinterpretation.

Boo’s opportunity is not that terminal multiplexing is new. It is that terminal sessions are becoming an API surface for tools that were never designed as APIs. Build systems, agent loops, remote IDEs, and local dev containers all need a better way to keep interactive work alive and inspect it accurately. Boo is an early attempt to make that surface cleaner without asking developers to abandon the terminal model they already understand.

For now, boo is best read as an infrastructure experiment with a sharp thesis: persistent terminal sessions should be inspectable, scriptable, and faithful to what a human would see. That is a narrower claim than most startup tooling pitches, which makes it easier to evaluate. The next signal to watch is whether developers and agent builders adopt it for real workflows, not whether it can accumulate another long list of multiplexer features.