HN Explorer

Show HN: Rmux – A programmable terminal multiplexer with a Playwright-style SDK (github.com)

194 points by shideneyu ↗ HN
Author here. RMUX started from a frustration: I've used tmux for years and got tired of scraping output with grep and sleeps to automate anything. So I rebuilt the multiplexer from scratch in Rust, with a programmable layer on top.

Two surfaces: a tmux-compatible CLI (~90 commands, your keybindings just work), and a typed async Rust SDK on the same daemon — stable pane IDs, structured snapshots, locator-style waits. The idea is Playwright-style automation, but for terminals.

Native on Linux, macOS, Windows (real ConPTY, no WSL).

Demos and docs at rmux.io. Happy to answer questions about the daemon protocol, ConPTY, or the SDK design.

39 comments

[ 4.5 ms ] story [ 440 ms ] thread
[deleted]
(comment deleted)
Sirental
The website is a little too obviously made by Claude. The first thing I noticed is the classic "pill with pulsing green dot that says something is active or live" claudism.
perseusai
As someone new to this site, I understand wanting to keep the AI Slop at bay, but for some of us, it's been a boon to get our ideas into an actual working application. I have decades of IT/Network/Enterprise experience, but creating and writing a complex tool would have been well beyond my abilities or patience. I had a friend say that AI is a "scourge on the intellectually lazy" and I couldn't really refute that, but I had to add that it is a boon to a lazy intellectual, which I consider myself to be.
Sirental
I'm not saying don't use AI. It's alright to use AI in my books, I'm just saying watch out for obvious hints. Some people translate that to "this product is cheap" even if it isn't at all the case.

I understand you've put a hell of a lot of work into this. You might want to have a look at https://www.awwwards.com/ and take some inspiration for some of the designs, then write up a general spec sheet of how the website should look and feed that into Claude.

Otherwise Claude just does what a language model does best, and regurgitates a lot of the same styles.

small_model
Never had the need to do playwright automation for tmux, so not sure why I would use this above tmux which works well.
kosolam
Hey, I automate tmux all the time with send keys and capture.. how is your project improves vs tmux or zellij?
cultofmetatron
a week ago I was using cmux but its osx only and doen't work on remote terminals. then I switched to herdr which is great so far except its not s great at managing panes. I can't move them around or change ordering. now another terminal multiplexer. I'm getting whiplash.

all that said, none of the existing solutions are perfect and rust codebases are nice. how easy is it to reorder panes? is there a cli that lets me control the panel layout via a skill file and allow my opencode session to target and send data to other panes?

qudat
I built https://zmx.sh to make it easier to interact with your terminal sessions programmatically. 1 window = 1 session which might feel like a negative but it makes programmatic access easy and agents can use it just by pointing it at the zmx help command. Basically, an agent just needs 2 commands (run and write) for full control and the commands are synchronous so you don’t need to do any polling.
ogulcancelik
hey, i’m the herdr dev. pane reordering will be in the next release, let me know if you have more feedback :)
luizfwolf
I found the project quite interesting but what's the advantage over just using tmux with a hotkey to send keys?
saghm
Writing shell scripts to orchestrate things is not a particularly great experience. "Shell scripts are annoying to write compared to the programming languages we use for other things" isn't a universal opinion, but it's not exactly uncommon; I've heard plenty of people talk about switching to Python as soon as anything gets even moderately complex. (I often tend to go with the lines "my bar for when to switch to a real programming language is as soon as I have to write an if statement" and "the number of times I've had to write a for loop in bash is the same as the number of times I've had to google the syntax for a for loop in bash", which are only slight exaggerations). Having an actual library for interactions that isn't just a wrapper around the CLI seems like it would be a huge improvement for anything that isn't a one-off interaction.
elromulous
Can someone describe the pros/cons vs zellij?
florianist
The paragraph on the website inviting us to switch to rmux from tmux claims that tmux is programmed in C++. tmux is made in C.
DeathArrow
1. ask Claude to rewrite X in Rust

