# coder/boo: a screen-style multiplexer that redraws from Ghostty terminal state

> boo keeps GNU screen's session model but replaces the decades-old emulator with libghostty-vt, so detached sessions can be read and scripted exactly as a human would see them. The trade-off is a young tool with a narrow command set.

**coder/boo** — A GNU screen style terminal multiplexer built on libghostty.

- Repository: https://github.com/coder/boo
- Stars: 792 · Forks: 24
- Language: Zig
- License: MIT
- Published: 2026-09-17 · Updated: 2026-09-17 · Language: en
- Canonical page: https://hysenlabs.com/projects/coder-boo

## What coder/boo solves, and for whom

The README frames the problem in one line: sessions that survive disconnects. Detach with Ctrl-A d, reattach with boo attach, and the process keeps running. That much every multiplexer does.

The narrower problem is what a detached session knows about itself. boo parses every session's output through libghostty-vt, Ghostty's VT core, so the daemon holds the exact screen state: contents, styles, cursor, scrollback and terminal modes. On attach it replays that state instead of dumping a byte log. While detached it can answer terminal queries, which the README says prevents TUIs from hanging unattended.

That second property is what makes the project interesting to a specific audience. The topics list includes ai and coding, and the README calls boo "a natural sandbox for scripts and AI agents driving interactive programs." If you write automation that has to type into a full-screen program and read what comes back, the screen-state model is the whole point. If you just want tabs and panes in one terminal, it is not.

## The client, the daemon and the replay path

The architecture section gives a three-part diagram. Your terminal talks raw TTY to a boo client. The client talks over a Unix socket to a session daemon. The daemon owns a PTY-attached child whose output feeds a persistent ghostty-vt TerminalStream.

The client puts your TTY in raw mode and shuttles bytes over a framed Unix-socket protocol defined in src/protocol.zig. The daemon is forked when a session is created. While you are attached, output is passed through byte for byte, so there is no rendering layer between the child and your terminal. On attach, the daemon sanitizes your terminal and replays the screen from libghostty state.

That split explains both the strengths and the constraints. Because the daemon keeps a parsed TerminalStream rather than a raw log, peek can print an ordered, fully redrawn screen, and wait can block on text appearing. Because the model is screen's (sessions, a prefix key, nothing else), there are no panes or windows to manage. One session per task, with boo ui to juggle them.

## Installing boo and running a first headless session

For Linux and macOS the README gives a single install script. It fetches the binary for your platform; the default install location is /usr/local/bin when writable, otherwise ~/.local/bin. Set BOO_VERSION to pin a release and BOO_INSTALL_DIR to change the location.

```bash
curl -fsSL https://raw.githubusercontent.com/coder/boo/main/install.sh | sh
```

Pre-built binaries are also published on the releases page if you would rather not pipe a script into a shell. Once installed, boo new with no name starts a session running $SHELL and attaches you to it. The README notes that an unnamed session takes the current directory's name, falling back to the process id when that name is taken or unusable.

The automation loop is where the design shows. Each step below is taken from the README's canonical example: create a detached session running bash, type a command into it, wait for output to settle, read the screen, then clean up.

```bash
boo new build -d -- bash
boo send build --text 'make' --enter
boo wait build --idle
boo peek build --scrollback
boo kill build
```

wait --idle blocks until output has been quiet for 2 seconds. peek --scrollback prints the rendered screen including history; add --json to get size, cursor and title as well. Everything except attach works without a terminal, which is what makes the loop usable from CI or an agent process. Exit codes are 0 for success, 1 for error, 2 for usage error, 3 for no such session, and 4 when a wait times out.

## Where boo is the wrong tool

The feature list is deliberately short, and the README is candid about the shape of the project: "sessions, a prefix key, and nothing else to learn. One session per task." There is no mention of panes, split windows, layouts, copy mode, or a configuration file. If your workflow depends on splitting one terminal into four panes and resizing them, boo does not offer that, and the README does not claim it will.

The key binding table covers detach, redraw and sending a literal Ctrl-a, plus additional bindings inside boo ui for switching, resizing and hiding the sidebar, creating sessions and killing them. That is the documented surface. Anyone who relies on a large personal keymap, status-line scripting or a plugin ecosystem will find nothing to hook into here.

The dependency is worth weighing too. libghostty is fetched and built from source automatically and pinned in build.zig.zon, and contributing requires Zig 0.15.2. Building from source therefore pulls in Ghostty's VT core and needs a specific compiler version. The install script and the pre-built release binaries exist precisely to avoid that, but if your platform is not among the published builds, the source path is the only one, and the README does not document a fallback for that case.

