RMUX: a Rust terminal multiplexer with a typed SDK

What RMUX is for, and who it is not for

The problem RMUX addresses is narrow and specific. A program that wants to control an interactive terminal application, whether that is a shell prompt, a full-screen TUI, or an agent that expects a live terminal, cannot simply pipe input into a process and read stdout back. Interactive programs check whether they are attached to a terminal, redraw regions of the screen, and respond to keystrokes rather than lines. RMUX puts a real pseudo-terminal behind those programs and exposes it through a client API, so the caller sends keys and receives rendered state instead of raw bytes.

That positioning matters more than the multiplexer label. The Cargo.toml describes the crate as "a local terminal multiplexer with a tmux-style CLI, daemon runtime, Rust SDK, and ratatui integration." The word local is doing real work. This is not presented as a way to keep sessions alive on a remote host; it is a way to own terminal sessions from your own process on the same machine. If your requirement is surviving an SSH disconnect, you already have tools for that, and RMUX is not claiming to replace them.

The audience is therefore developers building automation, test harnesses, or agent tooling around interactive programs, on Linux, macOS or Windows. The README states native support on all three, and the repository carries a resources/windows/rmux.exe.manifest file, which is consistent with Windows being a first-class target rather than an afterthought.

Daemon, protocol crates, and the SDK surface

The workspace layout in Cargo.toml is the clearest description of how RMUX is put together. The members list separates rmux-types, rmux-proto, rmux-core, rmux-os, rmux-ipc, rmux-pty, rmux-client, rmux-server, rmux-sdk, rmux-render-core, ratatui-rmux and rmux-web-crypto. Reading that list, the data flow runs from a server process that owns PTYs through an IPC layer to a client, with types and protocol definitions shared across the boundary.

The release profile reinforces the split. rmux-core and rmux-server are built at opt-level 3, while rmux-ipc, rmux-os, rmux-proto, rmux-pty, rmux-types and the rmux binary itself are built at opt-level "s" with strip = "symbols". The project is trading some throughput in the plumbing layers for a smaller binary. rmux-web-crypto is the exception in a different direction: codegen-units = 1, opt-level 3, and strip = false, which suggests it is performance-sensitive and kept debuggable.

The SDK is not Rust-only. The README links the Python SDK on PyPI as librmux and the TypeScript SDK on npm as @rmux/sdk. A typed SDK is the actual differentiator here. Instead of parsing terminal escape sequences yourself, you call into a client library that knows the shape of the protocol. The ratatui-rmux crate and the ratatui topic suggest the same rendering model used by ratatui is available to consumers.

Installing RMUX and starting a first session

The root package is published. Cargo.toml sets publish = true on the rmux package while the workspace sets publish = false, so the binary crate is the published artifact and the internal crates are not. The package name is rmux, version 0.10.0, and the repository field points at https://github.com/Helvesec/rmux.

The README's Installation section is the entry point for getting the binary, and the homepage at https://rmux.io is the project's own site. The README excerpt available here does not spell out the exact install command or the subcommand names, so the Installation, Quick Start and Demos sections of the README, plus the examples at https://rmux.io/docs/examples/, are where those live. Inventing a command line here would be worse than sending you to the source.

The README's sidebar links two SDK packages by name, which is the concrete install information the README does give:

pip install librmux

npm install @rmux/sdk

The Python package is librmux on PyPI and the TypeScript package is @rmux/sdk on npm. What you should see after installing either one is a client library that can connect to a running RMUX server; the README does not document what happens if no server is running, so treat that as the first thing to test.

Where RMUX will frustrate you

The licence metadata is the first thing to slow you down. The repository's LICENSE field resolves to NOASSERTION, yet the workspace Cargo.toml declares license = "MIT OR Apache-2.0" and the tree contains both LICENSE-APACHE and LICENSE-MIT. A dual MIT/Apache-2.0 grant is a common and permissive arrangement in Rust, but the discrepancy between the declared SPDX expression and the repository metadata means anyone doing a compliance review has to open the LICENSE file and read it rather than trust the field. That is a small amount of work, and it is work you should not skip.

The second limitation is scope. The crate description says local. Nothing in the repository describes remote session attachment, reconnection semantics, or what happens to sessions when the daemon is restarted. The README does not document rollback or recovery behaviour, and there is no mention of session persistence guarantees. If your mental model of a multiplexer comes from tmux, where detach and reattach across a network is the whole point, RMUX will not match that model.

The third is maturity signal. The most recent release listed is v0.10.0 from 2026-08-04, with v0.9.1 and v0.9.0 in the weeks before that. A 0.x version series with rapid point releases means the API surface is still moving. The repository was last pushed on 2026-08-09 and is not archived, so work is happening, but a 0.x version number is a statement about stability, not a formality.

RMUX against tmux and Zellij

The honest comparison is with tmux, because RMUX adopts its CLI style deliberately. The difference is not the keybindings; it is the intended caller. tmux is built for a human at a keyboard who wants to split panes and detach sessions. Its scripting interface exists, but it is a control channel bolted onto a tool designed around interactive use. RMUX inverts that: the SDK is a workspace member alongside the server and the protocol crates, which means programmatic control is part of the architecture rather than an add-on.

Zellij occupies a different position again. It is a terminal workspace aimed at interactive users, with its own layout and plugin model. If you want a multiplexer to sit in front of a person, both tmux and Zellij are further along the path of being finished products, and RMUX's 0.x version number reflects that it is not trying to win that comparison yet.

The practical test is what your code needs to do. If it needs to spawn an interactive program, send it input, and observe structured output, the typed SDK is the reason to pick RMUX. If it needs to give a human a persistent workspace they can detach from and come back to, RMUX is the wrong tool and the README's own description of it as local tells you so.

Upgrade cost and what the release cadence implies

Three releases in roughly three weeks, v0.9.0 on 2026-07-18, v0.9.1 on 2026-07-24 and v0.10.0 on 2026-08-04, is a fast cadence. For a pre-1.0 project that is normal, but it has a cost: pinning matters. If you depend on the Python package librmux or the npm package @rmux/sdk, an unpinned dependency will pull minor versions that may change behaviour between patch releases. Pin the version you have tested and move deliberately.

The workspace structure helps here. Because rmux-types and rmux-proto are separate crates, a protocol change is visible in the version graph rather than hidden inside a monolith. That does not make upgrades free, but it makes them legible. Watch CHANGELOG.md, which is present at the top level, before bumping.

On licensing, the declared MIT OR Apache-2.0 in Cargo.toml is permissive and typical for Rust projects, but this is not legal advice and the NOASSERTION metadata means you should read LICENSE, LICENSE-APACHE and LICENSE-MIT directly. If your organisation has a policy of trusting SPDX metadata alone, this repository will fail that check until the metadata is reconciled.

Editorial conclusion

Adopt RMUX if you are writing Rust, Python or TypeScript that has to drive an interactive CLI or TUI program and you want a typed client instead of screen-scraping a pipe. Do not adopt it if you only need to attach to a remote shell over SSH and keep it alive across disconnects; that is what tmux and GNU Screen already do, and RMUX is described as a local multiplexer. Before committing, install the published crate, confirm that the Cargo.toml package name rmux matches what cargo installs for you, and read LICENSE, LICENSE-APACHE and LICENSE-MIT yourself to confirm the terms your legal team will accept.

Frequently asked questions

Official sources

1. Helvesec/rmux on GitHub
2. Issues
3. Project website
4. README
5. Releases