I love tmux! Using it as a tool suddenly enabled me to do so many things. Lately I've been using Zellij, which I'd massively recommend for anyone not wanting to do a load of customisation. It just works great out the box (but probably has less wiggle room to "make your own")
The article is focused on interactive use, but I would be interested to also hear from folks using tmux as a process manager / dashboard for server-type environments. I was pretty unenthused about this practice when I first encountered it, but it's grown on me as a way to quickly get a sense of state from onboard a running system without having to rely on off-board dashboard or log parsers / alert systems.
In particular, I'm curious about libtmux/tmuxp and how well it works to have a more declarative bringup than just a bash script launching things into the background and then attaching tmux windows to them.
And I guess the broader question of whether this approach is an evolutionary dead end— like does it just become a pile of hacks as one discovers the need for restart policies, backoffs, ordering, whatever other stuff that is built into a "normal" process manager like systemd or runit? If you do end up wanting to send process stdout/stderr elsewhere or do alerting, is that now annoying if those streams are "trapped" in tmux sessions vs being written into log files or the journal?
I’ve seen people use this approach (and screen too) but personally I hate it for anything other than services that are interactive but you want detachable. Eg long running installs.
All the other examples I’ve seen where people have used it as a shortcut for daemonizing a service, it’s felt like just as much effort as writing a systemd service file.
I guess I could forgive people more back in the days of sysv-style initd. Writing those shell scripts was seldom fun. But with systemd, it’s literally a 5 minute task. And I say that as someone who dislikes numerous decisions made regarding the approach systemd takes.
> I would be interested to also hear from folks using tmux as a process manager / dashboard for server-type environments
Sure! I use tmux on most of my OpenBSD systems and copy the same .tmux.conf file around, but rarely tweak it other than to set a hostname.
My status bar is at the top and looks approximately like this:
--~ msg auth pf hostname. Mon Aug 04 15:05
* The first two windows (--) are regular shells.
* The tilde window (~) is where I do stuff as root.
* The message window (msg) tails `/var/log/messages` and `/var/log/daemon`, or `journalctl -f` and `journalctl -k -f` on Linux.
* The auth window (auth) tails `/var/log/authlog` to monitor login attempts and usage of doas and sudo.
* The pf window (pf) runs a script to monitor the packet filter rules (pass, block, match).
* hostname is just the hostname. The period (.) means no mail, it turns to an exclaimation mark (!) when I have mail.
* Simple date/time.
This setup gives me quick access shells, important logs, mail status, date/time, and works the same on every server I manage. I add extra windows to tail other app logs as needed.
I've used tmux like that a bunch before discovering process-compose [1]. Still use tmux a lot with remote connections and booting up a few scripts in parallel is still easier with it, but for longer-serving setups p-c has helped a lot
I wrote a quick and dirty bash script that launches a tmux dashboard for a legacy linux server. The team has been happy with it. It does seem like an evolutionary dead end to be honest, but it was very quick to set up.
Note that the dashboard is read-only and mostly just shows journalctl for different units (we use systemd for process management). And we assume it's only used by a single user at once and everything is stopped on detach.
Here's a simplified sample of setting up a 3x2 layout with some placeholder content:
The only reason to still use tmux (or screen) is because you use remote sessions. All modern terminal emulators are already capable of doing tabs and panes (okay, maybe not sessions, but some can locally). If you're using tmux for this reason, stop. Go pick up a modern terminal like ghostty, Alacritty, or WezTerm.
But why tmux still exists today is because people are working on computers they aren't sitting in front of. Because I don't want to have to be running nohup or detaching, moving to the background, and resetting the session so error messages don't appear in my active instance. Hell, technically I can do this with vim and get something pretty similar to tmux by using the terminal. But that's a pain.
Okay, but sessions are one of the best things about tmux.
Sessions aside, in my opinion tmux's flow is just better than terminal emulators I've tried. It slots into my brain in a way no terminal emulator's tabbing support ever has, and I have never found a terminal emulator who supported keybindings in such a sophisticated and seamless manner as tmux does.
I also concur with other commenters, who mention that having uniform multiplexing of shell windows between local and remote environments is super useful for muscle memory.
I would mostly agree, but I like that I can use tmux locally and remotely and thus have the same interface wherever I do my work (and regardless of what terminal I use).
Then, there's the fact that some terminals capture too many keybindings and get in the way of some terminal code editors I'd like to use (e.g. recently I was again trying to use flow <https://github.com/neurocyte/flow> and its next-tab and previous-tab shortcuts clash with Ghostty's). If I had a terminal that 1) was nothing but a black box with the capability to display Unicode font glyphs and ligatures correctly, 2) works under Wayland, and 3) captures as few keybindings as possible, I'd use it locally with tmux and live happy.
When I was a Vim user, tmux was always the first thing I ran when connecting to a machine…
But the after moving to Emacs and using Tramp for remote sessions, followed by VS Code with its built-in session management, I never feel the need to even leave the editor let along manage sessions
>I felt overwhelmed by the very poor default UI that it offers and the amount of options and shortcuts that I needed to know to operate it well and be productive
@HNModerators, I don't know why it was necessary to change the title of my post from "Customizing tmux and making it less dreadful" to "Customizing tmux". The point of the title was not the overview of all of the customization options, but the effort to make it more usable, convenient, and pleasant to use.
"When I first started using tmux, I felt overwhelmed by the very poor default UI that it offers and the amount of options and shortcuts that I needed to know to operate it well and be productive. It took me several tries before I started to feel more or less comfortable with it. One of the things that stood out to me right away was how dreadful UI looked. Not only it felt uninviting, but it almost felt “gatekeepy” - if you don’t know how to use it in this configuration, then might as well forget about it."
EPendragon elaborate on this. It seems like you understand the shell enough to use it productively and customize it to be how you like it. The screenshot this quote is talking about looks like a shell? In what way is it dreadful, and in what way do your customizations make it not dreadful?
For example, it seems like a valid criticism that shells are not very discoverable and a prompt and blinking cursor can be intimidating to a noob, and that surely applies to tmux as well. But then changing the shortcuts doesn't really address that, does it?
To me it seems your article is either saying, "tmux is a pig, and here's me putting some lipstick on it," :) or the problems are not insurmountable, and the solutions are nice but not life-changing.
It's great that you like it better now, and we're all having fun chatting around it about how we configure our tools here on the Hacker News :) But I don't see why it's "dreadful". It's just.. computers, no? Tmux seems no more gatekeepy than any other aspect of computers. And I say this as someone who stopped using tmux a few years ago after getting super annoyed with it.
The best way I have found to use tmux is to unbind everything and set only the things I use for my workflow. Then the configuration (.tmux.conf) becomes the docs.
I was inspired by the "How to Configure tmux from scratch" post [1].
I came up with my use cases:
- I want to create sessions
- I want to open and close windows
- I want to create split panes
- I want to use vim-style text select
- etc.
Then I made mappings for the things I care about for my workflow specifically.
Before this, I would accidentally hit a keybinding while doing something else and not know how I got to that state, taking me out of flow to troubleshoot.
Afterwards, only the keybindings I have defined take action.
Now tmux fits like a glove. Because tmux is so stable, I haven't had to touch my config in years. It's worth the one time effort.
> Before this, I would accidentally hit a keybinding while doing something else and not know how I got to that state, taking me out of flow to troubleshoot.
I used to accidentally background my tmux frequently and the first couple times made my heart sink in that “did I save??” way lol, though these days I’ve largely stoped using it since splits feel smoother in Kitty and I don’t do any remote sessions.
I was sad to discover that not all string-like config items accept input from external processes. I had to resort to on-the-fly sed templating as a hackaround.
I tend to use byobu as a wrapper around tmux wherever possible - this combination might have gotten the author close enough to where they wanted to be.
Well, they'd still need to bring their own ascii teacup.
I've largely given up using tmux in favor of wezterm: wezterm has the ability to remote connect to a persistent terminal running on another machine, and has native window objects so things like mouse support and copy/paste work out of the box. It also has a kind of mosh-like support, though not quite as good at persisting connections over bad networks or network disconnections as mosh+tmux.
The down side is that it's really sensitive to versions, right now I'm struggling to get it to work on NixOS in the version that I have running on my Ubuntu dev box and MacOS laptop.
"One of the things that stood out to me right away was how dreadful UI looked. Not only it felt uninviting, but it almost felt “gatekeepy” - if you don’t know how to use it in this configuration, then might as well forget about it."
I'm puzzled how we get from unintuitive interface to "gatekeepy" (which I'm assuming implies a deliberate attempt to make the set of users small). Things can be difficult to use without anyone setting out to exclude new users, some things _are_ difficult to use, and other things are written by people who haven't been paid to make them address the needs of a wider range of users than they want to.
As someone who lives in terminals, iTerm2 may be the Killer App for Macbooks.
You see, it has Tmux Integration [1], which makes tmux windows and panes become native tabs and panes in iTerm, which means I don't need to use weird chords to manipulate tmux, but most importantly, most UX-ily, it has native scrollback. No need to escape into a weird secondary mode just to do the most basic thing that all graphical terminals are good for.
If you work with terminals on remote machines, you owe yourself to use tmux. If your client is a Mac(book), you owe yourself to use iTerm2.
The weird thing is that iTerm2 is the only Terminal Emulator to leverage Tmux's Control Channel mode, for the integration. For all the breadth of copycat terminal emulators on Linux, none of them perform this one killer feature.
Have you used iTerm's built-in tmux integration? It's a while since I used it because I don't do development on a remote machine anymore, but I liked the way it mapped tmux tabs and panes to native iTerm ones
I have to admit I don't like customizing tools like tmux too much. Personally I prefer to just learn and live with the defaults. That mean losing out on some things, but I think it's a good trade off for having thing just work like you expect on random server you sign in to.
Especially something like keyboard shortcuts and leader keys doesn't make sense to change in my mind. It just confuses you when login in to a remote host.
Speaking of prefix-key binding -- I find all control-key combos painful. I use the UHK split keyboard, and set mod-space as the prefix key which is very ergonomic.
I recently dove into Tmux just to be able to combine it with Claude-Code(CC): allowing CC to watch and interact with a CLI application in a separate pane. A nice feature of tmux is that it is scriptable, I.e allows programmatically sending keystrokes to a specific pane. So I built this little tool "tmux-cli" that creates a convenient, safe wrapper (that prevents self-killing, and has built-in delays for Enter key, etc) around tmux that lets CC spawn another pane, launch a CLI script and actually interact with it. This gives CC some interesting abilities: interact with CLI scripts expecting user input; spawn another instance of CC and give it a task (like sub-agents but fully-visible); launch a CLI script with a debugger like Pdb and stepping thru it; launch UI servers and use Puppeteer MCP to check the browser.
I use a window manager and have never bothered with tmux, except as a screen alternative to keep processes alive on servers every once in a while. I don’t like the idea of learning a 3rd set of key bindings in order to get what my window manager mostly gives me.
For those of you who use a tiling or scrolling window manager and tmux, what’s your selling point?
As an emacs user, I struggle to see the purpose of tmux when emacs gives me a
lot of control of my screen layout.
I can see its purpose for vim users... maybe tmux can still have some features for neovim users. For emacs.. my answer is simply all-in emacs.
When I saw a screenshot of emacs in the article, I thought I was in for some education... but sadly not the case.
Maybe I am missing the point - but I am happy to learn.
34 comments
[ 3.2 ms ] story [ 58.9 ms ] threadhttps://zellij.dev/
In particular, I'm curious about libtmux/tmuxp and how well it works to have a more declarative bringup than just a bash script launching things into the background and then attaching tmux windows to them.
And I guess the broader question of whether this approach is an evolutionary dead end— like does it just become a pile of hacks as one discovers the need for restart policies, backoffs, ordering, whatever other stuff that is built into a "normal" process manager like systemd or runit? If you do end up wanting to send process stdout/stderr elsewhere or do alerting, is that now annoying if those streams are "trapped" in tmux sessions vs being written into log files or the journal?
All the other examples I’ve seen where people have used it as a shortcut for daemonizing a service, it’s felt like just as much effort as writing a systemd service file.
I guess I could forgive people more back in the days of sysv-style initd. Writing those shell scripts was seldom fun. But with systemd, it’s literally a 5 minute task. And I say that as someone who dislikes numerous decisions made regarding the approach systemd takes.
Sure! I use tmux on most of my OpenBSD systems and copy the same .tmux.conf file around, but rarely tweak it other than to set a hostname.
My status bar is at the top and looks approximately like this:
* The first two windows (--) are regular shells.* The tilde window (~) is where I do stuff as root.
* The message window (msg) tails `/var/log/messages` and `/var/log/daemon`, or `journalctl -f` and `journalctl -k -f` on Linux.
* The auth window (auth) tails `/var/log/authlog` to monitor login attempts and usage of doas and sudo.
* The pf window (pf) runs a script to monitor the packet filter rules (pass, block, match).
* hostname is just the hostname. The period (.) means no mail, it turns to an exclaimation mark (!) when I have mail.
* Simple date/time.
This setup gives me quick access shells, important logs, mail status, date/time, and works the same on every server I manage. I add extra windows to tail other app logs as needed.
[1] https://github.com/F1bonacc1/process-compose
Note that the dashboard is read-only and mostly just shows journalctl for different units (we use systemd for process management). And we assume it's only used by a single user at once and everything is stopped on detach.
Here's a simplified sample of setting up a 3x2 layout with some placeholder content:
The only reason to still use tmux (or screen) is because you use remote sessions. All modern terminal emulators are already capable of doing tabs and panes (okay, maybe not sessions, but some can locally). If you're using tmux for this reason, stop. Go pick up a modern terminal like ghostty, Alacritty, or WezTerm.
But why tmux still exists today is because people are working on computers they aren't sitting in front of. Because I don't want to have to be running nohup or detaching, moving to the background, and resetting the session so error messages don't appear in my active instance. Hell, technically I can do this with vim and get something pretty similar to tmux by using the terminal. But that's a pain.
Tmux is for *terminals*
Okay, but sessions are one of the best things about tmux.
Sessions aside, in my opinion tmux's flow is just better than terminal emulators I've tried. It slots into my brain in a way no terminal emulator's tabbing support ever has, and I have never found a terminal emulator who supported keybindings in such a sophisticated and seamless manner as tmux does.
I also concur with other commenters, who mention that having uniform multiplexing of shell windows between local and remote environments is super useful for muscle memory.
Then, there's the fact that some terminals capture too many keybindings and get in the way of some terminal code editors I'd like to use (e.g. recently I was again trying to use flow <https://github.com/neurocyte/flow> and its next-tab and previous-tab shortcuts clash with Ghostty's). If I had a terminal that 1) was nothing but a black box with the capability to display Unicode font glyphs and ligatures correctly, 2) works under Wayland, and 3) captures as few keybindings as possible, I'd use it locally with tmux and live happy.
But the after moving to Emacs and using Tramp for remote sessions, followed by VS Code with its built-in session management, I never feel the need to even leave the editor let along manage sessions
Typical Macintosh user.
https://news.ycombinator.com/newsguidelines.html
EPendragon elaborate on this. It seems like you understand the shell enough to use it productively and customize it to be how you like it. The screenshot this quote is talking about looks like a shell? In what way is it dreadful, and in what way do your customizations make it not dreadful?
For example, it seems like a valid criticism that shells are not very discoverable and a prompt and blinking cursor can be intimidating to a noob, and that surely applies to tmux as well. But then changing the shortcuts doesn't really address that, does it?
To me it seems your article is either saying, "tmux is a pig, and here's me putting some lipstick on it," :) or the problems are not insurmountable, and the solutions are nice but not life-changing.
It's great that you like it better now, and we're all having fun chatting around it about how we configure our tools here on the Hacker News :) But I don't see why it's "dreadful". It's just.. computers, no? Tmux seems no more gatekeepy than any other aspect of computers. And I say this as someone who stopped using tmux a few years ago after getting super annoyed with it.
I was inspired by the "How to Configure tmux from scratch" post [1].
I came up with my use cases:
- I want to create sessions
- I want to open and close windows
- I want to create split panes
- I want to use vim-style text select
- etc.
Then I made mappings for the things I care about for my workflow specifically.
Before this, I would accidentally hit a keybinding while doing something else and not know how I got to that state, taking me out of flow to troubleshoot.
Afterwards, only the keybindings I have defined take action.
Now tmux fits like a glove. Because tmux is so stable, I haven't had to touch my config in years. It's worth the one time effort.
[1] https://ianthehenry.com/posts/how-to-configure-tmux/
I used to accidentally background my tmux frequently and the first couple times made my heart sink in that “did I save??” way lol, though these days I’ve largely stoped using it since splits feel smoother in Kitty and I don’t do any remote sessions.
Glad that that it supports XDG though.
Well, they'd still need to bring their own ascii teacup.
https://www.byobu.org/
The down side is that it's really sensitive to versions, right now I'm struggling to get it to work on NixOS in the version that I have running on my Ubuntu dev box and MacOS laptop.
I'm puzzled how we get from unintuitive interface to "gatekeepy" (which I'm assuming implies a deliberate attempt to make the set of users small). Things can be difficult to use without anyone setting out to exclude new users, some things _are_ difficult to use, and other things are written by people who haven't been paid to make them address the needs of a wider range of users than they want to.
It's free https://iterm2.com/
As someone who lives in terminals, iTerm2 may be the Killer App for Macbooks.
You see, it has Tmux Integration [1], which makes tmux windows and panes become native tabs and panes in iTerm, which means I don't need to use weird chords to manipulate tmux, but most importantly, most UX-ily, it has native scrollback. No need to escape into a weird secondary mode just to do the most basic thing that all graphical terminals are good for.
If you work with terminals on remote machines, you owe yourself to use tmux. If your client is a Mac(book), you owe yourself to use iTerm2.
The weird thing is that iTerm2 is the only Terminal Emulator to leverage Tmux's Control Channel mode, for the integration. For all the breadth of copycat terminal emulators on Linux, none of them perform this one killer feature.
[1] https://iterm2.com/documentation-tmux-integration.html
Other than that, I always use the default CTRL+B (MOD) and rarely if ever do anything other than the following:
- MOD + d to detach, "tmux a" to attach
- MOD + c to create new window
- MOD + % to create new split pane, " for horizontal
- MOD + space to change between pane layouts
- MOD + pgup to scroll in buffer
Especially something like keyboard shortcuts and leader keys doesn't make sense to change in my mind. It just confuses you when login in to a remote host.
It's easy to install via uv:
https://github.com/pchalasani/claude-code-toolsFor those of you who use a tiling or scrolling window manager and tmux, what’s your selling point?
But only customization so far is metahar = C-b, because C-a needed on Emacs.
I can see its purpose for vim users... maybe tmux can still have some features for neovim users. For emacs.. my answer is simply all-in emacs. When I saw a screenshot of emacs in the article, I thought I was in for some education... but sadly not the case.
Maybe I am missing the point - but I am happy to learn.