2. ask Claude to make a website and claim R is better than X because it's Rust

3. advertise on HN, X and Reddit

4. ???

5. profit!

cat-whisperer
I used to use ghostty's applescript and built that into a claude skill. It worked like a charm. But this feels super interesting for programmability
0x1ceb00da
Getting this error when installing from git bash:

$ curl -fsSL https://rmux.io/install.sh | sh rmux install: unsupported OS: MINGW64_NT-10.0-26200

shideneyu
Hello ! I just updated rmux, you can run the command again, it should work ! Thank you for your curiosity and support
kloud
Cool project, I like the idea of having tmux-compatible CLI. I used Zellij to get better UX, but many agent tools integrate with tmux. This way agent tools can still integrate tmux as a defacto standard for programmatic interface while having better interface for users.

But I wonder if tmux/rmux design is suboptimal since it couples session persistence and window management together. Do you have an opinion the design which separates the responsibilities? An example that pioneered this approach is abduco, and libghostty-based zmx being a modern implementation.

[deleted]
(comment deleted)
pama
Congrats on the launch. If emacs was unavailable and I needed tmux, I would try it. I am old school, and use emacs daemons for all shell multiplexing. The agents dont need explanations and know how to use emacsclient to create, read, or send inputs to named buffers that run the shells. Elisp is powerful, so manipulating windows is a breeze. Lots of people on tmux would benefit from this design though.
deangiberson
Funny, I started vibing this (https://github.com/deangiberson/emacs-mux) yesterday on the train after playing with cmux for the day and thinking to myself there was nothing that emacs couldn't accomplish.

The repo doesn't quite work yet. Many sharp corners. But the basic idea is there.

pama, I'd be interested in hearing more about how you are using emacs for multiplexing. I'm trying to build up tooling for myself based around file and input workflows and I /really/ don't want to write a text editor and would prefer to stick with emacs.

pama
The key idea is to have many differently named shells. Typically, I group them by project (common prefix name), and the projects live in directories. I have some hacks to organize ibuffer, to split frames, to reflow buffers in the existing windows (eg to organize related project buffers (shells, magit, dired), or to show shells from multiple projects, or selected buffers, and so on). Emacs’ natural frame splitting and buffer selecting/switching commands are good enough if you dont display more than four buffers at a time, but soon you may need to show 5, 6, 8, 9, 10, 12, 15, 16, 18, 20, 24 or have funky arrangements, so you may collect functions to help along splitting n*m grids or keeping useful splits. The shells work very organically inside Emacs and you can still use it as a text editor. The so-called “dumb terminal” in M-x shell is a thing of beauty as it really is just a text buffer like any other; I think of it as a bash repl. If you are used to curses TUI commands it may not work, so for these rare occasions I also use eat (but tend to avoid). See also answer to a sibling comment.
notorandit
Scriptable terminal multiplexer?

Interesting portable scripting thingy. But it would only work with portable tools, not just everything. Especially with Windows tools.

yes_but_no
Floating panes seems not possible, or are they?
btown
Very cool! I think the hype around “agents are so good that you never actually need to see the underlying commands they are running or interact with the terminal session that they’re running” misses out on a lot of very important use cases, particularly around long running processes that may be shared across multiple agents. This will be very cool to see how best practices evolve!
joch
Very nice!

I created `ygg`[0] a while back to easily spawn a new worktree when working with Claude/codex, and it also spawns that in a dedicated zellij tab. I think making the terminal multiplexer pluggable, so it would be easy to integrate something like this.

[0] https://github.com/joch/ygg

SwellJoe
It's not clear to me what this does that tmux doesn't? Agents can already interact with tmux, so what does this provide?
shadowfax92
this might fit very nicely with gascity/gastown which orchestrates other coding agent over tmux.

currently, i finds it's tmux orchestration code is too complex.

will check it out