Replacing tmux in my dev workflow

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.

    unbind-key C-b
    set -g prefix C-Space
    bind-key C-Space send-prefix

  Host tmux
      HostName 1.2.3.4
      IdentityFile ~/.ssh/etc.etc.etc
      RequestTTY force
      RemoteCommand screen -dR

  alias looptmux='while true; do ssh tmux; sleep 2; done'

  autossh -M0 tmux

This blog post reminds me of _why_ I use tmux. Did you see how much they needed to do to even resemble the workflow of tmux? Jeez, just use tmux. I don't mind dealing with wonky copy and paste once in a while.

> 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.

What does that have to do with you using tmux? You're not the one maintaining tmux's codebase.

    #!/usr/bin/env python3
    import os, base64, sys
    clip = base64.b64encode(sys.stdin.buffer.read())
    for pid in (os.getpid(), os.getppid()): # so that osc52-copy can be invoked by processes that themselves do not have a tty.
        cty = f"/proc/{pid}/fd/1"
        try:
            fd = os.open(cty, os.O_WRONLY)
            if os.isatty(fd):
                os.write(fd, b'\x1b]52;c;') # the actual escape sequence
                os.write(fd, clip)
                os.write(fd, b'\a')
                break
        except:
            continue
        finally:
            os.close(fd)
    else:
        raise SystemExit(f"no tty")

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.

You can get it via

    uv tool install claude-code-tools

https://github.com/pchalasani/claude-code-tools

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.

> 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 still plan to keep using tmux. I like how it manages multiple sessions, making it easy to switch between projects and even resurrect them after rebooting. I also never had a problem with mouse copy / paste using tmux-yank. I've been using this set up for many years.

One cool feature of tmux is its ability to send keys. I did that a few months ago when I was revamping my dotfiles. I kept changing aliases and other shell files and wanted to source those files in dozens of panes at once and also reload neovim when I changed certain config files.

The above was pretty easy to pull off using a combo of tmux's built-in commands and a shell script. I made a post and video about that here: https://nickjanetakis.com/blog/running-commands-in-all-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.

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 have been tempted to drop tmux locally for native Ghostty panes/tabs, but I prefer the single height tmux status bar with window list only (set -g status-left '' + set -g status-right '') vs the thicker window decorations using macos-titlebar-style = tabs.

I did come up with Ghostty bindings to replicate my tmux settings if it helps anyone (my tmux leader is ctrl + space):

    # clear default bindings + add paste back
    keybind=clear
    keybind=super+v=paste_from_clipboard

    # navigate panes
    keybind=ctrl+h=goto_split:left
    keybind=ctrl+j=goto_split:bottom
    keybind=ctrl+k=goto_split:top
    keybind=ctrl+l=goto_split:right
    keybind=ctrl+space>shift+apostrophe=new_split:down
    keybind=ctrl+space>shift+five=new_split:right
    keybind=ctrl+space>space=equalize_splits
    keybind=ctrl+space>z=toggle_split_zoom

    # navigate tabs
    keybind=ctrl+space>c=new_tab
    keybind=ctrl+space>one=goto_tab:1
    ...
    keybind=ctrl+space>zero=goto_tab:10

> Another example is buffer scrollback. It's one of those things where you have to learn the tmux way of scrolling a window. You get used to it, of course, but it's just not great.

   And what about mouse select to copy/paste? It works most of the time, but
   sometimes tmux gets ignored and I'm selecting across splits which makes the
   thing I'm copying impossible to grab without bailing.

