RMUX est un multiplexeur de terminal écrit en Rust, pensé pour piloter des sessions, des panes et des applications CLI depuis du code. Après un vrai essai local, mon verdict est simple : ça marche, c’est prometteur pour l’automatisation, mais ce n’est pas encore le remplaçant évident de tmux pour tout le monde.
RMUX, c’est quoi ?
RMUX se présente comme un moteur universel de multiplexage. En clair, il reprend une grande partie de la surface de commandes de tmux, mais il ajoute une couche typée pour les développeurs : SDK Rust, SDK Python, SDK TypeScript, daemon local, captures de panes, attentes sur du texte visible, sorties JSON et mode web share.
L’idée utile, surtout côté DevOps, ce n’est pas juste de garder un shell ouvert. C’est de pouvoir dire depuis un programme : crée une session, lance cette commande, attends que tel texte apparaisse, récupère ce qui est affiché, puis nettoie. Pour piloter une CLI, une TUI, un agent de code ou un outil de diagnostic, c’est plus propre que des scripts expect bricolés.
| Point testé | Résultat |
|---|---|
| Version testée | RMUX 0.8.0 depuis le dépôt GitHub |
| Plateforme | Linux x86_64 en conteneur |
| Installation | Build Rust puis installation Cargo depuis le dépôt |
| Surface de commandes | 90 commandes listées par rmux list-commands |
| Cas réel | Session détachée, commande injectée, attente de texte, capture de pane, split |
| SDK | Exemples Rust officiels lancés contre le daemon local |
Installation de RMUX
Le README propose plusieurs méthodes : Homebrew, Winget, paquets Linux, Nix, téléchargement direct et Cargo. Pour ce test, j’ai cloné le dépôt dans /tmp, puis j’ai compilé et installé depuis les sources.
Le premier point à noter : la toolchain Rust du système était trop ancienne. Le build a refusé Rust 1.85, car certaines dépendances demandaient Rust 1.88 ou plus. Avec Rust stable 1.96.1, le build est passé.
Les commandes principales de mon test :
git clone https://github.com/Helvesec/rmux /tmp/rmux-scout
cd /tmp/rmux-scout
cargo build --workspace --locked
cargo install --path . --locked --debug
rmux -V
rmux diagnose --human
La compilation complète a pris plusieurs minutes, ce qui est normal pour un workspace Rust avec daemon, IPC, SDK, crypto web share et intégrations terminal. Une fois installé, rmux -V a renvoyé rmux 0.8.0.
RMUX à l’usage
Je voulais éviter le faux test qui se limite à afficher une version. J’ai donc lancé une vraie session détachée, injecté une commande shell, demandé à RMUX d’attendre un texte visible, puis capturé le contenu du pane.
Voici le scénario :
rmux new-session -d -s scout -x 100 -y 28 bash
rmux send-keys -t scout:0.0 -l "printf 'RMUX demo: build audit\n'; uname -srmo; printf 'Repo files: '; find /tmp/rmux-scout -maxdepth 2 -type f | wc -l; printf 'Checksum sample: '; printf rmux | sha256sum | cut -c1-16; printf '\nDone from inside RMUX pane\n'"
rmux send-keys -t scout:0.0 --wait-visible-text "Done from inside RMUX pane" --timeout 10s -- Enter
rmux capture-pane -p -t scout:0.0 -S -30
rmux split-window -h -d -t scout:0.0 "printf 'split-pane-ready\n'; sleep 2"
rmux list-panes -t scout
rmux capture-pane -p -t scout:0.1 -S -10
rmux kill-session -t scout
Ce que ça a produit concrètement : RMUX a gardé une session locale, envoyé une ligne de commande dans le shell, attendu que la phrase Done from inside RMUX pane soit rendue, puis m’a donné le contenu visible du terminal. Dans ce contenu, on voit le noyau Linux, le nombre de fichiers repérés dans le dépôt et un petit checksum calculé dans le pane.
Le split de pane a aussi fonctionné : list-panes a affiché deux panes, un actif en 50x28, un second en 49x28, puis la capture du second pane contenait split-pane-ready. Ce n’est pas spectaculaire visuellement, mais c’est exactement le genre de détail qui compte pour de l’automatisation fiable.
RMUX avec son SDK Rust
Le gros intérêt de RMUX est le pilotage typé. J’ai donc lancé plusieurs exemples officiels du SDK Rust :
cargo run -p rmux-sdk --example sdk_demo_snapshot
cargo run -p rmux-sdk --example sdk_demo_split_window
cargo run -p rmux-sdk --example collect_until_exit
L’exemple snapshot a produit du texte visible depuis un pane :
visible text:
user@rmuxio:~/workspace$ uname -s
Linux
L’exemple split a créé un pane via le SDK et a confirmé :
split pane: split:0.1
visible panes: 2
L’exemple de collecte a terminé avec :
collected 14 bytes (truncated=false, lagged=false, missed=0)
C’est là que RMUX devient intéressant. Pour un usage freelance sécu ou DevOps, on peut imaginer des scripts qui lancent un scanner, attendent une bannière, capturent un résultat, relancent un pane, ou orchestrent plusieurs outils CLI sans parser un pseudo terminal à la main.
Ce que j’aime dans RMUX
Premier bon point : le modèle est local. Les sessions, les shells et les panes restent sur la machine. Le web share existe, avec un discours sécurité ambitieux, mais le coeur du produit ne dépend pas d’un service cloud.
Deuxième bon point : l’API d’attente sur le texte visible est vraiment pratique. Dans mon test, l’option d’attente sur texte visible a évité de mettre un sleep 3 fragile. Pour de l’automatisation, c’est une différence nette.
Troisième bon point : la compatibilité tmux n’est pas un simple argument marketing. rmux list-commands m’a listé 90 commandes, avec des classiques comme new-session, send-keys, capture-pane, split-window, list-panes et display-message.
J’aime aussi la présence des sorties JSON pour certaines commandes et le diagnostic humain, qui expose la version, l’OS, le chemin de socket et les capacités.
Les limites de RMUX
La première limite, c’est la maturité perçue. Le projet est déjà dense, mais l’écosystème autour de tmux est énorme. Si vous avez dix ans de config tmux, des plugins, des raccourcis et des habitudes, RMUX ne va pas tout remplacer en une soirée.
La deuxième limite, c’est l’installation depuis source. Elle a fonctionné, mais uniquement après mise à jour de Rust. Pour un outil terminal grand public, ce détail peut faire perdre du monde. Les paquets précompilés existent, mais sur une machine de CI ou un conteneur minimal, il faut vérifier la toolchain.
Troisième limite : certaines options restent austères côté aide CLI. Le help est très proche de tmux, mais il explique peu. On sent que la documentation web et les exemples SDK sont indispensables pour comprendre la valeur réelle.
Enfin, je n’ai pas validé ici le web share ni le comportement Windows natif. Ce test couvre le coeur local Linux, pas tout le périmètre annoncé.
Faut-il adopter RMUX ?
Mon verdict : essayer, surtout si vous automatisez des CLI ou des TUI. RMUX marche vraiment sur le cas que j’ai testé : création de session, injection de commande, attente de texte, capture, split et SDK Rust.
Je ne le mettrais pas encore partout comme remplacement brutal de tmux sur mes serveurs. En revanche, je le garderais dans ma boîte à outils pour des agents, des tests de terminaux, des workflows CI qui doivent piloter une CLI interactive, ou des prototypes d’orchestration locale.
Pour un utilisateur classique qui veut juste détacher une session SSH, tmux reste plus évident. Pour un développeur qui veut piloter le terminal depuis du code, RMUX mérite clairement un essai.
FAQ
RMUX remplace-t-il tmux ?
Pas forcément. Il reprend une grande partie de la surface tmux, mais son angle fort est l’automatisation typée et multi plateforme. Si tmux vous suffit, pas besoin de migrer dans l’urgence.
RMUX a-t-il besoin d’une clé OpenAI ou OpenRouter ?
Non pour le coeur testé ici. Mes essais n’ont utilisé aucun LLM : seulement le daemon local, la CLI et le SDK Rust.
RMUX est-il utile pour des agents autonomes ?
Oui, potentiellement. Sa capacité à créer des panes, envoyer des touches, attendre du texte visible et capturer l’état d’un terminal colle bien aux agents qui doivent contrôler des outils CLI réels.