You Don’t Need A Terminal Multiplexer on Your Desktop

I’m not sure where this recent trend on YouTube, Substack, and other social media platforms is coming from, but for some reason, every content creator and their dog appears to be pitching how hYpEr PrOdUcTiVe their desktop became ever since they found this one trick your government doesn’t want you to know about: Terminal multiplexing.

Terminal multiwhat?

Alright kids, buckle up, time to set the Flux Capacitor to 1987. Terminal Multiplexers were first introduced in the late 80s as a way to allow a user to access multiple terminal sessions within a single TTY. See, back at that time, computers couldn’t display what we know today as multiple windows. In fact, most of them didn’t have any windows at all but were running solely on command-line interfaces. Once you logged in to one session, you had one shell prompt to run programs. Assuming you launched a long-running program, like for example copying a huge (read: 1.44 Megabytes) file onto a floppy disk, all you could do was wait and stare at cp until it finished, which is when the prompt returned and you could run another program. Unless you pressed Ctrl+Alt+F2 to switch to the second TTY, type in your login credentials there and start a whole new session.

Terminal multiplexers solved this issue by allowing you to launch multiple shells, usually in different windows that you could switch between, and later even as split-screen tiles next to each other, all within a single TTY and login session. They were basically a window manager, on the command-line interface. GNU screen was one of the first terminal multiplexers and for a long time the only solid option around. Tmux only joined the multiplexing party two decades later, in 2007, at a time when GUIs were already widely available and people on Linux were slowly moving towards the back then still young successor of XFree86, Xorg.

Tmux was clearly focused on more modern use cases, as, unlike screen, it didn’t implement support for either serial port communication – yes, you can totally fire up screen /dev/ttyS1 to read what your Arduino is telling you – or telnet – yep, screen my.telnet.host works. And while Tmux is still just a humble terminal multiplexer that “enables a number of terminals to be created, accessed, and controlled from a single screen”, Zellij took it to new heights by being “a terminal workspace with batteries included”, whatever that is supposed to mean. More on that later.

Long story short, as with everything in our world, it seems that we have now gone full circle:

• First, we didn’t have a GUI, so we built TUI programs like Vi and Midnight Commander and terminal multiplexers to allow us to run multiple CLI and TUI programs in parallel, in the foreground.
• Then we created GUIs that allowed us to run multiple GUI programs in the foreground in parallel.
• We then built UI monstrosities like Lotus Notes, Microsoft Excel, and Visual Studio and realized that the TUI programs we had actually weren’t that bad, so…
• … we went back to those, iMproved upon them, and began running them in individual GUI terminal emulator windows.
• Now, apparently, we only run the graphical user interface to spawn a single terminal window, within which we use a multiplexer to run multiple CLI and TUI tools in parallel. On, and plugins that show us the date, time, CPU temperature, weather, latest post on Hacker News and control your Spotify. But hey, at least that single terminal window now justifies our 450-watt graphics card because it uses GPU acceleration.

Why use a terminal multiplexer when we have GUIs?

One of the top arguments that I’ve heard in all those YouTube videos and social media posts about making Tmux your primary workspace is, that Tmux prevents you from killing a process by unintentionally closing the terminal window.

Something tells me, though, that the people pitching Tmux in 2025 as uLtImAtE pRoDuCtIvItY tOoL, and are using the argument of “preventing accidentally quitting Vim by closing the terminal”, are the same people who had to look up on the internet how to quit Vim a few years ago.

Putting aside the sarcasm, however, it begs the question of how valid of an argument this is. How often does it happen that you accidentally close a terminal window with a running program? Especially one that is really important to not be killed just like that, like for example dd if=os.img of=/dev/sdb bs=1024k?

First of all, a terminal window should only close when the shell process that it spawned has ended. Meaning, that if you open a new terminal window and press Ctrl+d, the terminal window should close. However, if you run sleep 10, vim, or any other program with reasonable key bindings, and press the same key combination, the terminal should not close until the running process is finished. You’d first have to e.g. suspend the process (Ctrl-z) to be able to reach your shell’s prompt for Ctrl+d to have the desired effect and close the window while the process is running.

“But what if my mouse accidentally slips onto the [x] button on the window border and I click it??”, you might ask. Well, first of all, let me ask you: Why are you using a mouse? I THOUGHT WE WERE TMUX-ING NOW?! *screams in Ctrl+b*