funny, those things make me use tmux! My 2nd laptop is a debian terminal-only laptop (it's very old), the mouse doesn't work so the only way to copy paste is tmux (or screen probably but I never learned it) For me, tmux is not replaceable

Kitty is great; I want to see it succeed in pushing terminal emulators forward into the current millennium. However, I can’t use kitty at work, and I absolutely live inside of tmux. The server is where all the action is, and when I get disconnected, I want to be able to pick things up exactly where I left them. Window layout, the state of each shell and text editor, what’s in the copy buffer, scrollback, everything. I can’t give that up unless I have a suitable replacement on Windows. Until then I will continue to use tmux at work and kitty at home.

Interestingly enough, suckless folks took the opposite approach with their terminal:

> Goals … Do not reimplement tmux and his comrades.

( From https://st.suckless.org/goals/ )

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

I keep using GNU Screen

    * Scrolling on TTY (Linux itself doesn’t support this for some years)
    * Window-Tabs on TTY, Wayland, SSH
    * Sessions
    * Copy/Paste

I’m not using ZelliJ or Tmux because I don’t need more features and I know the shortcuts. I’m fine and don’t need weird workarounds. This article even confirms my decision!

Would love some good C developers helping the Screen people.

I'm by no means a tmux power user, but it does have really nice features for when I need it.

The primary usecase I've had for it is I can kick off 1 or multiple long running jobs, exit, and then come back later and checkout the various stdout logs to see how it worked.

Could I accomplish the same thing with a bunch of stdout pipes, disown, fg, ctrl-z, etc? Sure. However, tmux makes it really easy to do that and then quickly switch around sessions to see how things are going.

In the simplest workflow, it looks like this

    tmux
    longcommand()
    ctrl + B D

and later

    tmux -a

to checkout and see what's gone on with the command long after I disconnected with ssh.

Better still, use Emacs as your terminal multiplexer:

https://www.masteringemacs.org/article/replacing-tmux-gnu-sc...

[edit]

The below is fixed (https://github.com/shell-pool/shpool/pull/213/files) upstream already, but is pending a release.

I never heard of shpool, so just tried it. shpool completely breaks my PROMPT_COMMAND because it assumes that each word (in the shell sense) is a separate command. My PROMPT_COMMAND included "history -a" thus causing it to run "history" and "-a" on every prompt, making things quite unusable.

It's quite maddening because all they had to do was write a lot less code to fix it:

    eval "${SHPOOL__OLD_PROMPT_COMMAND}"

Would run the old prompt command just nicely instead of the much longer:

    for prompt_hook in ${SHPOOL__OLD_PROMPT_COMMAND};
    do
        ${prompt_hook};
    done;

I’ve migrated from tmux to zellij. And I’m playing around with omarchy and am really digging the tiling window manager feature

Obviously, different ways for different folks -- I never got into tmux, but perhaps relatedly, what I want is a well thought out and stable terminal/GUI filemanager hybrid thing; e.g. I can either "cd" or just click where I want to go, etc. I've seen half done implementations of this but nothing comprehensive?

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.

I just browsed through to realize that this is not criticism to tmux very existence. It’s just author found his own ways. That’s OK. I was once screen user, tmux extends that, but comes with emacs keyboard combos like if I was doing Mortal Kombat fatality trick for a simple thing and I personally found zellij more user friendly to me, unless I launch my linux box with i3 where all that is basically replaced by a quite interesting compositor. Point is… there are many ways to solve a problem… finding one that works for an individual doesn’t automatically create religious dogma… unless one wants to be internet famous for 72h and then forgotten until another dopamine shot hits.

Tmux has definitely caused me some pain too. I'm mostly back now (semi alas) but for a while I was using shpool adjacent dtach to leave nvim sessions running even if I logout. If I was doing things on the terminal, it would be inside an nvim terminal window.

My workflow is project oriented, and I have to juggle multiple projects. So I wrote a small script to let me quickly either attach to an existing dtach session for a project by name, or to start a dtach+nvim session for a project.

Also included some fun wildcarding, so I didn't have to type the full name of the project out, could just type some letters and hit enter.

https://github.com/jauntywunderkind/dtachment

I don't see change as likely, but it does strike me as absurd that although I had gotten rid of tmux as a redundant window management system, I still had both the OS and nvim's window management going. The author talks about how things would work over ssh, but ideally to me, I could ssh in, forward some ports, and start some new terminal emulators that open multiple nvim clients that attach to a persistent perhaps headless nvim session.

I don't need much. I tried zellij but i couldn't stick with it. I either had to lock/unlock or change keybinds which is also annoying. Now i use ghostty and i can create new splits, tabs and i know few shortcuts to move around and resize and that's it.

It's a bit unclear what the limitations of the non-screen/tmux alternatives are E.g. how does the scrollback work if I were to disconnect and then reconnect with a different machine, can I view the scrollback like screen/tmux?

It's also nice to be able to re-connect and be able to resume a session without having to reopen many terminals, which you would lose with the lack of window management.

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).

My fingers are just too used to tmux and I can do all I want to do. But I hear the scroll issue. When I have to copy multiple chunks, I have to go to cp mode visual a chunk and as soon as I enter tmux goes to the bottom line and I have to scroll up again…

All good points relating to friction points with tmux.

But, I am not an uber-elite-geek and Zellij is a good enough compromise to me.

It gives me the things I am too lazy to solve by myself like tmux, with a lot less pain points.

Switching to WezTerm has completely eliminated the need for tmux for me - except for stuff I want to run server side, disconnect and come back to.

The conclusion I come to from this is that yes, I actually do need tmux, as the alternatives proposed are far more annoying and provide no benefit. I don't have a need for graphics in the terminal, and frankly I find it odd that we wouldn't simply display graphics... with the graphics system. But I do have a need for seamless session persistence and multiple terminals, and I do enjoy splitting a window when I'm running a command on multiple servers.

If you're using kitty and have terminal related problems the easiest solution usually is just not using kitty.

Don't use tmux. Use a nice wrapper for tmux instead (e.g. like byobu).

Otherwise complaining about tmux and talking about hacky workaround alternatives is a bit like complaining about the internet and advocating for the telegraph as a hacky alternative because you don't like writing your own HTTP requests by hand and morse code is so much simpler.

Having said that, if really all you want is pane splits / window management, lots of terminals have their own solutions for this. Guake is a good one.

disclaimer: I use Guake and still prefer to just use tmux (byobu) from Guake

I need "tmux" on remote linux machines that don't allow me to install "screen". If there's an easier way to keep a session running (and interactive) over internet disconnects, I have not found it yet

If I were to stop using tmux, the things I would need to replace are:

1. zoom-pane (temporarily make one pane be the only pane) (also can someone please add this to vscode!)

2. keybindings to navigate focus between panes according to their layout positions

3. ability for another process to programmatically change which terminal window has focus, and window naming

I think that's it. Could probably hack most/all of that together with hammerspoon I guess. I don't use it for persistence, and I certainly don't like the scrollback UX. It has got in the way from time to time, principally with its slow adoption of hyperlinks. But I'm general it's been a huge win for years.

Correct statement, but poorly chosen alternatives: zellij is like tmux, but with less scrollback issues and supports mouse.

It is also extensible.

I only use tmux for one reason -- for a script that setups my local server and runs backend/frontend/etc

If there's a better way, I'm open to it. As of right now Claude can't vibe code me a script that opens two ghostty tabs, so tmux it is

If your main issue is session persistance you should try using mosh

Most important tmux functionality is substituted with a window manager and a terminal emulator with normal mode support: https://wiki.archlinux.org/title/Alacritty#Vi_mode_and_copy/...

But I agree that tmux sessions are convenient.

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).

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...

AFAIK this doesn't exist, so I'm using tmux...

This sounds strictly more complicated than just using tmux.

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.

I don't use tmux because I have to. I use it because I love the way it works. The issues the author of the article and Kovid Goyal raise are not issues for me in practice. If something is built that better suits my needs, I'll be happy to switch. I am particularly sympathetic to Goyal's gripes about the performance/resource wastes of a multiplexer.

But I also take issue with statements like "terminal multiplexers are a bad idea, do not use them, if at all possible" (from the kitty FAQ and the YouTube video linked in the article). Tmux solves a number of real problems for me that Kitty doesn't. Kitty also seems to be moving in a direction that I am not interested in. It's tied to a windowing system when I want a terminal that I can use headless. Even with the hacky workarounds the article mentions, it doesn't really support session persistence when I use this feature of tmux weekly. It introduces a lot of features that are likely to lead to visual noise when the constraints of text-only are one of the main reasons I like terminals (personally I don't want images in my terminal, full stop).

