This doesn’t sound like a “you might not need tmux” argument. It more just argues than tmux is a pita on the terminal ecosystem which I’m sure is true. But the workarounds described are just reimplementing tmux features by taping together a bunch of tools. A better argument I think is - a lot of people do need tmux, so perhaps we should rethink protocols etc to make many of these features more native
People here are missing the point of the solution described in the blog post.
This isn't about reinventing tmux poorly. They're trying to keep their workflow without having a muxer in the middle that needs to understand and translate every feature of the protocol, which is the core concept and the major problem with tmux.
If you do splits client side, you don't have any software middlebox trying to interpret the traffic, so you keep native scrollback and all the fancy features of your terminal are still here.
That's what the blog post is about. Not reinventing tmux, but getting rid of the muxing.
Yes the clean and efficient alternative would be a session manager "server" running on the server and communicating with the terminal "client" (like kitty) using a more efficient protocol for handling panes/windows/drawing etc...
I view "you might not need tmux" in the same way as "you might not need browser tabs".
Yes, if you only have one or two terminal sessions or open web pages then you can probably live without using them, but anything beyond that leads you into reimplementing features to cope with your desktop's lack of ability to manage dozens of windows.
I stopped using tmux, but not for the reasons mentioned here. I think tmux is perfectly fine, I just don't like the default keybindings and I could never remember how to copy/paste between windows.
I've switched to abduco for persistance and use neovim for window management (both vim and neovim have a built in terminal emulator). Using vim keybindings for managing windows and tabs is more natural, I can copy/paster just normally and you even get some perks like `gf` to quickly open a filepath under the cursor.
> act as a drag on the ecosystem as a whole, making it very hard to get any new features
I dont see this as an issue though. Terminals are pretty much a solved problem, they dont need any new features. IMO it makes more sense to spend effort on improving tmux<->terminal interop rather than adding fancy graphics protocols that we dont actually need.
The keystrokes are so ingrained into me that you can take tmux from my cold dead hands.
I use it a bit with remote connections, but tmux is basically my IDE for development. I have the backtick mapped as my prefix and I hope between terminals and Neovim, and I am considerably less productive when I don’t have this setup.
> if you do not set TERM with tmux properly, your colors will render incorrectly
This is of course true of every other terminal emulator as well, and indeed it's not only colours that are incorrect. Function and editing keys get recognized incorrectly; REP can get used where it does not work; and even simple relative cursor motions can be done wrongly.
TERM and the ideas incorporated into terminfo/termcap are inherent in the way that terminal devices work on Unices and Linux-based operating systems. That there are different terminals and terminal emulators not all speaking exactly the same protocol is also an unavoidable reality.
Setting TERM properly isn't some tmux-specific problem.
I learned about Tmux just a few weeks ago and found out that one of the nifty features is that it is scriptable, I.e allows programmatically sending keystrokes to a specific pane. Then, inspired by some Japanese forums I asked myself if I can leverage this to have Claude Code actually interact with an interactive CLI script — we know CC can launch a script via bash but if said script waits for user input then CC can’t (easily) interact with it. Turns out yes we can leverage Tmux for this!
So I used Claude Code to build a little el tool called Tmux-cli, which gives a convenient way to have CC (or any CLI coding agent for that matter) spawn a Tmux
Pane, launch a script there, and actually interact with it.
So it’s like Playwright/Puppeteer for the terminal.
There are some interesting possibilities this enables:
Let CC autonomously test interactive CLI scripts, without me having to intervene and point out errors.
Have the CLI coding agent launch UI from another pane and then use Puppeteer MCP to test from a browser.
Let CC launch a cli script with a debugger enabled (e.g. Pdb) and set breakpoints etc — for token-efficient code understanding, debugging and explaining.
Let the CLI coding agent spawn and drive another instance of the same or other CLI coding agent, AND interact with it. Note this is way better than CC sub-agents which are “spawn and let go” black-boxes.
I wonder if the discussed Tmux alternatives enable building this type of tool.
Session persistence is the key feature for me. All the rest I don't need because i simply open more windows. However multiple windows (or whatever you call them) were really useful when I bought a vt100 as a teenager and programmed on that for a while for fun (with screen at the time, not tmux).
> In summary: multiplexers add unnecessary overhead, suffer from a complexity cascade, because they actually have to translate escape codes, modifying them in hackish ways to get them to work with their concepts of windows/sessions.
This is a feature for me. Because less and less applications bother supporting termcap, this way some applications can still work on my VT520.
I don't really care what the kitty dev thinks anyway. He's entitled to his opinion but for me tmux is way more important. Also I think alacritty is better (though I generally just use Konsole).
As a user I only care about what works well for me, not what's architecturally the most elegant solution.
Can I ask why? It starts slower (has a significant lag on old hardware), has way less useful features (like tabs), has the same responsiveness, and loses in benchmarks (for what they're worth). I see no reason to use it when kitty/ghostty/konsole/foot exist (depending on one's preferences), but people obviously do.
This is incorrect: Alacritty does not have significant lag on old hardware. I suspect you actually meant "hardware that does not have (what is colloquially called) 3D acceleration".
That said, I agree with Terminal elitism being weird: as long as a terminal implements truecolor, both leonerd's and kitty's input protocols, undercurl, OSC52, and maybe OSC8, and otherwise isn't weirdly broken, its good enough.
On that list, alacritty, wez, kitty, foot, WT, anything that uses libvterm, and maybe Ghostty (last time I looked at it, it was just trying to look cool, not being an actually fully implemented terminal, but people swear by it now). Also, multiplexers that implement these requires are on the good enough list, such as tmux or zellij, but not screen (screen tries to pass unknown sequences through, but still sometimes mangles them by accident).
Things that are not required to be on the good enough list: tabs and split panes and any sort of menu bar. These are not show stoppers that prevent compatibility with terminal programs.
This is written for the Linux-on-the-Desktop crowd, and good for them. But tmux really shines for folks using MacBooks with iTerm2. Its tmux integration is so good that it simply disappears into my workflow.
With this in my `~/.ssh/config`, I can just type `ssh tmux` to get back to my remote dev box whenever I wake my computer or change connections.
Host tmux
HostName 1.2.3.4
IdentityFile ~/.ssh/etc.etc.etc
RequestTTY force
RemoteCommand tmux -CC new -A -s 0
With iTerm2's tmux integration enabled, this will pop open a new window where the remote tmux tabs and scroll buffer look and act just like native, local iTerm2 tabs and scroll buffer. I don't even know any tmux commands.
Wow, I was wondering if e.g. Ghostty could implement something like this but that's cool it's already proven out.
Does everything still go "through" tmux (so parsing etc. is still done twice), or does iTerm handle most of the rendering and just delegate scrollback storage/session persistence to tmux? The latter seems like the best of both worlds.
I've just now learned about tmux's control mode. Can you explain what that tmux -CC command does? I use `ssh -t <host> tmux attach -d` from bash history to (re)establish my remote tmux session. `new -A -s 0` would do the about same thing, I just don't see how -CC is supposed to work here.
Edit: It appears to be related to iterm2's tmux integration. Neat.
As someone who uses Linux on all my personal machines but has usually had to use a MacBook for work, tmux is also pretty useful as a platform- independent tool for me to reuse the same workflow without needing to worry about differences between the two. I use Alacritty on Linux, but when I've tried using it on MacOS, there have things that don't seem to work for me out of the box the same way they do in Linux (which I'm struggling to remember exactly at the moment, but I think one of them might have been the setting to have the window maximized on startup). Rather than spend time trying to tinker around on an operating system that I don't have any particular desire to use outside of just getting my work done, it's pretty nice to be able to use tmux on iTerm to get basically the same experience I do on Linux. From that perspective, having something like an entirely independent way of scrolling back in a session is a feature to me, not an annoyance.
A lot of these arguments against tmux seem like they're more relevant to someone developing a terminal rather than using it. It's fine for people working on their own terminals to decide they don't care to support it, but I don't really find the arguments convincing as something I should care about, and I'd personally just switch to another terminal with better support for it rather than stop using it.
From what I have seen, tmux is the _only_ multiplexer with with you can select from the scroll-back buffer using only the keyboard (without using the mouse).
I think a key piece of context to Kovid's distain of tmux is how good window management is in kitty. I regularly have at least ten terminals open and navigating them is a breeze. I previously lived in tmux but much prefer this.
The session persistence thing is still best solved with tmux, however, I don't ever need this. Nohup is sufficient for long running commands where my ssh might fail. I don't really find myself sshing into a machine and then setting loads of env vars that I need to persist.
90 comments
[ 3.1 ms ] story [ 89.5 ms ] threadI'm still a gnu screen guy, but for me the trade-off is still in favour of screen/tmux.
But I agree that tmux sessions are convenient.
It is also extensible.
This isn't about reinventing tmux poorly. They're trying to keep their workflow without having a muxer in the middle that needs to understand and translate every feature of the protocol, which is the core concept and the major problem with tmux.
If you do splits client side, you don't have any software middlebox trying to interpret the traffic, so you keep native scrollback and all the fancy features of your terminal are still here.
That's what the blog post is about. Not reinventing tmux, but getting rid of the muxing.
AFAIK this doesn't exist, so I'm using tmux...
https://www.masteringemacs.org/article/replacing-tmux-gnu-sc...
Yes, if you only have one or two terminal sessions or open web pages then you can probably live without using them, but anything beyond that leads you into reimplementing features to cope with your desktop's lack of ability to manage dozens of windows.
A big difference is that I can move two browser tabs into separate windows, or from separate windows into the same.
The same is actually tree of top-level windows if your window manager can group windows into tabs.
tmux tabs lack this flexibility.
I've switched to abduco for persistance and use neovim for window management (both vim and neovim have a built in terminal emulator). Using vim keybindings for managing windows and tabs is more natural, I can copy/paster just normally and you even get some perks like `gf` to quickly open a filepath under the cursor.
I liked the fact I didn't need to set anything up for Zellij and could gradually add stuff
I dont see this as an issue though. Terminals are pretty much a solved problem, they dont need any new features. IMO it makes more sense to spend effort on improving tmux<->terminal interop rather than adding fancy graphics protocols that we dont actually need.
> Goals … Do not reimplement tmux and his comrades.
( From https://st.suckless.org/goals/ )
I use it a bit with remote connections, but tmux is basically my IDE for development. I have the backtick mapped as my prefix and I hope between terminals and Neovim, and I am considerably less productive when I don’t have this setup.
This is of course true of every other terminal emulator as well, and indeed it's not only colours that are incorrect. Function and editing keys get recognized incorrectly; REP can get used where it does not work; and even simple relative cursor motions can be done wrongly.
TERM and the ideas incorporated into terminfo/termcap are inherent in the way that terminal devices work on Unices and Linux-based operating systems. That there are different terminals and terminal emulators not all speaking exactly the same protocol is also an unavoidable reality.
Setting TERM properly isn't some tmux-specific problem.
So I used Claude Code to build a little el tool called Tmux-cli, which gives a convenient way to have CC (or any CLI coding agent for that matter) spawn a Tmux Pane, launch a script there, and actually interact with it.
So it’s like Playwright/Puppeteer for the terminal.
You can get it via
https://github.com/pchalasani/claude-code-toolsThere are some interesting possibilities this enables:
Let CC autonomously test interactive CLI scripts, without me having to intervene and point out errors.
Have the CLI coding agent launch UI from another pane and then use Puppeteer MCP to test from a browser.
Let CC launch a cli script with a debugger enabled (e.g. Pdb) and set breakpoints etc — for token-efficient code understanding, debugging and explaining.
Let the CLI coding agent spawn and drive another instance of the same or other CLI coding agent, AND interact with it. Note this is way better than CC sub-agents which are “spawn and let go” black-boxes.
I wonder if the discussed Tmux alternatives enable building this type of tool.
This is a feature for me. Because less and less applications bother supporting termcap, this way some applications can still work on my VT520.
I don't really care what the kitty dev thinks anyway. He's entitled to his opinion but for me tmux is way more important. Also I think alacritty is better (though I generally just use Konsole).
As a user I only care about what works well for me, not what's architecturally the most elegant solution.
Can I ask why? It starts slower (has a significant lag on old hardware), has way less useful features (like tabs), has the same responsiveness, and loses in benchmarks (for what they're worth). I see no reason to use it when kitty/ghostty/konsole/foot exist (depending on one's preferences), but people obviously do.
That said, I agree with Terminal elitism being weird: as long as a terminal implements truecolor, both leonerd's and kitty's input protocols, undercurl, OSC52, and maybe OSC8, and otherwise isn't weirdly broken, its good enough.
On that list, alacritty, wez, kitty, foot, WT, anything that uses libvterm, and maybe Ghostty (last time I looked at it, it was just trying to look cool, not being an actually fully implemented terminal, but people swear by it now). Also, multiplexers that implement these requires are on the good enough list, such as tmux or zellij, but not screen (screen tries to pass unknown sequences through, but still sometimes mangles them by accident).
Things that are not required to be on the good enough list: tabs and split panes and any sort of menu bar. These are not show stoppers that prevent compatibility with terminal programs.
With this in my `~/.ssh/config`, I can just type `ssh tmux` to get back to my remote dev box whenever I wake my computer or change connections.
With iTerm2's tmux integration enabled, this will pop open a new window where the remote tmux tabs and scroll buffer look and act just like native, local iTerm2 tabs and scroll buffer. I don't even know any tmux commands.Does everything still go "through" tmux (so parsing etc. is still done twice), or does iTerm handle most of the rendering and just delegate scrollback storage/session persistence to tmux? The latter seems like the best of both worlds.
Edit: It appears to be related to iterm2's tmux integration. Neat.
A lot of these arguments against tmux seem like they're more relevant to someone developing a terminal rather than using it. It's fine for people working on their own terminals to decide they don't care to support it, but I don't really find the arguments convincing as something I should care about, and I'd personally just switch to another terminal with better support for it rather than stop using it.
The session persistence thing is still best solved with tmux, however, I don't ever need this. Nohup is sufficient for long running commands where my ssh might fail. I don't really find myself sshing into a machine and then setting loads of env vars that I need to persist.