Jokes aside, in this case, your terminal should be smart enough to understand that there’s an active process that is not your shell, and have you confirm whether you really want to close that window and thereby kill the process. Also, with a proper window manager, there’s really no need for these little buttons on your window border to begin with. Why would you jump through the hoops of running a piece of software inside your terminal (e.g. Tmux), which by default requires you to press at least four keys (Ctrl+b + x + y to confirm) to close a pane, instead of simply learning the two-key combination required to quit programs through your window manager?

“Okay, but what if I accidentally hit my window manager’s key combo for quitting an app and my dumb terminal emulator doesn’t double-check if that was intentional?”

Well, what if? Again, unless it is a supercritical process that under no circumstances should get killed by mistake, you can just spawn a new terminal window and re-run the command. It’s a minuscule annoyance at most. ¯\(ツ)/¯

For processes that really shouldn’t die, it makes sense to run them in a way that prevents accidental killing. However, you won’t need a Tmux configuration that spans three books for that. As a matter of fact, you can just launch the process using nohup. All the 10+ minutes videos and live streams on YouTube and Twitch, that talk about their overengineered terminal multiplexer setup are not doing it for the sake of running an important command every once in a while in a way in which it stays alive when the terminal window gets closed accidentally, or when the GUI crashes (but somehow the rest of the system survives and keeps running).

My impression is that the sole purpose of the terminal multiplexer hype train stems from a perceived sense of pseudo-elitism that the advocates perceive as being achieved by – amongst other things – setting up and using a terminal multiplexer in a highly customized way. As with other instances of solutionism, more sensible approaches are being ignored or even rejected for something that is inferior on many different levels and more often than not requires specialized knowledge and tools.

Don’t get me wrong, I’m not saying that terminal multiplexers are useless or bad. I regularly make use of screen -x when pairing up to troubleshoot situations on remote hosts. I use tmux extensively on all the machines that I SSH onto – usually in combination with Mosh for improved connection stability. That is because I don’t like sessions being terminated when I lose connectivity, and I also don’t like hammering the machine with multiple simultaneous SSH connections just to work in multiple terminals.

However, there is no connectivity to lose when working with programs on my local machine. If I need to detach from a running process, I just move the terminal window to a different workspace in the background. And if, for whatever weird reason, I have to detach from a running process in that same terminal window, I press Ctrl+z, do whatever I want to do, and then bring it back with fg. And if I need that process to continue while being put in the background, I run bg. And for most other things nohup works just fine. I rarely have to use Tmux locally.

Hence, on a desktop, I fail to see any benefit of running Tmux or any other multiplexer as the primary shell environment. On the contrary, however, I can name at least a dozen disadvantages, starting with the aforementioned prefix key combo, that will eventually get in the way, especially when using TUI tools with key bindings. And don’t even get me started on the horrendous performance. The same people on YouTube, Substack, and other platforms, that boast about how their favorite terminal emulators have GPU acceleration and their own graphics protocol that does 60FPS video playback, then go ahead and cripple the performance by using a terminal multiplexer, tO bOoSt ThEiR pRoDuCtIvItY.

“But… but… I would like to save and restore my workspace and only Tmux allows me to do so?!”

Saving and restoring a layout is a feature that is (or should be) part of the window manager. With Tmux you’re working around your WM’s inability to do so. For example, i3 natively supports saving and restoring layouts. There are also workarounds for Sway, the Hyprland people have it on their to-do list as well, and I bet you there are extensions for proprietary desktops out there that can perform such tasks as well. The argument of using Tmux to save and restore a workspace is moot, simply because your workspace will for sure contain at least one GUI program (most likely a browser) window for which you cannot control its layout with your Tmux script. Unless you’re working via SSH on a remote machine, plugins like tmux-ressurrect are a half-assed solution for a feature that should have been part of your window manager to begin with.

“But… but… but.. plugins..”

… should be part of a dedicated tool (e.g. wtf or wth) running inside a dedicated terminal window, redrawing the information that it displays only when needed; Or a dedicated component of your GUI desktop, like your status bar or desktop widgets. Why would you want Tmux plugins that eat up precious processor cycles to render information like time and date, sensor values, or even weather reports with almost every redraw of the TUI? Especially when these are all things that your GUI desktop environment is far more capable of handling. Unless you’re actually working with a system that has no graphical user interface there’s no need for a terminal multiplexer, nor any of its plugins, and using one will, on the contrary, just lead to unnecessary overhead.

“But… productivity?”