## boo against tmux and GNU screen

The README addresses both neighbours directly. On screen: it works the same way architecturally, parsing all output through a built-in terminal emulator and redrawing from that state on reattach, but that emulator is decades old and lags behind what modern programs emit. Whatever it does not understand gets dropped or mangled on redraw. boo swaps that layer for libghostty-vt, so the saved state matches what your terminal would display, and terminal queries are answered while detached.

On tmux, the README is explicit that it "solves a different problem." The difference in approach is real: tmux gives you a window and pane hierarchy inside a server, plenty of configuration, and a command language for scripting it. boo keeps screen's flat model of independent sessions and adds typed automation primitives instead: send --text is literal, with no escape processing, no implicit newline and no quoting layer; --enter submits and --key Enter,C-c,Up names control keys; stdin mode is binary safe. wait --text blocks until the screen contains a given string, which replaces the sleep-and-poll loop that -X stuff and hardcopy files otherwise force on you.

So the choice is not which multiplexer is better. It is whether you want a hierarchy you configure, or a flat set of sessions you drive from a script.

## Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-07-05, the same day as the v0.6.4 release. Releases v0.6.3 and v0.6.2 landed on 2026-06-26 and 2026-06-25, so the recent cadence is a patch release roughly every one to two weeks across those three versions. There is no published roadmap in the README, and it does not document a deprecation policy or a migration path between versions.

The practical upgrade cost sits in the pinned libghostty revision. The README states that the dependency is fetched and built from source automatically and pinned in build.zig.zon, which means a boo upgrade can move the VT core underneath you. If you build from source, expect Zig 0.15.2 and a libghostty build in the loop; the Nix flake provides nix develop for the right Zig version and nix build for the package. If you install from the script or a release binary, set BOO_VERSION to pin, and treat a version bump as something to try against your own interactive programs before rolling it out.

The licence is MIT, per the repository's LICENSE file and the licence badge in the README. That is permissive and places few obligations on how you redistribute or embed boo, but the usual caveat applies: the libghostty dependency is fetched separately and carries its own licence, which the README does not state. If you vendor or ship boo, check that dependency's terms yourself rather than assuming MIT covers the whole build.

## Conclusion

boo fits engineers who want screen's prefix-key model but need detached sessions that answer terminal queries and can be scripted headlessly. It is the wrong pick if you depend on tmux's panes, scripting language or plugin ecosystem, or if you need a multiplexer whose behaviour has been settled by years of production use. Before adopting it, check the release page for a build for your platform, confirm the pinned libghostty revision in build.zig.zon, and run the canonical loop (new -d, send, wait --idle, peek --json, kill) against the interactive program you actually intend to drive.

## FAQ

### How do I set up Coder?

For coder/boo on Linux and macOS, the README gives a single install script that fetches the binary; pre-built binaries are also on the releases page. Set BOO_VERSION to pin a release and BOO_INSTALL_DIR to change the install location.

### What is coder/boo?

It is a GNU screen style terminal multiplexer built on libghostty (libghostty-vt) and written in Zig. Sessions survive disconnects, and every session's output is parsed through Ghostty's terminal emulation core so boo knows the exact screen state of each one.

### How is coder/boo related to GNU screen?

It keeps screen's model by design: sessions, a prefix key, and nothing else to learn, with Ctrl-a bindings that follow screen's defaults including the C-x variants. The difference is the emulation layer, which is libghostty-vt instead of screen's decades-old built-in emulator.

### Can boo be driven by scripts or AI agents without a terminal?

Yes. Everything except attach works without a terminal, and the README describes boo as a natural sandbox for scripts and AI agents driving interactive programs. The primitives are send, peek, wait and --json output, with wait --timeout exiting 4 rather than hanging.

### What does boo peek print compared with a raw log?

peek prints the rendered screen reconstructed from terminal state: ordered, fully redrawn and stable, not a raw byte log. --scrollback includes history, and --json adds size, cursor and title.

### What do I need to build coder/boo from source?

Zig 0.15.2. zig build produces the binary in zig-out/bin/boo, and the libghostty dependency is fetched and built from source automatically, pinned in build.zig.zon. With Nix, nix develop opens a shell with the right Zig version.

## Sources

- [coder/boo on GitHub](https://github.com/coder/boo)
- [Issues](https://github.com/coder/boo/issues)
- [License: MIT](https://github.com/coder/boo/blob/main/LICENSE)
- [README](https://github.com/coder/boo/blob/main/README.md)
- [Releases](https://github.com/coder/boo/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/coder-boo