If you aren't familiar with tmux(or GNU screen), you owe it to yourself to become familiar. If you are a deveoper/sysop/cli-type it will act as a force multiplier. It takes 10 minutes to get setup and learn the basic hotkeys - and you will save many orders of magnitude of your time. One of the best learn-some-software investments you can make IMHO.
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 actually migrated away from tmux because I became tired of using one set of keybindings to manage my terminal windows, panes and splits, and another set for my file buffers inside Emacs. Now I run my terminal emulator inside Emacs so I get the same keybindings for file windows and terminal windows.
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.
I actually migrated away from tmux because I became tired of using one set of keybindings to manage my terminal windows... and another set for every other os window. I also wanted gui apps being part of the session, not just terminals.
So claude and I grew the replacement over the course of a few months. Really happy with it. Never looked back.
Oh yeah. I actually use Forge[0] on my Linux desktop machine at home which allows me to customize the keyboard shortcuts for tiling and managing OS windows.
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.
>If you aren't familiar with tmux(or GNU screen), you owe it to yourself to become familiar. If you are a deveoper/sysop/cli-type it will act as a force multiplier.
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.
Not sure why my other reply was flagged, I think it's objectively correct. Different tools for different purposes, and all that. Not unlike emacs vs vi(m), actually. (With vi/vim being more minimal, but also more often preinstalled or available OOTB versus emacs)
And of Herdr, tmux, vim, and emacs, I still use all 4 regularly :)
If you want a little bit more of a batteries-included experience, Zellij[1] is to tmux what Fish is to Bash and what Helix/Neovim is to Vim. If you like any of those, I highly recommend giving Zellij a try.
I gave it a try earlier this year but because of some bad incompatibility with Codex I had to go back to tmux, and then I just never picked Zellij back up. I thought about giving it a shot, but now I'm reading about herdr here which seems pretty cool too.
15 years ago I thought: should I go all in on i3 or tmux ? both manage windows for me, I don't need to learn both tools. Since I use web browsers for my work, I decided to go all in with i3. I don't regret that choice but I regret seeing the problem as "this or that" when I could have mastered both.
I used both for a long time. i3 for non-terminal work, and tmux in the terminal. Loved it, and am ready to move back to Linux for better OS-tiling management. I also ran it on OpenBSD on my laptop as a daily driver for about ~9 months. Loved the security/simplicity, but made it more difficult or impossible for certain Linux only tools.
Genuine question: when there's new tech, sometimes it's legitimately useful and hard to appreciate (e.g. Git: it seemed no better than SVN at first, it required new commands to learn, etc.) ... but when you started using it, you soon realized how powerful it was.
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?
Its mostly useful for remote sessions as you can use one ssh connection for multiple terminals, and of course the most common usecase, leave processes running after you logout (or if the connection drops).
does your terminal on your laptop smoothly resize to match the same terminal session constrained by the screen dimensions of the phone you just opened it on so that you can monitor something from either? can you easily switch to a different terminal tab by name based on the output of something you just ran? can you have each ssh login pop open a new gui terminal tab you can later switch to interacting with locally?
the capture-pane, send-keys, set synchronize-panes on/off are somewhat difficult to pull off when targeting one terminal from another. For scripting or even simple functions that depend on multiple terminal states, being able to reliably read and write to a terminal become rather essential primitives.
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
honestly, I use nvim as my terminal (via lazy vim guy's terminal plugin), and I wish that there was a better way to vibe code in just nvim without having to leave it.
I have tried to learn tmux, but the key bindings are really unintuitive to me vs my familiar vim setup
I know its a hard sell, but once you configure tmux with the exact keybindings that work for you and get them into muscle memory, then working with tmux is such a joy.
You can just install Claude Code on the server and drive it from Claude Desktop via remote control. That way you can control Claude Code on mutiple servers straight from your Claude Desktop, Mobile or Web, and stay fully within Anthropic tools.
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.
I put tailscale on my desktop and run my AI sessions in tmux (or per that other HN topic, anything with persistent attachable sessions).
Now I can termux in from my phone or laptop and keep the work going. Not everyone has a spare desktop sitting around, but I like having freedom of provider and keeping the actual filesystem on my machine.
I’ve been thinking about something similar using a pizero2w on a little rover thing i have. Turn cc loose writing the software to drive it around while reading sensors for obstacle avoidance. It would be cool to prompt “drive to the wall, turn around, and come back” and see if it could figure it out.
I used Claude Code in tmux since January until August.
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.
tmux is still nice for remote work And it's even nicer when you want to have a different harnesses communicate with each other. I typically have a group of them working on the same thing, and typically it is Codex, Claude Code, and Pi. Sometimes I include agy if I need some Google specific capability, and it's very easy for them to communicate. I basically evolved something like a poor man's version of Claude Code's new projects But the nice thing is that I can have different coding harnesses other than cc working on a specific tasks.
The CSS of that website is weird in general, seems to be coming from whatever the kids use today that works like Dreamweaver. The width is so small because the layout is a grid for some reason, although it's just two columns. That same column has a "min-width: 0" and seems like that's happening in more places too, properties set to their defaults? Looks really strange overall.
fwiw, I like to set max-width of columns of text to about `64ch`. In smaller view ports I may go down to about 45ch. But I feel the range of 50-65ch is ideal for reading. Setting to 20% or 20 vw is a bit dangerous for this precise issue.
This is why good browsers have a reader mode. Click a button and you can make it easily readable for you if you have challenges reading. I don't know why you would resize the window. Just use reader mode.
I really liked Tmux and Zellij for the time being, but Herdr does it all so much better out of the box when it comes to agentic coding. I haven't found something I can do with tmux/zellij but can't do with herdr.
Maybe I didn’t give it enough of a shot, but I fond herdr was solving the wrong problem for me. I want to manage shipping work, gtd, not a bunch of agent sessions. The sessions are an implementation detail that I prefer jumping into only when something is wrong.
You can. I use it exactly that way with the individual terminal sessions accessible.
I'm mostly using it now because it integrates with ssh while still supporting image paste. I also use it via it's json API for a harness I'm working on which is agent agnostic.
I do expect I'll move off it if it becomes hostile and another tool takes it's place.
My only problem with herdr is its propensity to randomly crash and take out the whole session. At one point it was crashing once or twice a day, recently it’s more like every two weeks, but it still crashes. I have auto session resume on but that still means ongoing work is interrupted and I have to manually restart all the long running non-agent processes.
As a result I still run sessions and processes I really don’t want to lose inside tmux, nested inside herdr. Tmux never crashes.
If you’re mainly just using Claude Code, “$ claude agents” view is a good alternative coupled with tmux. I’m curious if herdr does other things though.
I built zmx because I wanted a simpler session persistence model that also supported remotely running, tailing, and waiting for commands to finish.
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.
Like others here I created my own terminal multiplexer as well. Daemon that holds all sessions, seamless binary upgrades so those sessions never get lost, everything recorded so recovery is always possible, thin client mode so laptop has a native app that connects to daemon, and a wasm responsive webui with transcription so I can carry on with sessions from phone. Claude/codex sessions started with a uuid so they can be killed/resumed at will (mine autosleep after 12h inactivity to free resouces). CLI allows agent control of everything for a harness independent implementation of claude's channels. A few friends have forked and adopted it as their daily driver. Similar organization to herdr wrt spaces to organize sessions. Optimized for speed/bandwidth when running in thin client mode.
Shameless plug but I hit these exact same kinds of walls and I tried out alternatives like agent-deck or herdr, but ultimately didn't enjoy the TUI approach that herdr/Tmux solutions offer, so I built Muster [0] and I'm quite proud of it -- it's turning out really well and is my daily driver at home and at work. It uses libghostty so I get the same sort of Ghostty-feel as Ghostty by itself provides. It supports SSH / remote machines well too and allows agents from different harnesses to message and work together thru 'muster daemons'.
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.
Each session loads about 39.6k tokens of config before I type anything, so running several in parallel multiplies that. With lots of subagents, this overhead is even easier to overlook.
It's always been a chore to keep sessions (and tmux windows) at a minimum to avoid context switching and the cognitive drag/fatigue that comes with too many. My goal is 2 active sessions to avoid context switching, but it's so easy to just take on more tasks and try to cycle between all of them, and accomplish less overall. I've had upwards of a dozen, and it is very draining. Even more panes within windows to track subtasks becomes unruly. The other problem is that work keeps ballooning as agents pick up related/unplanned work along the way all the time. I try to reign things in by having the agent create tickets that we will revisit during planning sessions later. By keeping tasks minimal, it feels slower, but then I can think deeply about the problem without the cognitive residue coming from all the other sessions.
I used to use tmux & Claude on a Mac mini, but I gave it away when herdr came around - there were just too many tmux sessions to maintain and herdr does a better job at showing you what’s open. Admittedly, your tmux setup looks far more sophisticated than what I was doing. However, the new claude code projects is insane and a step above on having claude being a real project manager across sessions.
Tmux is a good way to orchestrate sessions and keep them observable and interactive. I can easily adapt it to whatever mental model I need to get the job done.
Been using tmux session to hand over to claude for a while. Paranoid me uses the macbooks secure enclave with fingerprint for the ssh key so claude can't ssh into my remote boxes by himself. I then open named tmux sessions, perform the ssh login via fingerprint, and then tell claude that he is free to take over that session with a given name.
That’s the same reason I started using the Secure Enclave SSH access for HomeAssistant: I wanted to grant agentic access, but I also didn’t want my house’s automations being blown up. Everything is written offline as IaC, and gets pushed with explicit approval only.
I've been using shpool these days (especially for things like Claude / Codex / etc). Shpool only does persistence, not multiplexing. It turns out this is exactly what I want. I want to have one keyboard shortcut, to detach the session, and that's it.
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.
Interesting. I’ve been using it heavily on macOS (ssh to Linux host) and over the web using xterm.js, and it’s been working about as reliably as tmux did. Sometimes it doesn’t resize properly, but that’s also true of tmux (when I see a big field of .).
So many commands. I just started claude in a new tmux session with iterm. Told it it's running in tmux with iterm and it should spawn subagents into separate tabs. When I wanted to know the status of the fleet I just asked the primary agent.
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.
herdr (supercharged tmux) has also mouse keybindings. So instead of remembering how to split a pane, you just right click with the mouse and choose "split" from the popup menu
The documentation does mention building from source, maybe edit it or add a note to avoid confusion?
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.
I mean you still went through the trouble (unless you don't check the AI's output at all) to design this entire prebuilt release process, and then encourage people to blindly run it. Regardless of what you want to achieve with this post here, you should expect this kind of pushback if you promote unsafe practices like that.
Well I am using this release process myself (and a couple of friends), along with the auto update feature. So it is still self centered.
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.
Looks interesting but I’m confused if you published your source code or not.
> 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.
I've been doing this for a while with jaiver (made by me). Just expanded it recently to work with another tool that allows access via Telegram, because I've been on a crusade to make everything on my desktop mobile-accessible.
Similar others I have had a lot of success just hand rolling a terminal multiplexer that fit my workflow — somewhat similar to herdr but works a little bit how I had my set up working with git worktrees and agents. Terminal native, and optimised for speed.
I honestly haven't used herdr off a lot myself, but the main thing that jumped out was organising projects. With domux projects can have workspaces which are git worktrees that domux manages, and you can run agents inside them. That helps me see at a glace what workspaces I have in flight, and the work each agent is doing inside them. The navigation is different as well — with cmd+k like experience to rapidly switch between agents.
I created my own harness tcode (https://github.com/wb14123/tcode) to leverage tmux and neovim. Have been using it all the time since the beginning of this year.
How are folks on windows using tmux or tmux-like tools? Tmux inside git bash is really slow. Any other tools? I know I can use WSL but due to some deployment constraints I can’t use it.
Honestly WSL sucks. Even msys2. My current client forces me to use windows to access their data, and I really, really tried to make it a dev machine, it just MS made it such a shit experience. I had scoop, I had msys2, I had WSL2, etc ... My mere setup (nvim, tmux, or even herdr, etc ...) all run very slow. nvim is barely usable. Where is on my nearly 10 yo voidlinux notebook of 4GB, it runs amazing. Something about MS bloatware will never disappoint.
I use AI Agents inside tmux since last year, the main motivation at that time was to avoid lost the session if I close the terminal by accident - now all of them have --resume
tmux is great, specially when you need persistence in a remote server where you don't want or can't install any other software, and when you are stuck with some 2010 terminal emulator.
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).
Like everyone else here I have mine as well. My motivation was:
- A way to 'resume' my whole workflow after restart or shutdown
- Visual way to verify which sessions are running still, which need my assistance, and which are actually done
- Something lightweight I could bake into an orchestration layer
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.
I went down this path over 6 months ago and had a variety of custom setups using tmux, cmux, and more. But since using Orca IDE it feels like a leap in usability and robustness.
I love CMUX and some people I know who were building their own tmux setups bailed and just started using CMUX -- The built in browser and associated bash tools are awesome but really just having workspaces with colors and todos that survive a refresh makes it worth it if you run a bunch of agents at one time
Isn't this the wrong architecture? Fundamentally, a coding agent should be running as a headless/detached process, a daemon. If it needs a CLI then that CLI can attach/connect to that daemon and interact with it. If you architect it that way then you can quit and resume the CLI anytime you want, from any machine you want and with whatever UI you want, the daemon doesn't care. Running the agent as an interactive CLI process which you need to stuff into something like tmux is just the wrong approach, and "connecting" to it by reading/scraping its screen is terrible.
Or, wrong by design. There is something about nudging users to use the claude CLI from which Anthropic extracts value. Otherwise they would not charge extra for "claude -p" or ACP access.
The tmux send-keys + terminal scrape is the LLM version of the analog hole of DRM'ed audio.
Wait, is `claude -p` usage counted differently? I've built something of a multi-agent daemon system and use `-p` extensively. Now I'm wondering if I'm burning my credits faster.
If you are paying for the API anyways, I don't think it makes a difference. What is different is if you are on a subscription then you need to pay more to use `claude -p`. But then Anthropic started adding free credits, at least for Team and above plans, to offset the cost. Drug dealer pricing.
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.
tmux kind of is that daemon. The agent keeps running on the box and I attach from my laptop or phone. What I was missing was everything around it, like paste and files.
tmux is also a great primitive to build on top of.
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).
I've made a terminal that is essentially ghostty + herder, but all natively and has a session persistence. https://thurm.rs
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.
hehe, I also have done the same, but I'm building on top of tmux. Though much more minimal in scope. https://kido.tools (website showcases the TUI only but there's native macOS app in the PR which I'm using but still refining).
p.s. it has a daemon and automatically installs claude/codex/pi skills so the agent knows how to control and script the panes, tabs and everything else. It is also heavily inspired by Rex's design.
I've been using ghosty + ssh + mosh + tmux + claude code (sometimes codex) for a while now. It works well but the few things that still piss me off:
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
I don't use tmux. I run Claude Code in Cursor windows, and each window title shows the folder name, so that's how I tell them apart. It rarely gets confusing, and an app I built for myself made it a lot easier.
One overlooked thing about tmux is it is designed for the world of 80x24 terminals so it works really well on mobile terminals like terminus while web interfaces have to be redone for smaller screens and don't quite have all the features of the full web apps.
If you aren't familiar with tmux(or GNU screen), you owe it to yourself to become familiar. If you are a deveoper/sysop/cli-type it will act as a force multiplier. It takes 10 minutes to get setup and learn the basic hotkeys - and you will save many orders of magnitude of your time. One of the best learn-some-software investments you can make IMHO.
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 agree.
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 actually migrated away from tmux because I became tired of using one set of keybindings to manage my terminal windows, panes and splits, and another set for my file buffers inside Emacs. Now I run my terminal emulator inside Emacs so I get the same keybindings for file windows and terminal windows.
I wonder if something similar to this vim plugin exists for emacs: https://github.com/christoomey/vim-tmux-navigator. Or you could maybe vibecode one yourself now.
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.
Inside Emacs I use winum mode and I can’t go back to directional moves like up/down/left/right any more.
I actually migrated away from tmux because I became tired of using one set of keybindings to manage my terminal windows... and another set for every other os window. I also wanted gui apps being part of the session, not just terminals.
So claude and I grew the replacement over the course of a few months. Really happy with it. Never looked back.
Oh yeah. I actually use Forge[0] on my Linux desktop machine at home which allows me to customize the keyboard shortcuts for tiling and managing OS windows.
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.
[0]: https://extensions.gnome.org/extension/4481/forge/
>If you aren't familiar with tmux(or GNU screen), you owe it to yourself to become familiar. If you are a deveoper/sysop/cli-type it will act as a force multiplier.
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.
Yeah, I've migrated away from tmux and back to using terminal windows.
> If you aren't familiar with tmux(or GNU screen), you owe it to yourself to become familiar
Or just jump straight into herdr which offers a superset of what tmux offers.
Not sure why my other reply was flagged, I think it's objectively correct. Different tools for different purposes, and all that. Not unlike emacs vs vi(m), actually. (With vi/vim being more minimal, but also more often preinstalled or available OOTB versus emacs)
And of Herdr, tmux, vim, and emacs, I still use all 4 regularly :)
[dead]
If you want a little bit more of a batteries-included experience, Zellij[1] is to tmux what Fish is to Bash and what Helix/Neovim is to Vim. If you like any of those, I highly recommend giving Zellij a try.
[1] https://zellij.dev/
I gave it a try earlier this year but because of some bad incompatibility with Codex I had to go back to tmux, and then I just never picked Zellij back up. I thought about giving it a shot, but now I'm reading about herdr here which seems pretty cool too.
15 years ago I thought: should I go all in on i3 or tmux ? both manage windows for me, I don't need to learn both tools. Since I use web browsers for my work, I decided to go all in with i3. I don't regret that choice but I regret seeing the problem as "this or that" when I could have mastered both.
I used both for a long time. i3 for non-terminal work, and tmux in the terminal. Loved it, and am ready to move back to Linux for better OS-tiling management. I also ran it on OpenBSD on my laptop as a daily driver for about ~9 months. Loved the security/simplicity, but made it more difficult or impossible for certain Linux only tools.
I was using zelij, before that tmux, and before that gnu screen. Now I’m pretty happy with herdr and their integration with agents
All of these tools are great. Which one is better for you will depend on the specifics of your use case and machine
Genuine question: when there's new tech, sometimes it's legitimately useful and hard to appreciate (e.g. Git: it seemed no better than SVN at first, it required new commands to learn, etc.) ... but when you started using it, you soon realized how powerful it was.
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?
I don’t see much of a benefit locally but for remote machines over ssh it’s pretty nice.
Its mostly useful for remote sessions as you can use one ssh connection for multiple terminals, and of course the most common usecase, leave processes running after you logout (or if the connection drops).
does your terminal on your laptop smoothly resize to match the same terminal session constrained by the screen dimensions of the phone you just opened it on so that you can monitor something from either? can you easily switch to a different terminal tab by name based on the output of something you just ran? can you have each ssh login pop open a new gui terminal tab you can later switch to interacting with locally?
the capture-pane, send-keys, set synchronize-panes on/off are somewhat difficult to pull off when targeting one terminal from another. For scripting or even simple functions that depend on multiple terminal states, being able to reliably read and write to a terminal become rather essential primitives.
Came here to add this as well.
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 hadn't heard of this feature, so I looked up a video of what it is. Turns out I'm using this every day!
honestly, I use nvim as my terminal (via lazy vim guy's terminal plugin), and I wish that there was a better way to vibe code in just nvim without having to leave it.
I have tried to learn tmux, but the key bindings are really unintuitive to me vs my familiar vim setup
I know its a hard sell, but once you configure tmux with the exact keybindings that work for you and get them into muscle memory, then working with tmux is such a joy.
Or skip it and just learn emacs.
You can just install Claude Code on the server and drive it from Claude Desktop via remote control. That way you can control Claude Code on mutiple servers straight from your Claude Desktop, Mobile or Web, and stay fully within Anthropic tools.
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.
> The only downside
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.
I feel like everybody forgot that prompt injection is not solved
Is it better if these are pure development servers, that are only used for Claude to create software?
I put tailscale on my desktop and run my AI sessions in tmux (or per that other HN topic, anything with persistent attachable sessions). Now I can termux in from my phone or laptop and keep the work going. Not everyone has a spare desktop sitting around, but I like having freedom of provider and keeping the actual filesystem on my machine.
I’ve been thinking about something similar using a pizero2w on a little rover thing i have. Turn cc loose writing the software to drive it around while reading sensors for obstacle avoidance. It would be cool to prompt “drive to the wall, turn around, and come back” and see if it could figure it out.
I used Claude Code in tmux since January until August.
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.
tmux is still nice for remote work And it's even nicer when you want to have a different harnesses communicate with each other. I typically have a group of them working on the same thing, and typically it is Codex, Claude Code, and Pi. Sometimes I include agy if I need some Google specific capability, and it's very easy for them to communicate. I basically evolved something like a poor man's version of Claude Code's new projects But the nice thing is that I can have different coding harnesses other than cc working on a specific tasks.
This website is so hard to read on a 15" retina screen.
The text content occupies like 20% of the screen, the rest is empty. Resizing the window helps.
Firefox reader view is made for this issue. Adjust the content width slider a bit and it's great.
The CSS of that website is weird in general, seems to be coming from whatever the kids use today that works like Dreamweaver. The width is so small because the layout is a grid for some reason, although it's just two columns. That same column has a "min-width: 0" and seems like that's happening in more places too, properties set to their defaults? Looks really strange overall.
Ironically, making my Firefox window smaller - about 830 pixels wide - made the text content wider, taking up the full width.
Making it wider than about a thousand pixels shrinks the text column down to 400 pixels.
A weird design choice.
remove. works fine. `.guide-page[data-astro-cid-oph4gsm4] { max-width: var(--max-w-narrow); margin: 0 auto; padding: 2.5rem 1.5rem 2rem; }`
It was unpleasant on a 27" 1440p monitor as well. I think the content is just too narrow in general.
fwiw, I like to set max-width of columns of text to about `64ch`. In smaller view ports I may go down to about 45ch. But I feel the range of 50-65ch is ideal for reading. Setting to 20% or 20 vw is a bit dangerous for this precise issue.
This is why good browsers have a reader mode. Click a button and you can make it easily readable for you if you have challenges reading. I don't know why you would resize the window. Just use reader mode.
I have it, was just curious.
I really liked Tmux and Zellij for the time being, but Herdr does it all so much better out of the box when it comes to agentic coding. I haven't found something I can do with tmux/zellij but can't do with herdr.
Only problem with Herdr is the VC funding. Not sure what the rug pull will be, but it's coming sooner or later.
Maybe I didn’t give it enough of a shot, but I fond herdr was solving the wrong problem for me. I want to manage shipping work, gtd, not a bunch of agent sessions. The sessions are an implementation detail that I prefer jumping into only when something is wrong.
You can. I use it exactly that way with the individual terminal sessions accessible.
I'm mostly using it now because it integrates with ssh while still supporting image paste. I also use it via it's json API for a harness I'm working on which is agent agnostic.
I do expect I'll move off it if it becomes hostile and another tool takes it's place.
My only problem with herdr is its propensity to randomly crash and take out the whole session. At one point it was crashing once or twice a day, recently it’s more like every two weeks, but it still crashes. I have auto session resume on but that still means ongoing work is interrupted and I have to manually restart all the long running non-agent processes.
As a result I still run sessions and processes I really don’t want to lose inside tmux, nested inside herdr. Tmux never crashes.
As a counterpoint, I use herdr in WSL/windows and has never crashed for me.
If you’re mainly just using Claude Code, “$ claude agents” view is a good alternative coupled with tmux. I’m curious if herdr does other things though.
I built zmx because I wanted a simpler session persistence model that also supported remotely running, tailing, and waiting for commands to finish.
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://zmx.sh
https://bower.sh/zmx-ai-portal
Apologies for the self-promo.
I use zmx daily, it’s a great piece of software. Thanks for your work!
Like others here I created my own terminal multiplexer as well. Daemon that holds all sessions, seamless binary upgrades so those sessions never get lost, everything recorded so recovery is always possible, thin client mode so laptop has a native app that connects to daemon, and a wasm responsive webui with transcription so I can carry on with sessions from phone. Claude/codex sessions started with a uuid so they can be killed/resumed at will (mine autosleep after 12h inactivity to free resouces). CLI allows agent control of everything for a harness independent implementation of claude's channels. A few friends have forked and adopted it as their daily driver. Similar organization to herdr wrt spaces to organize sessions. Optimized for speed/bandwidth when running in thin client mode.
https://github.com/zackham/seance
Shameless plug but I hit these exact same kinds of walls and I tried out alternatives like agent-deck or herdr, but ultimately didn't enjoy the TUI approach that herdr/Tmux solutions offer, so I built Muster [0] and I'm quite proud of it -- it's turning out really well and is my daily driver at home and at work. It uses libghostty so I get the same sort of Ghostty-feel as Ghostty by itself provides. It supports SSH / remote machines well too and allows agents from different harnesses to message and work together thru 'muster daemons'.
[0] https://github.com/amterp/muster
I am doing tmux + Claude but I wanted a bit more.
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
[1]: https://termrover.sh/
[2]: https://happier.dev/
[3]: https://github.com/pjlsergeant/byre-happier-claude
Each session loads about 39.6k tokens of config before I type anything, so running several in parallel multiplies that. With lots of subagents, this overhead is even easier to overlook.
After using Tmux since 2015, I started using herdr for agents, and it's pretty great.
Have you tried workmux? It gets you 90% of herdr but through tmux (or any terminal multiplexer).
This is essentially an ad for crystl.
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)
It's always been a chore to keep sessions (and tmux windows) at a minimum to avoid context switching and the cognitive drag/fatigue that comes with too many. My goal is 2 active sessions to avoid context switching, but it's so easy to just take on more tasks and try to cycle between all of them, and accomplish less overall. I've had upwards of a dozen, and it is very draining. Even more panes within windows to track subtasks becomes unruly. The other problem is that work keeps ballooning as agents pick up related/unplanned work along the way all the time. I try to reign things in by having the agent create tickets that we will revisit during planning sessions later. By keeping tasks minimal, it feels slower, but then I can think deeply about the problem without the cognitive residue coming from all the other sessions.
[dead]
I used to use tmux & Claude on a Mac mini, but I gave it away when herdr came around - there were just too many tmux sessions to maintain and herdr does a better job at showing you what’s open. Admittedly, your tmux setup looks far more sophisticated than what I was doing. However, the new claude code projects is insane and a step above on having claude being a real project manager across sessions.
Tmux is a good way to orchestrate sessions and keep them observable and interactive. I can easily adapt it to whatever mental model I need to get the job done.
https://github.com/jdonaldson/headless-horseman
I work on a GUI multi-agent harness & IDE (claude, codex, opencode,vibe). It has MCP for supervisor agents to delegate tasks and receive feedback.
A nice alternative for ppl who struggle with terminal based solutions. It's a free indie product. https://shikigami.dev <--- more info there
Been using tmux session to hand over to claude for a while. Paranoid me uses the macbooks secure enclave with fingerprint for the ssh key so claude can't ssh into my remote boxes by himself. I then open named tmux sessions, perform the ssh login via fingerprint, and then tell claude that he is free to take over that session with a given name.
That’s the same reason I started using the Secure Enclave SSH access for HomeAssistant: I wanted to grant agentic access, but I also didn’t want my house’s automations being blown up. Everything is written offline as IaC, and gets pushed with explicit approval only.
Same reason I migrated my keys to ed25519-sk and began using touch and PIN hardware security dongles to approve auth.
[flagged]
[flagged]
[dead]
If you're using tmux with either worktrees or agents, I strongly recommend you check out workmux. It makes for such a clean setup.
https://github.com/raine/workmux
I've been using shpool these days (especially for things like Claude / Codex / etc). Shpool only does persistence, not multiplexing. It turns out this is exactly what I want. I want to have one keyboard shortcut, to detach the session, and that's it.
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 want to like shpool but it struggles with reattaching and redrawing or resizing
Interesting. I’ve been using it heavily on macOS (ssh to Linux host) and over the web using xterm.js, and it’s been working about as reliably as tmux did. Sometimes it doesn’t resize properly, but that’s also true of tmux (when I see a big field of .).
If you are interested in this setup I would recommend https://github.com/asheshgoplani/agent-deck.
So many commands. I just started claude in a new tmux session with iterm. Told it it's running in tmux with iterm and it should spawn subagents into separate tabs. When I wanted to know the status of the fleet I just asked the primary agent.
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.
herdr (supercharged tmux) has also mouse keybindings. So instead of remembering how to split a pane, you just right click with the mouse and choose "split" from the popup menu
I created my own “terminal multiplexer for AI agents” after trying out herdr.
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
Interesting, thanks for sharing! Is it not open-source? I could not find a github link.
I didn’t release the source yet but plan on doing so.
The documentation does mention building from source, maybe edit it or add a note to avoid confusion?
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.
You’re absolutely right. I merely wanted to share my own story / tool and listed the link to be complete.
I mean you still went through the trouble (unless you don't check the AI's output at all) to design this entire prebuilt release process, and then encourage people to blindly run it. Regardless of what you want to achieve with this post here, you should expect this kind of pushback if you promote unsafe practices like that.
Well I am using this release process myself (and a couple of friends), along with the auto update feature. So it is still self centered.
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.
Bit of a conflict with jai.scs.stanford.edu/.
Looks interesting but I’m confused if you published your source code or not.
> 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.
Thanks for your feedback, I’ll fix that copy. I didn’t release the source yet but I plan on doing do.
I built all of this tooling many months ago. See https://github.com/NavistAu/claude-tmux-bridge and https://github.com/NavistAu/claude-tmux-director
I've been doing this for a while with jaiver (made by me). Just expanded it recently to work with another tool that allows access via Telegram, because I've been on a crusade to make everything on my desktop mobile-accessible.
- https://gitlab.com/skeledrew/jaiver
Similar others I have had a lot of success just hand rolling a terminal multiplexer that fit my workflow — somewhat similar to herdr but works a little bit how I had my set up working with git worktrees and agents. Terminal native, and optimised for speed.
https://domux.dev
what are the differences between domux and herdr ?
I honestly haven't used herdr off a lot myself, but the main thing that jumped out was organising projects. With domux projects can have workspaces which are git worktrees that domux manages, and you can run agents inside them. That helps me see at a glace what workspaces I have in flight, and the work each agent is doing inside them. The navigation is different as well — with cmd+k like experience to rapidly switch between agents.
I created my own harness tcode (https://github.com/wb14123/tcode) to leverage tmux and neovim. Have been using it all the time since the beginning of this year.
How are folks on windows using tmux or tmux-like tools? Tmux inside git bash is really slow. Any other tools? I know I can use WSL but due to some deployment constraints I can’t use it.
Honestly WSL sucks. Even msys2. My current client forces me to use windows to access their data, and I really, really tried to make it a dev machine, it just MS made it such a shit experience. I had scoop, I had msys2, I had WSL2, etc ... My mere setup (nvim, tmux, or even herdr, etc ...) all run very slow. nvim is barely usable. Where is on my nearly 10 yo voidlinux notebook of 4GB, it runs amazing. Something about MS bloatware will never disappoint.
It's great to manage subagents using the Claude team mode and tmux integration.
I use AI Agents inside tmux since last year, the main motivation at that time was to avoid lost the session if I close the terminal by accident - now all of them have --resume
tmux is great, specially when you need persistence in a remote server where you don't want or can't install any other software, and when you are stuck with some 2010 terminal emulator.
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).
Wow, nearly every top level comment is about coding their own version of this.
I'd love some perspective on what problem this setup solves and how do you address sandboxing.
Like everyone else here I have mine as well. My motivation was: - A way to 'resume' my whole workflow after restart or shutdown - Visual way to verify which sessions are running still, which need my assistance, and which are actually done - Something lightweight I could bake into an orchestration layer
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.
[flagged]
I went down this path over 6 months ago and had a variety of custom setups using tmux, cmux, and more. But since using Orca IDE it feels like a leap in usability and robustness.
I found orca way to cluttered and overkill. Cmux feels very lightweight.
I love CMUX and some people I know who were building their own tmux setups bailed and just started using CMUX -- The built in browser and associated bash tools are awesome but really just having workspaces with colors and todos that survive a refresh makes it worth it if you run a bunch of agents at one time
I'm a Zellij man myself, but terminal multiplexers are THE number one best QOL improvement for terminal based work.
Personally I switched to zellij and haven't looked back. Though any of them is worth it over nothing.
Isn't this the wrong architecture? Fundamentally, a coding agent should be running as a headless/detached process, a daemon. If it needs a CLI then that CLI can attach/connect to that daemon and interact with it. If you architect it that way then you can quit and resume the CLI anytime you want, from any machine you want and with whatever UI you want, the daemon doesn't care. Running the agent as an interactive CLI process which you need to stuff into something like tmux is just the wrong approach, and "connecting" to it by reading/scraping its screen is terrible.
Or, wrong by design. There is something about nudging users to use the claude CLI from which Anthropic extracts value. Otherwise they would not charge extra for "claude -p" or ACP access.
The tmux send-keys + terminal scrape is the LLM version of the analog hole of DRM'ed audio.
Wait, is `claude -p` usage counted differently? I've built something of a multi-agent daemon system and use `-p` extensively. Now I'm wondering if I'm burning my credits faster.
If you are paying for the API anyways, I don't think it makes a difference. What is different is if you are on a subscription then you need to pay more to use `claude -p`. But then Anthropic started adding free credits, at least for Team and above plans, to offset the cost. Drug dealer pricing.
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.
Oof same. I basically built something GP described: a daemon that kicks off a one-shot session, working on git-bug tasks
tmux kind of is that daemon. The agent keeps running on the box and I attach from my laptop or phone. What I was missing was everything around it, like paste and files.
Opencode works that way-ish.
[flagged]
tmux is also a great primitive to build on top of.
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).
I've made a terminal that is essentially ghostty + herder, but all natively and has a session persistence. https://thurm.rs
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.
I just hard forked paseo and used its websockets/relay system w/e2ee along with some additional credentialling.
Seems like we all get tailored suits now.
hehe, I also have done the same, but I'm building on top of tmux. Though much more minimal in scope. https://kido.tools (website showcases the TUI only but there's native macOS app in the PR which I'm using but still refining).
We should compare notes!
Nice! Feel free to check Thurm codebase on Github https://github.com/nklmilojevic/thurm
p.s. it has a daemon and automatically installs claude/codex/pi skills so the agent knows how to control and script the panes, tabs and everything else. It is also heavily inspired by Rex's design.
I've been using ghosty + ssh + mosh + tmux + claude code (sometimes codex) for a while now. It works well but the few things that still piss me off:
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
> I have never been able to get copy-paste to work 100% of the time
Have you tried Kitty? Its remote clipboard integration works over SSH, including images. Might be worth a look.
No, I'll check it out!
Might be worth checking out https://mpx.capocasa.dev/
I guess it's not totally clear to me that would solve all of my problems. But, I'll look into it more when I have time.
I don't use tmux. I run Claude Code in Cursor windows, and each window title shows the folder name, so that's how I tell them apart. It rarely gets confusing, and an app I built for myself made it a lot easier.
How many simultaneous cursor windows are you running? Have you hit RAM limits at some point?
does this approach allow you to interact with the sessions(resume existing or create new) through claude apps?(desktop/mobile/web)?
tmux and pi is already my preferred way to use LLMs, but the config in the article is sweet. I was wondering why the colors were off...
One overlooked thing about tmux is it is designed for the world of 80x24 terminals so it works really well on mobile terminals like terminus while web interfaces have to be redone for smaller screens and don't quite have all the features of the full web apps.
`claude agents` runs a daemon that survives SSH reconnects. You don’t really need tmux anymore
Now we are in the state where we have a thousand multiplexers
Sigh, painful AI slop that is wrong on so many things and just an ad for crystl.
[flagged]
[flagged]
[flagged]
[flagged]