Working across several projects at once means keeping a lot of terminals alive: development servers, test runners, build watchers, agent sessions. They pile up across windows and tabs with no structure.
Muster is a Rust library and CLI that organizes them into named, color-coded groups. A group is a set of tabs, each with a working directory and an optional startup command, saved as a profile and brought up or torn down with one command.
muster profile save myproject --tab 'Shell:~/work/myproject' --color '#f97316'
muster up myproject # create or reattach
muster status # what's running
muster down myproject # tear it down
State lives in tmux
There is no application cache and no runtime state file. tmux owns all running state (windows, working directories, the active window) and the config directory holds only saved profiles and settings. The group metadata that would normally need a state file (display name, color, profile reference) is stored as tmux user options on the session, so it is created and destroyed with the session. When muster needs to know what a group looks like, it asks tmux.
Changes arrive from tmux as they happen, over control mode, rather than being polled for.
Library first
The tmux bindings (command execution, output parsing, control mode event streaming) are written in-house. Control mode streaming is the part that matters most here, and the one existing Rust tmux crate calls itself experimental and does not provide it.
The workspace is three crates: muster, the library; muster-cli, the binary; and muster-notify, a small macOS helper that lives inside an app bundle so Notification Center will talk to it. The CLI is a thin consumer of the library, and the library has no dependency on any GUI framework, so the same core can back a desktop application later.
Availability
Published on crates.io as muster-cli and muster, dual-licensed MIT/Apache-2.0, with documentation covering the user guide, CLI reference, and architecture.