Byobu: a text window manager and terminal multiplexer for Linux, BSD and Mac

What Byobu actually solves, and for whom

GNU Screen is described in Byobu's own README as functional, plain and practical. That is a fair summary of a multiplexer whose defaults are old and whose status line shows little. Byobu began as a set of enhancements layered over Screen for the Ubuntu server distribution, and the project later extended the same treatment to tmux, which the README calls the more modern terminal multiplexer.

The audience is narrow and specific. You are working over SSH on a Linux, BSD or Mac host, you keep long-running processes in named windows, and you want a status line that tells you something without you writing a config file first. Byobu supplies that status line, a set of keybindings, profiles and a configuration utility. It is not a new multiplexer. Everything it shows you is produced by Screen or tmux underneath.

If you already have a tmux configuration you have tuned for years, Byobu's value proposition mostly evaporates. You would be replacing your own decisions with the project's defaults, and the defaults are the product.

How the Screen and tmux wrapper works

Byobu is a Python project that sits between you and the multiplexer. The repository layout reflects that: the top level holds a Makefile.am, configure.ac, autogen.sh and a usr/ tree alongside etc/, po/ for translations, rpm/ and homebrew/ packaging directories, and an experimental/ directory. There is no compiled daemon and no service to supervise.

The mechanism is a launch path. You run byobu, and the wrapper selects a backend, applies a profile, and starts the multiplexer with Byobu's own configuration. Keybindings and status notifications are toggle-able, which means the status line is assembled from individual pieces you can turn off rather than a fixed layout. The configuration utility is a separate program that edits those settings, and the README notes python-newt is needed only if you want to use it. That separation is the honest part of the design: the utility is optional, and Byobu still runs without it.

The consequence is that Byobu inherits both backends' behaviour and both backends' bugs. A keybinding that conflicts with a tmux default is resolved by whichever layer wins, and the README does not document that precedence. When something behaves unexpectedly, you are debugging two programs, not one.

Installing Byobu from source and running it once

The README's first instruction is to check whether your OS packages Byobu. If it does, use that package. The source path below is the documented fallback for systems where Byobu is not packaged or where you lack administrative privileges.

Pull the upstream source and enter the directory:

git clone https://github.com/dustinkirkland/byobu.git byobu-src
cd byobu-src

GitHub release tarballs do not ship a configure script, so the README says to generate one. Official release tarballs from Launchpad already include it and can skip this step:

./autogen.sh

Configure into a prefix inside your home directory, then build and install:

./configure --prefix="$HOME/byobu"
make
make install

The README also shows how to point Byobu at a Python interpreter from your environment rather than the distribution's, by exporting BYOBU_PYTHON. Add the installed bin directory to PATH and set BYOBU_PREFIX, then reload your shell:

echo "export PATH=$HOME/byobu/bin:$PATH" >> $HOME/.bashrc
. $HOME/.bashrc

Run it:

byobu

You should land in a multiplexer session with Byobu's status line at the bottom. Before any of this works, the README lists tmux at version 1.5 or newer and screen as dependencies, python-newt for the configuration utility, and gsed if your sed implementation does not support the -i flag.

Where Byobu gets in the way

The README does not document rollback. There is no uninstall section, no list of files Byobu writes into your home directory, and no description of what happens to an existing tmux or screen configuration when Byobu first runs. If you install from source into $HOME/byobu, you can remove that prefix, but the README is silent on anything else the first run may create. That is a real gap for anyone evaluating the tool on a machine they care about.

The contribution section is equally candid about process friction. The README asks contributors to commit locally and propose a merge in Launchpad, describing a GitHub pull request as less ideal. For a project hosted on GitHub, that is an unusual arrangement, and it means the review path is not where most developers would look for it. Coding standards are stated in one line: tabs, not spaces.

Byobu is also the wrong tool when the multiplexer is not the point. If you are scripting session creation, running a headless job queue, or embedding terminal management in another program, there is no API documented here. Byobu is a user-facing wrapper, and its interface is keystrokes and a status line.

Byobu versus plain tmux

The comparison people search for is Byobu against tmux, and the difference is one of defaults versus primitives. Tmux gives you a multiplexer with a configuration language and a client-server model; you decide what the status line contains and which keys do what. Byobu gives you a multiplexer plus a set of decisions already made, exposed as toggle-able notifications and profiles.

That trade is legible in the install instructions. Byobu's source build needs autogen.sh, configure, make and make install, plus PATH and BYOBU_PREFIX exports. Tmux installs as a single binary from a distribution package. Byobu's extra machinery buys the status bar and the configuration utility, and it costs you a build step and an environment variable.

A second difference is backend choice. Byobu can drive either Screen or tmux, and the README treats tmux as the more modern option. Tmux drives only itself. If you have old Screen habits or Screen-only hosts, Byobu is the only one of the two that spans both.

Maintenance, licence and upgrade cost

The last push to the repository was on 2026-08-20, and the most recent releases listed are trustmux-v7.19rc7, trustmux-v7.19rc6 and trustmux-v7.19rc5, all release candidates published in August 2026. The repository is not archived. Note the naming: the release tags use a trustmux prefix while the project presents itself as Byobu, and the README's own text is dated 2023-11-22, so the documentation and the release stream are not moving at the same pace.

Upgrade cost depends on how you installed it. A distribution package is upgraded by the distribution. A source install into $HOME/byobu is yours to rebuild: re-run configure, make and make install against the new tree. The README does not describe an upgrade procedure or a migration step between versions, so treat each source upgrade as a fresh install over the same prefix.

Byobu is GPL-3.0, and the README points at the COPYING file in the repository for the full text. The practical implication for most readers is that if you redistribute Byobu or a modified version, the licence's source-availability terms apply. Whether that matters for your specific distribution is a question for your own legal review, not something this article can settle.

Editorial conclusion

Adopt Byobu if you want a status bar, profile-based keybindings and a configuration utility on top of Screen or tmux, and you are willing to install it from source when your distribution does not package it. Skip it if you need a documented rollback procedure, a published API, or you already maintain a tmux configuration you are happy with, since Byobu's own README does not describe how to reverse its changes. Verify first that tmux is at least 1.5 and that screen is present, because the README lists both as dependencies, then run byobu and open the configuration utility to see whether python-newt is installed.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes