> You might be asking: why did you rewrite tmux in Rust? And yeah, I don’t really have a good reason. It’s a hobby project. Like gardening, but with more segfaults.
I love this attitude. We don’t necessarily need a reason to build new things. Who knows what will come out of a hobby project. Thanks to the author for the great write up!
Also, my gardening is full of segfaults, coding a new project is definitely safer to my yard.
I like the initiative, but all this effort for ... unsafe Rust?
I know it's a hot topic, and I hope the end goal is to have a memory-safe (and faster) tmux. I just hope the author doesn't stop here :)
Edit: As pointed out below, I'm stupid, it's stated in the article and I didn't read that part
Some of that video is about stuff you have no use for if you're not a Rust developer, but, some of it is things that would be just as useful to anybody who is comfortable with, as it says, a command line interface.
I'll take a rust tmux if it runs on Windows. I'm currently kind of stuck on Windows and I didn't realize how much tmux means to me until Bill took it away :(
Tmux is a gamechanger for me. Being able to start a dozen different projects with one line (using tmuxinator): the server, tailing logfiles, activating venvs, running the docker container, all within one line of code: Awesome. Hadn’t worked with it for years, just started again two days ago as I migrated from iTerm to Ghostty. And am loving the setup. Plus nvim. Pure awesomeness.
It seems automatically translating Rust to C is not a very good idea: "I threw away all of the C2Rust output and decided I would translate all of the files into Rust manually from C.". Neither seems doing it manually: "I introduced many bugs while translating the code. I’d like to share the process of discovering and fixing a couple." Or using AI: "That’s because when using cursor to translate the code it would still occasionally insert bugs, just like me. So, I spent as much time reviewing the generated code as it would have taken me to write it myself."
As a hobby project, all power to you. But otherwise, maybe better not rewrite working code....
Nice, I like tmux, I use it daily, I live in it. I hope this version makes it easier to just scroll with the scroll wheel or ctrl-page-up/down, or ctrl tab through your panes, or just show the whole unconcatenated title in the bottom left ;)
Sorry I know this is not the place to complain, but it would be so nice!
I've been working on a Rust-based tmux session manager called rmuxinator (i.e. tmuxinator clone) for a few years now. It (mostly) works and been slow going because ... life but I've recently picked it back up to fix some bugs. One of the last new features I'd added was the ability to use rmuxinator as a library in other Rust programs. I'd like to try forking tmux-rs, adding rmuxinator as a dependency and seeing if it would ... just work as a way to start sessions using per-project config files. I'm definitely not advocating for adding rmuxinator upstream but it would be very nice to have this sort of session templating baked into the "terminal multiplexer" itself.
The other interesting possibility I could foresee is doing things the other way around and having rmuxinator use tmux-rs as a library in order to setup and manage sessions instead of just dumping out shell commands -- which is fraught with edge cases. (Not sure if this is currently possible with tmux-rs, though.)
Once I wrap up the bugfixes I'm currently working on, I may fork this project and give one or both of the above a try.
As of rmuxinator 4.0.0, you can now use tmux-rs as a configurable "terminal multiplexer" and it'll use that executable when shelling out to create and manage the session.
This seems like an excellent future use case for a fully automated process by a large language model that translates a non-trivial C codebase to Safe Rust in under an hour with high accuracy. However, as the author noted, even after some attempts with Cursor at the end of development, the tool wasn't able to accelerate the translation effectively (in mid-2025). So while the potential is promising, it appears we're still some way off.
Interesting, this article and the comments make no mention of LLMs for the initial translation. Really surprising given that would be the first thing I'd reach for for a translation/porting task (though verification could get tricky).
Now I really wonder how a good model like Sonnet 4 would have performed.
Nice, hope it will become cleaner code in time. I tried zellij multiple times but despite years of development it still misses many things tmux provides. Inability to show/hide status bar[1] is the most annoying.
Just curious. I'm a Rust developer. But I don't see myself discriminating between tools written in C, C++, Rust, Zig, etc. They all seem easy to install and use, as long as they're reasonably bugfree. Scripting languages are slightly different as they require me to maintain their respective interpreters and tools on my system. What difference do you see between applications written in Rust and those written in other compiled languages?
What @tkcranny said. They are better usability now and more sensible defaults. I also find them marginally faster.
I also using them as way of supporting them. Tmux is great and I have used for years. Zellij is not there yet but does some things better than tmux too.
LLM's are really good at translating one programming language into another.
In fact, I sometimes port code to another language and back just as a way to do code cleanup (or at least give ideas for things that could be cleaned up)
I wonder why OP didn't start from that as a starting point?
I love the attitude on this project and most of the comments are supportive. While rewriting a mature application to another language always sounds like a bad idea, there are so many learnings along the way. It's not about the end it's about the process.
Given the traction you got here and the advancements in AI, I'm sure this can become a very attractive hobby project for Rust beginners, there's probably a lot of easy bugs to fix. Fixing bugs, adding new features, and optimizing the code is all you need.
Here's an idea to get the ball rolling: Create a scratch buffer for Gemini CLI (or your favorite LLM) and enable it to interact with the various windows and panes of the tmux session.
Here's my use case, I use synchronized panes to send the commands into multiple servers, but some commands sometimes fail for various reasons. What if I can just ask the AI to send a series of commands and react based on the output and adjust along the way. It's like a dynamically generated custom shell script on the fly.
I started working on this feature about a month ago: https://github.com/snizovtsev/tmux (it's in early experiments, not ready for a try).
Luckily tmux has a well-established "control mode" protocol designed for iTerm2 that can serialize internal state updates into a stream of text messages. So I do write client-side of this feature right inside tmux.
When it's ready, you will able to embed remote sessions inside local tmux instance by calling something like "ssh example.com tmux -CC attach". It will auto-detect "control mode" escape sequence and create special "remote session" you can switch into.
If you are interested, connect with me (snizovtsev@gmail.com) so I will notify when feature is ready and ask for early testing before making upstream proposal.
66 comments
[ 3.4 ms ] story [ 82.4 ms ] threadI love this attitude. We don’t necessarily need a reason to build new things. Who knows what will come out of a hobby project. Thanks to the author for the great write up!
Also, my gardening is full of segfaults, coding a new project is definitely safer to my yard.
I have often executed `pkill -9 tmux` and saved my day. I hope the rust version can help a bit here?
Also, in 2017-2018 I contributed a few fixes for memory leaks related to buffer history, so make sure you are using a recent version.
Edit: As pointed out below, I'm stupid, it's stated in the article and I didn't read that part
https://www.youtube.com/watch?v=rWMQ-g2QDsI
Some of that video is about stuff you have no use for if you're not a Rust developer, but, some of it is things that would be just as useful to anybody who is comfortable with, as it says, a command line interface.
Looking forward to check out tmux-rs.
It seems automatically translating Rust to C is not a very good idea: "I threw away all of the C2Rust output and decided I would translate all of the files into Rust manually from C.". Neither seems doing it manually: "I introduced many bugs while translating the code. I’d like to share the process of discovering and fixing a couple." Or using AI: "That’s because when using cursor to translate the code it would still occasionally insert bugs, just like me. So, I spent as much time reviewing the generated code as it would have taken me to write it myself."
As a hobby project, all power to you. But otherwise, maybe better not rewrite working code....
Sorry I know this is not the place to complain, but it would be so nice!
I've been working on a Rust-based tmux session manager called rmuxinator (i.e. tmuxinator clone) for a few years now. It (mostly) works and been slow going because ... life but I've recently picked it back up to fix some bugs. One of the last new features I'd added was the ability to use rmuxinator as a library in other Rust programs. I'd like to try forking tmux-rs, adding rmuxinator as a dependency and seeing if it would ... just work as a way to start sessions using per-project config files. I'm definitely not advocating for adding rmuxinator upstream but it would be very nice to have this sort of session templating baked into the "terminal multiplexer" itself.
The other interesting possibility I could foresee is doing things the other way around and having rmuxinator use tmux-rs as a library in order to setup and manage sessions instead of just dumping out shell commands -- which is fraught with edge cases. (Not sure if this is currently possible with tmux-rs, though.)
Once I wrap up the bugfixes I'm currently working on, I may fork this project and give one or both of the above a try.
Regardless, nice work by richardscollin!
Transitioning more software from C to Rust is a great idea.
I was hoping for the announcement of a brand new bulletproof tmux-resurrect.
But no, it is (just) tmux-(recodedIn)rust.
Now I really wonder how a good model like Sonnet 4 would have performed.
[1] https://github.com/zellij-org/zellij/issues/694
Here I want to call out zellij. Zellij is rust based terminal multiplexer.
I am user not creator. I love everything rust and finding and migrating to rust based solutions where feasible.
I also using them as way of supporting them. Tmux is great and I have used for years. Zellij is not there yet but does some things better than tmux too.
In fact, I sometimes port code to another language and back just as a way to do code cleanup (or at least give ideas for things that could be cleaned up)
I wonder why OP didn't start from that as a starting point?
Given the traction you got here and the advancements in AI, I'm sure this can become a very attractive hobby project for Rust beginners, there's probably a lot of easy bugs to fix. Fixing bugs, adding new features, and optimizing the code is all you need.
Here's an idea to get the ball rolling: Create a scratch buffer for Gemini CLI (or your favorite LLM) and enable it to interact with the various windows and panes of the tmux session.
Here's my use case, I use synchronized panes to send the commands into multiple servers, but some commands sometimes fail for various reasons. What if I can just ask the AI to send a series of commands and react based on the output and adjust along the way. It's like a dynamically generated custom shell script on the fly.
Luckily tmux has a well-established "control mode" protocol designed for iTerm2 that can serialize internal state updates into a stream of text messages. So I do write client-side of this feature right inside tmux.
When it's ready, you will able to embed remote sessions inside local tmux instance by calling something like "ssh example.com tmux -CC attach". It will auto-detect "control mode" escape sequence and create special "remote session" you can switch into.
If you are interested, connect with me (snizovtsev@gmail.com) so I will notify when feature is ready and ask for early testing before making upstream proposal.