Now, all of this is fine. It's the other statement, "[tmux acts] as a drag on the ecosystem as a whole, making it very hard to get any new features," that causes it all to rub me the wrong way. The only reason you feel like tmux acts like a drag is because there are users like me who won't switch to something like Kitty if it doesn't support tmux. So don't worry about us. Build a new thing that is not backwards compatible and live with the fact that many people won't use it. If you really want to drive the ecosystem forward as a whole, be less condescending about real use-cases that bring benefit to real users.

To be clear (because text is a limited medium), I'm not grumpy, angry, or against Kitty because of this. But I am dismissive.

I highly recommend zellij if you’re looking for a newer multiplexer. It give a bunch of tmux features but without some of the legacy baggage.

Zellij has started to become messy in my setup (i don't mean to blame zellij, i just suck), so I'm looking into tmux now.

I liked the fact I didn't need to set anything up for Zellij and could gradually add stuff

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.

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.

Why would one go through so much trouble when you have tmux?

But I really want Vim to color properly in it, can anyone give me the right solution?

> 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.

I just use Emacs for this.

I am regularly using waypipe to use a remote kitty terminal.

Sounds like work-arounds and duck-tape-tier re-implementation of tmux features, to be honest.

I'm still a gnu screen guy, but for me the trade-off is still in favour of screen/tmux.

Honestly, my only gripes with TMUX have been:

1. Having to zoom a window before copying multiple lines of text (Kovid brought this up in the interview that was mentioned in this article)

2. The weirdness of copying text from the scrollback buffer into the clipboard

I've tried so many things for the second one over the years. I think I have it working okay-ish these days. But there are still plenty of times that I say, "aw screw it", and literally use the terminal's copy command.

Every other solution to my multi-terminal workflow have been worse though! i3/bspwm with multiple terminals were okay. It was just hard to have "projects". I'd have to visit each terminal and switch to the proper directory, launch servers/docker-compose/etc.

Zellij felt like too much "hopping out into manipulation mode, manipulating, then hopping back into work mode". Those milleseconds were enough to halt my flowstate.

Single terminal with built-in tabs/splits felt clunky as I couldn't get the keyboard shortcuts into muscle memory (perhaps more time would help)

TMUX supports sixels just fine. It's a damn standard, and you have it at OpenBSD's base. Keep It Simple, Stupid.

Also, tmux new-window does wonders with software spawned from sfeed, sacc and who knows how many TUI/CLI tools.

You open your RSS feed list with sfeed, read the whole page with C under 'less', and if there are images, you can spawn Links in another page with 'o'.

You lost me at nohup.

very interesting. im going to continue using tmux instead of doing any of that.

I love tmux in combination with tmuxinator. Because with one command I can start my dev setup with one split for nvim, one for lazygit, one for yazi and one for claude code. In another window I can run the server, in another I can tail the logfiles.

I have similar setups for various projetcts and do not need to manually start services, tools, whatnot. With `mx projectx` everything is started within seconds.

And navigating panes and windows is super easy with the proper shortcuts (opt+h,j,k,l), even across tmux and nvim.

Why would I give up on that?

Tmux prevents vendor lock-in but on Terminal level. It's so established and standard that everyone knows they need to support it, which is great. I don't need my terminal do display pictures, render video or whatever crazy features they come up with next, I want a solid base with the essentials.

The rest the Operating system applications can probably do better anyway. VLC, MPV, Apple Preview IrfanView etc.

That's why I love Alacritty, no fuss, no overcomplication. The basics, fast and stable.

Reminder: terminal multiplexers (like TMUX, Zellij, and Screen) are terminals too — even if often overlooked as such.

So, if your multiplexer lacks support for certain features, it will limit functionality in advanced terminals like Kitty or Ghostty.

If I could just figure out how to scrollback in ghostty I probably wouldn’t bother with tmux.

I was in the same boat then I discovered this thing called a GUI and inside this GUI I could use this thing called tabs. It was revolutionary technology.

It’s just too bad I suffer from a lack of common sense and insistence on trying to believe that all archaic terminal text based tools are better than anything else. I’m a developer and developers have insight on the best UI and we know that terminals are better than anything in the known universe. If you use a mouse you’re an ass hole.

i smell copium