Yeah, right. Then let’s talk about productivity. Assuming you have your Tmux (or Zellij or whatever) configuration ready after watching several twenty-minute videos on YouTube and spending multiple days afterward to fine-tune the shade of the pane divider color. At that point, you had to agree on a prefix, which is a key combination that lets Tmux know that the following key presses are directed towards the multiplexer, rather than the program running in the current window/pane.

According to people on the internet, the preferred prefix key combo to use is something along the lines of Ctrl+b (the Tmux default), Ctrl+a, or Ctrl+Space. To highlight/focus for example the pane on the left side of the currently active one, you’d press Ctrl+b + Left (in the default configuration). This takes three key presses. With terminal windows in a tiling windows manager like i3, however, you can perform the same action by pressing only two keys (Mod1+j, by default), as opposed to a combo of two keys followed by a third one.

This is only one of many examples in which a terminal multiplexer adds unnecessary overhead to your workflow. Not only by having inconvenient key combinations but also by consuming mental space with additional key combinations that are only relevant to the workflow within the multiplexer. Even if you were to configure your Tmux in a way in which you could switch the currently focused pane by only pressing two keys (e.g. Mod1+j):

You will still have to learn a set of key combinations for navigating windows and panes, that are only valid within your terminal multiplexer and that will differentiate from your window manager’s key combinations, that allow navigating within the rest of the graphical user interface.
So instead of learning that Mod1+j will always focus the next window to the left, you are now occupying mental space with Mod1+j for Tmux, and e.g. Mod4+j for your window manager. Whenever you switch panes within Tmux, you have to press the former combo, while switching between Tmux and e.g. your browser will require you to press the latter combination.

This doesn’t sound productive to me, but instead more like an incoherent setup. Productivity would mean the exact opposite: Making all the software that you’re using behave somewhat similar, to free you from the mental load of remembering how to navigate/operate each program. That is ultimately why many tools decide to implement Vi- or Emacs-mode for navigation. That is why we have Surfingkeys and other extensions for our browsers – and even dedicated browsers! – that allow us to continue using the same key combinations and habits that we accustomed ourselves within other programs. You can press Ctrl+t in your browser to create a new tab, and you can (most likely) do the same in your terminal.

“But my desktop of choice doesn’t run i3, Sway, or any tiling window manager!”

There surely exists an extension for your desktop of choice that works around the native window manager’s limitations and emulates a TWM, like Amethyst and Yabai for macOS, or GlazeWM and Komorebi for Windows. And no, just because you’re using a TWM doesn’t mean you cannot have freestanding windows that you can drag around.

One more thing (specifically about Zellij)

Given the odd description of Zellij – “A terminal workspace with batteries included” – I wanted to understand what it is and where it’s heading, as it is clearly trying to differentiate itself from other terminal multiplexers. I found an interview with the Zellij creator, Aram Drevekenin in which he answered the question “What is Zellij?” by giving the following example:

Let’s say you want to convert a video file, okay? To convert a video file, do some editing or something like that. What would you do today?

FFmpeg.

However, the interviewer answered:

You open some user interface, big software like iMovie or something.

Aram counters:

You don’t have it installed.

He continues:

You go to Google or whatever, you search MKV2MP4 or whatever, you find a site that does it for you.

What.

At least for me, that’s the first thing I do. I go to a search engine, do this thing. I don’t care. Track me, show me ads. Whatever.

Whaaaattttt.

And why not do this in your terminal?

Phew, okay, I got confused for a moment. So, terminal, right? Yeah! Why not FFmpeg!

Why not open your terminal?

Yeah, Aram, let’s bring it home!

Have a search engine on the web looking for a plugin for this essentially. MKV2MP4, have an open source thing that someone wrote.

Can I hear that again?

Have a search engine on the web looking for a plugin for this essentially. MKV2MP4, have an open source thing that someone wrote.

Someone like our good friend Jia?

It’s a Wasm file. You download it to your machine. You run it on Zellij. You have a nice interface that shows you do this, do this, and move on. And it’s just one example. I see it essentially in the future as an application platform.

There’s a lot to unpack here. Even if we ignore Aram’s disturbing take on privacy, tracking, and ads and the fact that he seemingly prefers uploading his family vacation video to a random website instead of doing what the interviewer suggested (installing iMovie), and even if we also ignore that his argument against iMovie was that “You don’t have it installed”, but the solution he presented was “a Wasm file. You download it to your machine. You run it on Zellij.”; Even if we ignore all of that, I think that at this point I understood what Zellij intends to be: Another perfect example of solutionism at its worst. Let me cook.

