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

The Playwright-style snapshot/wait layer is the interesting part to me. A lot of agent terminal automation still breaks because the tool can send keys but can't prove which pane or terminal state it actually reached. Stable pane IDs plus explicit waits should make replay and debugging much saner than the usual grep+sleep loops.

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.

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.

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.

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!

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.

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?

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

I found the project quite interesting but what's the advantage over just using tmux with a hotkey to send keys?

Scriptable terminal multiplexer?

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

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

Hey, I automate tmux all the time with send keys and capture.. how is your project improves vs tmux or zellij?

Never had the need to do playwright automation for tmux, so not sure why I would use this above tmux which works well.

Floating panes seems not possible, or are they?

Can someone describe the pros/cons vs zellij?

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!

[dead]