dmux-rs

Native Rust tmux control-mode renderer for dmux — first-party test ring. You run it; it improves itself. See AGENTS.md for how the loop works and ROADMAP.md for architecture.

Install (one line)

gh api repos/standardagents/dmux-rs/contents/scripts/install.sh -H "Accept: application/vnd.github.raw" | bash

Needs the GitHub CLI logged in (gh auth login) with access to this repo, and tmux ≥ 3.3. Prefer clicking? Grab the binary from the latest release (dmux-rs-macos-aarch64), chmod +x, put it on your PATH.

Use

cd your-project && dmux-rs

That's it. From then on:

Pushing a branch to this repository publishes a branch build: CI runs the full validation gate, then uploads the binary as a prerelease tagged build-<branch>. When a dmux-rs checkout is in your sidebar, the sidebar title row shows a ▾ switcher (also Switch dmux-rs build… in the ^b m menu) listing the latest main release and every branch with a passing build. Selecting one downloads it and hot-swaps in place. A running branch build then auto-reloads whenever its branch publishes a new commit, exactly as main-channel builds follow releases; when the branch or its build disappears from the remote, the running binary stays and a notice appears.

For local iteration before a push, a second terminal can request a worktree build directly:

dmux-rs --prototype-worktree /path/to/dmux-worktree --project /path/to/your-project

The command builds an untagged release binary from the worktree. The running controller re-execs that binary after active input and pane launches settle. --watch keeps the command running. It rebuilds after worktree source changes and hands each successful current build to the controller:

dmux-rs --prototype-worktree /path/to/dmux-worktree \
  --project /path/to/your-project \
  --watch

The active build keeps running when a watched build fails. A later source change starts another build. A worktree build remains outside the published release updater until you start dmux-rs again from an installed release. Each worktree keeps its dependency artifacts in target/dmux-prototype-cache, so later builds usually compile only the dmux crates changed by that branch.

• It stays fresh by itself: every running head polls releases every minute and hot-swaps in place — your tmux sessions, agents, and layout survive the swap (the sidebar shows the current build).
• Using it makes it better: the shadow verifier compares every settled pane against tmux's grid; a divergence auto-files an issue here with the exact bytes to reproduce it (🐛 chip in the sidebar, one issue per pane until the next build reloads you). The fix ships; your head updates; the bug is gone.

Knobs (all optional)

env	effect
DMUX_NO_UPDATE=1	don't self-update
DMUX_UPDATE_INTERVAL_SECS	poll cadence (default 60)
DMUX_NO_REPORT=1	don't auto-file issues
DMUX_VERIFY=0	disable the shadow verifier entirely

Testing

scripts/validate.sh is the complete pre-push gate (quality checks, UI interactions, and rendering fidelity); scripts/check.sh is the fast inner gate for mid-task iteration.

For focused unit tests, note the naming split: the Cargo package is dmux, but it has no library target — all unit tests live in the binary target dmux-rs. So cargo test -p dmux --lib <filter> fails with no library targets found; use the binary target instead:

cargo test -p dmux --bin dmux-rs <filter>   # e.g. … session::tests

Other crates in the workspace (dmux-vt, dmux-cc, dmux-compositor, …) are ordinary libraries where cargo test -p <crate> <filter> works as usual.

Sidebar preview

Contributors can render representative sidebar states through the production renderer without connecting to a tmux server:

scripts/sidebar-preview.sh

The preview covers the standard 40-column sidebar, compact and tiny widths, hover and leader states, diagnostics, and a long status message. ANSI colors are included by default. Use scripts/sidebar-preview.sh --plain for stable text output in a diff.