Boo: A GNU Screen-style Terminal Multiplexer built on libghostty

Boo is a terminal multiplexer designed as a modern alternative to GNU screen, built using the Zig programming language and powered by libghostty-vt. By integrating Ghostty's terminal emulation core, Boo ensures that session state—including contents, styles, cursor position, and scrollback—is accurately preserved and redrawn upon reattachment, solving the common issue where older multiplexers mangle modern terminal output.

Accurate Terminal State via libghostty

Boo uses libghostty-vt to parse all session output, allowing the daemon to maintain a precise representation of the screen state at all times. This architecture provides several technical advantages over traditional multiplexers:

  • Faithful Redraws: When a user reattaches to a session, Boo uses the TerminalFormatter from libghostty to replay the screen, ensuring SGR styles, scrolling regions, and window titles are rendered exactly as they would be in a native terminal.
  • Detached Query Handling: While a session is detached, the daemon can answer terminal queries (such as DSR or XTWINOPS) using libghostty's stream handler. This prevents TUIs (Text User Interfaces) from hanging while waiting for a response from a terminal that is no longer attached.
  • State-Awareness: Because the daemon knows the exact screen state, it can provide the rendered screen to external scripts or AI agents without requiring a TTY.

Agent-Friendly Automation Primitives

Boo is designed to be a sandbox for scripts and AI agents, providing a set of primitives that allow programmatic interaction with interactive programs without the need for a TTY.

Programmatic Control Loop

The canonical automation workflow in Boo consists of five steps:

  1. Creation: boo new build -d -- bash creates a headless session.
  2. Input: boo send build --text 'make' --enter sends literal text and a newline.
  3. Synchronization: boo wait build --idle blocks until output has been quiet for two seconds (or boo wait build --text <text> blocks until specific text appears).
  4. Observation: boo peek build --scrollback reads the rendered screen state.
  5. Cleanup: boo kill build terminates the session.

Automation Features

  • peek: Unlike raw byte logs, peek reconstructs the rendered screen. The --json flag provides machine-readable output including cursor position and terminal size.
  • send: Provides literal text input without escape processing or implicit quoting layers.
  • wait: Eliminates the need for sleep-and-poll loops by blocking until specific text is found or the terminal becomes idle.

Architecture and Design

Boo employs a client-server architecture to manage sessions. The client puts the local TTY in raw mode and communicates via a framed Unix-socket protocol. The session daemon (forked upon session creation) owns the PTY-attached child process and feeds its output into a persistent ghostty-vt TerminalStream.

Comparison with Other Multiplexers

Boo intentionally follows the GNU screen model rather than the tmux model. It focuses on one session per task with a simple prefix key (Ctrl-a) and a dedicated session manager (boo ui) to juggle multiple sessions.

Feature Boo GNU Screen tmux
Backend libghostty-vt Legacy Emulator Custom Emulator
Automation Native send/peek/wait -X stuff / Hardcopy Client-server API
State Tracking Full VT state Partial/Legacy Full VT state
Model Session-centric Session-centric Window/Pane-centric

Current Limitations and Caveats

As a young project, Boo has several known limitations:

  • Single Window: Each session is limited to one window; there are no internal splits or tabs. Users are encouraged to run one session per task.
  • Single Client: Only one client can be attached to a session at a time; session sharing (similar to screen -x) is not supported.
  • Fixed Prefix: The Ctrl-a prefix is currently not configurable.
  • Terminal Type: All sessions run with TERM=xterm-256color.

Community Discussion and Alternatives

Users in the Hacker News community have noted the emergence of several libghostty-based tools, including cmux and zmx, suggesting a growing trend of using Ghostty's core for multiplexing. Some users expressed a preference for Boo's minimal approach, while others noted that the lack of multiple windows per session is a significant departure from the original GNU screen's capabilities.

Sources