Muxy: a SwiftUI terminal for macOS built on libghostty

The problem Muxy targets: many shells, one window, low memory

A typical working day on a Mac now involves several long-lived processes per repository: a shell, a test watcher, a dev server, and increasingly one or more agent CLIs. The README lists amp, claude, codex, gemini and opencode among the repository topics, which tells you who the project is aimed at. The stated vision is a "Lightweight terminal that has a rich API for extensions", and the description positions memory efficiency as the differentiator rather than feature count.

The audience is therefore narrow and specific: macOS developers who already live in a terminal, who keep more than one project open at a time, and who care about what the terminal process costs in RAM when five of them are running. The feature list reflects that. Project groups, vertical tabs, split panes and git worktrees are all about keeping multiple contexts alive in one window rather than opening five separate terminal windows and paying for five separate app processes.

It is not a general-purpose cross-platform terminal. The install section offers Mac, iOS and Android, but the desktop build is macOS only, and the requirements block asks for macOS 14+ and Swift 6.0+.

How Muxy is put together: SwiftUI shell, libghostty core, extension host

The repository layout is the clearest description of the architecture. Package.swift sits at the top level, so the app is a Swift Package Manager project. The top-level directories split the concerns: Muxy/ holds the app itself, GhosttyKit/ holds the terminal core, and MuxyExtensionHost/, MuxyHookBridge/, MuxyHookKit/, MuxyServer/, MuxySession/, MuxySessionProtocol/ and MuxyShared/ are separate modules.

That split matters for anyone evaluating the project. The terminal emulation is not written from scratch. libghostty, the library behind the Ghostty terminal, does that job, and Muxy builds a SwiftUI application around it. The README points at ghostty-org/ghostty for the core. So the interesting engineering is in the shell: session persistence, splits, the extension host, and the hook bridge that lets external processes talk to the app.

MuxyServer/ and MuxySessionProtocol/ suggest a local server plus a protocol layer, which is consistent with the Agent Skills section. The README describes skills that can "Drive the workspace from a shell (open projects, splits, send keys, read panes)", so the app exposes a programmatic surface rather than only a GUI. That is the part most terminals do not have, and it is the main reason to look at Muxy rather than an existing emulator.

Installing Muxy with Homebrew and running it for the first time

The README gives two install paths. Homebrew is the short one: tap the project's own tap, then install the cask. Note that this is a cask, not a formula, because Muxy ships as a macOS application bundle.

brew tap muxy-app/tap
brew install --cask muxy

After that, launching Muxy from Applications should open a window with the tab bar on the left, since vertical tabs are the default layout the README describes. If you prefer not to use Homebrew, the README says to download the latest release from the releases page instead.

For working on the project itself rather than using it, the README documents a four-step local development flow. The first step is not optional: the terminal core is a downloaded artifact, not vendored source.

scripts/setup.sh          # downloads GhosttyKit.xcframework
swift build               # debug build
swift run Muxy            # run
scripts/checks.sh         # format, lint, build, and test in isolated app storage

The setup script fetches GhosttyKit.xcframework, which is why a plain checkout will not build. The checks script runs formatting, linting, build and tests against isolated app storage, so it does not touch your normal Muxy configuration.

One more install step is documented for agent tooling. The README shows two skills being added from the repository, one for driving the workspace from a shell and one for authoring extensions.

npx skills add github.com/muxy-app/muxy/tree/main/Muxy/Resources/skills/muxy-cli
npx skills add github.com/muxy-app/muxy/tree/main/Muxy/Resources/skills/muxy-extension
muxy install-skills

The third command is the shortcut: the README says it installs both skills into every detected AI harness at once, and notes that it requires the Muxy CLI.

Where Muxy gets in the way: beta builds and an undocumented rollback path

The most concrete limitation is release status. The three most recent releases are all 2.0.0 beta tags, and the repository carries a BETA_VERSION file at the top level. Anyone installing through the cask is installing software the project itself labels as beta. That is not a reason to avoid it, but it changes how you should treat it: do not put it in front of a workflow you cannot afford to have interrupted.

The README does not document rollback, and it does not describe a stable channel separate from the beta line. If a beta build breaks your session state, the documented recovery path is to download an older release from the releases page manually. There is no stated downgrade command for the cask.

The extension API is the second place to be careful. The README points at a skill for authoring extensions and names window.muxy as the API surface, but it does not publish a stability guarantee for that API. Building a non-trivial extension against a beta series means tracking changes yourself.

Finally, the platform requirement is a hard boundary. macOS 14+ and Swift 6.0+ are stated in the requirements block. If your team is mixed-platform, Muxy is not the terminal that gives everyone the same environment. It is a Mac-only tool with separate mobile companion apps, not a cross-platform client.

Muxy against tmux and against a plain libghostty build

The name invites the comparison, so it is worth being precise about it. tmux is a terminal multiplexer that runs as a server process and attaches clients to it. Sessions survive the client dying, and the same session is reachable over SSH from a different machine. Muxy is a GUI application. Its session persistence is a feature of the app, described in the README as workspace and session persistence, not a detached server you can reattach to from anywhere. If your reason for using a multiplexer is that your work survives a dropped connection to a remote host, tmux solves that and Muxy does not claim to.

The closer comparison is Ghostty itself. Ghostty is the terminal that libghostty comes from. Muxy uses that same core but wraps it in SwiftUI and adds the surrounding workspace: project groups, git worktrees, a text editor, a Markdown and HTML preview with Mermaid diagrams, an image viewer, and an extension host. If you want the libghostty rendering model and nothing else, upstream Ghostty is the smaller dependency. If you want the workspace features and the shell-drivable API, those are the parts Muxy adds on top, and they are the parts you are actually adopting.

Licence, maintenance and what upgrading costs you

Muxy is MIT licensed. In practice that means you can read the source, fork it, and ship a modified build, provided you keep the copyright notice and licence text with it. It does not impose copyleft obligations on your own code. This is not legal advice, and if you plan to redistribute a modified build, read the LICENSE file at the repository root rather than this summary.

The maintenance signal is the release cadence. Three beta tags landed on 2026-09-14, the same day as the most recent push to main. The repository is not archived. That pattern means active work, and it also means the thing you install today is not the thing that will be there in a month.

The upgrade cost is mostly about state. The README advertises workspace and session persistence, so an upgrade touches whatever format that state is stored in, and the BETA_VERSION file is the project's own marker that the format is not frozen. If you run agent skills against the workspace, the skills-lock.json file at the top level is the other thing to watch, since it records which skill revisions you pulled. Pinning to a specific release tag and re-reading the release notes before moving is cheaper than discovering a state migration after the fact.

Editorial conclusion

Muxy is worth adopting if you run several agent CLIs or long-lived shells per repository on macOS 14 or later, want splits and worktrees in one window, and are comfortable tracking 2.0.0 beta builds rather than a frozen release. Skip it if you need a terminal that is identical on Linux and macOS, if you depend on a stable extension API contract, or if you want a long-term support branch. Before installing, check the requirements block for macOS 14+ and Swift 6.0+, read the BETA_VERSION file and the latest release tag to see which beta you are actually getting, and confirm the Homebrew cask version matches the release you intend to run.

Frequently asked questions

Official sources

1. License: MIT
2. muxy-app/muxy on GitHub
3. Project website
4. README
5. Releases