Skip to content
cyber-muxcyber-muxcyber-mux

Introduction

cyber-mux is a small CLI for cross-multiplexer pane control. It gives you one way to drive panes — open, send, submit, read, wait, focus, close, list, exists — regardless of the terminal multiplexer you happen to be inside. It also manages git worktrees bound to a workspace, and can build a whole named template of panes in one call.

Today it supports seven backends:

  • tmux — the ubiquitous terminal multiplexer (tmux).
  • rmux — an async Rust reimplementation of the tmux command language (Helvesec/rmux) that runs natively on Linux, macOS, and Windows — the first backend here to run natively there. Built and verified against a live rmux 0.10.0 on Linux; the Windows and macOS claim is about rmux’s own portability and has not been exercised there.
  • herdr — an agent-aware multiplexer (herdr.dev).
  • WezTerm (alpha) — a GUI terminal with a built-in multiplexer (wezterm.org), driven through wezterm cli. Verified against WezTerm 20240203-110809-5046fc22 — a headless wezterm-mux-server CI’s live-backends job drives on every pull request.
  • Zellij (alpha) — a terminal workspace with a built-in multiplexer (zellij.dev), driven through zellij action. Requires Zellij ≥ 0.45.0, and is verified against exactly that version in the same live-backends job — the suite runs at the floor rather than above it.
  • cmux (alpha) — a Ghostty-based macOS terminal built for AI coding agents (cmux.com), driven through cmux CLI. Read off cmux’s own Swift source rather than a live binary — it is a macOS GUI app, which CI’s Linux runner cannot drive, so treat it as unverified until confirmed against a real cmux session.
  • otty (alpha) — a native terminal-centric workspace for AI coding agents (otty.sh), driven through otty CLI. Built from the otty docs rather than a live binary — another desktop GUI app CI cannot drive, so treat it as unverified until confirmed against a real otty session.

It is kept deliberately narrow: it drives panes and nothing else. No mail, no dispatch, no agent registry — those live in the tools that build on top of it. Those tools can skip the CLI and import the same core directly — see the Library API.

Try it

Section titled “Try it”
Terminal window
# What multiplexer am I in?
npx cyber-mux doctor


# Just the backend name (tmux / rmux / herdr / wezterm / zellij / cmux / otty / none)
npx cyber-mux mode

doctor reports the detected multiplexer, your current pane, and a fast-path pin you can export to skip detection entirely.

Where next

Section titled “Where next”
  • Multiplexers — the tmux, rmux, herdr, WezTerm, Zellij, cmux, and otty backends and how their feature sets differ.
  • Detection — how cyber-mux figures out where it is running.
  • Templates — named, reusable pane pools.
  • Worktrees — git worktrees bound to a workspace.
  • agent — inspect and wait on a pane’s agent-lifecycle state.
  • AXI — the agent-facing output contract every command follows.
  • Library API — import the core directly instead of shelling out to the CLI.
  • CLI Reference — the full verb surface, one page per command.