If you want to convert a video on the command line, there are open-source tools for that, searchable and readily available for you to install through the package manager of your choice. No Google, no tracking, no ads. Those tools are command-line tools, and they’re most likely written in high-performance low-level languages like Assembler, C, or C++.

Aram however suggests that instead, people should use Zellij to search and find random WebAssembly plugins on the internet – rather than trusting the package maintainers of the system they use – then download and use those Wasm files to convert what might be gigabytes of video data. The fact that he uses probably the worst possible example (video conversion) to pitch this WebAssembly terminal application platform thing begs the question of whether the Zellij author has ever actually looked at the performance difference of WebAssembly in comparison to native code. And it’s not only performance that makes this example complete nonsense:

Video stuff is hard. Why do you think that nearly a quarter decade later we’re still stuck with FFmpeg, for better or worse? Why do you think that the majority of open-source video tools (e.g. Kdenlive, Shotcut, …) use – you guessed it! – the FFmpeg API for various tasks? Because video is really hard.

The assumption that any person, let alone a group of people, that have the knowledge and the time to write video tools will think to themselves “Oh, today seems like a great day to write a video tool as a WebAsssembly plugin for this Zellij thing that has a handful of users!” is frankly bizarre.

You could argue that maybe Aram referred to a Zellij plugin that would use the FFmpeg API, just like all these other tools do. Okay, fine, so your plugin depends on FFmpeg being installed. How do you install FFmpeg? Oh, wait, through your system’s package manager. So, then why not also install a FFmpeg TUI that is an actual program, through that same package manager, and use that instead of a Zellij plugin?

Putting aside the video tool example, I frankly fail to see how the application platform idea makes sense to begin with. We have an application platform for TUI/CLI programs, it’s called the operating system and it has been around for a looooong time. It has applications, it runs them, and, more importantly, it has safeguards in place that make it harder for random applications we downloaded from the internet to misbehave. For example, when I run emerge to install a new program, it is constrained by the SELinux rules that the operating system imposes on it, and, in addition, I get several confirmation requests from OpenSnitch, that I have to acknowledge for emerge (or its sub-processes) to be able to reach the outside world. When I then run the freshly installed program, I will most likely need to fiddle with SELinux and confirm a couple of OpenSnitch popups as well for it to do anything useful.

Zellij appears to be trying to abstract all that into a new layer, adding a runtime dependency that offers no obvious benefits to the applications, while on the other hand leaving the user at risk by trusting a sandbox to deal with random Wasm files from the internet and implementing a permissions model that is inferior to what the operating system can provide.

“But Zellij is just another tool that is subject to the same SELinux and firewall rules as all the other system programs!”, you’re going to say. Yes, Zellij is, and one can implement a SELinux policy and firewall rules with just enough head space that Zellij can function. However, things change when random code downloaded from the internet gets injected into the Zellij process through its Wasm runtime. All of a sudden the network requests that are made by Zellij and that I approved might not be as safe anymore as I initially thought. The files the Zellij process might access might also be broader now because that dynamically loaded plugin is e.g. a glorified TUI for find that needs access to the entirety of my filesystem to work.

Later in that interview, when asked why WebAssembly, Aram answers that he wants developers to be able to develop Zellij applications in any language that they prefer. So, basically, like on that other application platform that I just mentioned (the operating system), with the only difference being that, let’s say natively compiled Go code, is significantly faster than its Wasm counterpart:

But in terms of percent difference from native implementation, Go has a whopping 1317% longer execution time in wasm.

And don’t get me wrong, I’m not trying to badmouth WebAssembly here. For what Wasm’s main goal is – facilitate high-performance applications on web pages – these execution times are fair enough. However, Zellij is taking this technology that was intended for web pages and is using it on a level well beyond the web: At the system level. The idea to write a Zellij application (plugin) in for example Go, that compiles to Wasm and uses Zellij’s very limited API, rather than building a better performing, native tool using e.g. the powerful Bubbletea TUI framework and utilizing the operating system’s API, doesn’t check out.

Long story short, it feels like Zellij is trying to create artificial needs and, awkwardly enough, still fails to offer a sensible solution to those created needs. Even imagining a more powerful API, I still don’t see how CLI/TUI applications will benefit from being constrained to running within Zellij.

Anyhow, if you’re using Zellij as a terminal multiplexer today, you might be in for a surprise with the vision that the Zellij team appears to have moving forward.