Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

  • Hacker News
  • Scriptable terminal multiplexer?

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

  • I wrote it for rust apps in mind, same usecase as for Ratatui. You’re right maybe I need to expose more tools with the cli
  • 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
  • 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

  • noted, I'll check this out, thank you
  • Hello ! I just updated rmux, you can run the command again, it should work ! Thank you for your curiosity and support
  • It's not clear to me what this does that tmux doesn't? Agents can already interact with tmux, so what does this provide?
  • gobdovan nailed it. The CLI is a drop-in for existing tmux workflows; the SDK eases your flow when you'd otherwise be writing brittle send-keys + sleep + capture loop. But that's just one one of the use cases. rmux should be used to make beautiful TUI, something very dirty to do with tmux. Especially the day you want to do integration testing (playwright style)
  •   I think it's trying to be like a code-first/API alternative to Tmux. So instead of:
    
    ``` tmux new-session -d -s a

    tmux send-keys -t a 'npm test' Enter

    sleep 2

    tmux capture-pane -p -t a ```

      you'd do something like:
    
    ``` pane.send_text("npm test\n").await?;

    pane.wait_for_text("Tests passed").await?;

    let snapshot = pane.snapshot().await?; ```

      I don't know why it would be better for agents, maybe the author also works on an LLM agent harness.
  • 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?

  • hey, i’m the herdr dev. pane reordering will be in the next release, let me know if you have more feedback :)
  • no skill file, you get the same 90 commands of tmux. and if you build a rust app you can have many more cool stuff like "wait for" some text to appear, asyncly
  • 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.
  • I started using cmux a month ago and it had made my life a lot easier. Finally I have a pane with all my projects open all the time, I can switch between them, have multiple terminals for each one.

    What do you mean by remote terminals?

    by Oras
  • I found the project quite interesting but what's the advantage over just using tmux with a hotkey to send keys?
  • windows support, and the sdk. native async "wait until" something appears on your terminal, so you don't spam send-keys
  • 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.
  • 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!
  • Same ! TUI are becoming more and more mainstream so there is a need for automated multiplexing , not used by humans but by programs (and agents)
  • 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.

  • I thought I was too zealous because I created 11 crates respecting single responsibility principles.. I would have been all in to risk it further and separating responsibilities for session and window management but it would have diverged too much from tmux. I wanted a 1-1 port for now
  • Hey, I automate tmux all the time with send keys and capture.. how is your project improves vs tmux or zellij?
  • I mean, the obvious immediate answer is “windows”, which tmux flat out doesn't support (except via WSL and a shared mount).
  • I don't get it as well, everything mentioned in the readme is already trivially possible with tmux or zellij
  • rmux is much faster than tmux or zellj, I did some internal benchmark and it's promising. rmux is a multiplexer engine, meaning that you can rewrite entirely zellij using rmux.. I created a mini zellij in a few hundred lines of rust. You can check the demoes on the repo
  • 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.
  • wupsy ! thanks, I just fixed it
  • 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.
  • So?
  • 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.