I'd love some perspective on what problem this setup solves and how do you address sandboxing.
I have agents create work queues with little completion bar charts so I can at a glance be aware of all the running tasks (could be subagents as well) and a keyboard only way to jump between sessions.
I am also a big fan of distilling skills into scripts, and the expressiveness of tmux makes it easy to create some easy wrapper commands you let your agent use in a skill rather than having to direct it with verbose skills
What do you mean by sandboxing exactly? Not sure if the other part of my workflow addresses that or not.
One other thing I will say, maybe it is just me, but I have an easier time (even for the first time) moding and customizing tmux than terminals themselves.
But if you have control over your setup, I would use a capable terminal and ditch in-band multiplexers that sit in the middle of the process and your terminal eating up escape sequences and native features while adding latency. Then use a separate tool for session persistence (I like zmx but there are more for this).
You can have a message routing layer entirely on top of tmux with send keys - this way you don't even ever need to see your terminals (but can still see it if you want to).
there is an ios application in testflight and web client, nothing is on the servers, using tailscale through clients or you can use classic remote hosts.
We should compare notes!
Seems like we all get tailored suits now.
1. I have never been able to get copy-paste to work 100% of the time. I'm at about 95% of the time now which has been enough for me to not look into it.
2. Pasting and dragging and dropping non-text content (like images and videos).
At the end of the day I want it to feel like a native, local terminal
Have you tried Kitty? Its remote clipboard integration works over SSH, including images. Might be worth a look.
Firstly, I want to sandbox my agents from each other and from my hard-drive, and partition (and encrypt) secrets, so I use (and wrote) byre[0], and run a devbox with long-running agents for certain tasks. TermRover[1] is a pretty good SSH client for tmux. For a more native integration I have started using Happier[2] which provides a web front-end and iOS app for my sessions too (unified with real Claude Code, so handover is seamless), and put together a byre skill[3] to make that easy.
[0]: https://github.com/pjlsergeant/byre-happier-claude
[2]: https://happier.dev/
The tmux send-keys + terminal scrape is the LLM version of the analog hole of DRM'ed audio.
But don't worry, I'm sure next week it'll all change in some new and confusing way. And not for the benefit of the customer.
PS: This applies to /alot/ of software though...not just tmux. See: vim, emacs, bash, zsh.... the difference between a new or non-learned user is /vast/ compared to someone that spends 10 minutes and learns the basic of these tools. This is one of your first steps into greybeard mastery.
I remember "getting into" vim back in ~2018 because I was doing enough work on headless machines that having a "proper" text editing experience became a must. It was only through this process did I learn about tmux and what it offered.
At some point, VSCode's remote features became good enough that I didn't really need vim anymore (granted, it's still my go-to when needed), but I still use tmux constantly. And, of course, tmux with agents is an excellent combination. The fact that I can have my remote agents interact with my existing tmux sessions is the kind of workflow I dreamed of back in 2018.
Regardless, my point is that you hear a lot of praise for things like vim and emacs, but everyone should prioritize learning tmux well enough to at least be able to navigate it and hand over sessions to agents.
I've used it for years to have consistent keybindings for movement across vim windows and tmux panes. Worked much better than trying to do terminals inside vim.
So claude and I grew the replacement over the course of a few months. Really happy with it. Never looked back.
I tend to use tmux for persistent sessions when ssh'ing to and fro between my own personal machines, but I've never really delved that deep into it when my work computer is a macbook pro and I simply use iterm2 and splits.
Likewise, over on linux, everyone raves about tiling window managers, but I've never really moved beyond a simple L/R split that's easily achievable in every decent floating wm / de.
Or just jump straight into herdr which offers a superset of what tmux offers.
And of Herdr, tmux, vim, and emacs, I still use all 4 regularly :)
All of these tools are great. Which one is better for you will depend on the specifics of your use case and machine
To me, Tmux seems ... not a whole lot better than a terminal. I use a regular old terminal that lets me rename tabs (and lets Claude rename them automatically). I also use VS Code where I have a few sessions in separate panes on one screen. Both those features seem to be Tmux's big selling point.
Why would Tmux be so great that I'd want to learn an entire new app and set of keyboard shortcuts: can anyone explain it in a "this Git thing sounds like what you have, but here's all the awesome stuff you can do with Git branches" kind of way?
tmux is probably my favourite tool by far. I highly suggest going through its documentation (even easier with LLMs now) to learn the basics. It's extremely scriptable.
One of favourite uses of it is its 'popup' feature. Combining the tmux popup with fzf creates a crazy opportunity of whats possible.
Highly suggest learning these tools; literally just point an agent at my comment here and ask it what one could do with tmux popup and fzf combined
I have tried to learn tmux, but the key bindings are really unintuitive to me vs my familiar vim setup
Everything works: you get the native view of subagents, you can upload files and images, fork threads, etc.
The massive upside is that the actual work happens on the server so you can close your laptop and it will continue plus it will not fry your thighs. The advantage over sessions (which I haven't tried but theoretically sound) is that you can configure Claude's environment on the server however you like. Give it any tools you need, ssh access to other machines, sudo, whatever.
The only downside is that every new project requires a setup step on the server (to add the systemd service) where you will develop it since Claude can only handle one server per directory. Claude will handle this step however if you give it ssh access to your server.
The machines show up nicely in Claude Desktop/Mobile/Web, and repos/projects are in a dropdown. Unless you work on very many projects at the same time, this setup is golden.
This is the only downside? You expose your servers to Claude infrastructure and their security. You inherently leave a backdoor open to your system.
I can't wrap my year around how far we backtracked on security standards, to the point people just don't even see the obvious.
Now I am 100% in the ChatGPT desktop app, because it felt I am doing way too much tinkering amd maintenance of my setup instead of doing real work.
Retrospectively, it feels tmux was right choice early this year as the alternatives just weren’t there. It was also fascinating and enjoyable building own workflow from the primitives and I did learn a lot, but the learning has plateued and what was left was mostly chore.
The text content occupies like 20% of the screen, the rest is empty. Resizing the window helps.
Making it wider than about a thousand pixels shrinks the text column down to 400 pixels.
A weird design choice.
As a result I still run sessions and processes I really don’t want to lose inside tmux, nested inside herdr. Tmux never crashes.
It just so happens that it works really well with agentic development as well. I can remote into any shell environment through zmx and tell an agent to execute commands in that environment. `zmx run` executes and waits for the command to complete and also returns the exit code. For humans and agents this is a seamless experience, as if you are running the commands directly.
https://bower.sh/zmx-ai-portal
Apologies for the self-promo.
A nice alternative for ppl who struggle with terminal based solutions. It's a free indie product. https://shikigami.dev <--- more info there
I can do terminal multiplexing better in the GUI—tabs, virtual desktops, or in the browser with xterm.js.
Yes, you can learn all these different tmux shortcuts, and I know them well enough. I like using the shortcuts in my terminal emulator better. All I really want is a way to continue my session after putting my laptop to sleep, and shpool does exactly that and no more.
I haven't check the whole list of features, but I believe herdr can do all the things described in the article (including what tmux offers)
Worked pretty well. Now if I want to automate something like that I would just ask it to write a skill at the end of the session. I'm lazy and I can't remember a couple of hotkeys or commands.
For me (like for many others) tmux didn’t suit the multi agent workflow. Herdr then was too buggy in my experience.
My own tool, Jai, connects to multiple machines, handles multiple agents and enables agent to agent communication.
For those interested: https://michael.sinax.be/jai/index.html
> By hand or from source > To install by hand, download jai-x86_64-unknown-linux-musl (Linux) or jai-aarch64-apple-darwin (macOS) or jai-x86_64-pc-windows-msvc.exe (Windows), check its SHA-256 against latest.json, and put it on your PATH as jai (jai.exe on Windows). You can also build from source with cargo install --path .; those builds don't check for updates.
However I’m not able to find source code anywhere on your github.
No worries if you didn’t open source, only it seems ambiguous currently.
Unfortunately I still have to use macOS and Windows at work, so universal OS window management isn’t a solved problem. I’m happy enough that I can run Emacs everywhere and have consistent keybindings inside Emacs though.
Still though why would you release and announce this before being ready to share the sources? You're telling people to run a shell script that not only fetches and installs a random, closed-source prebuilt binary, but also runs it automatically after fetching it.
Nobody in their right mind should be running this script or recommending it to anybody.
While I agree with you on the unsafe practices, let’s say this is closed source: what is different then? People download and run closed source apps all the time.