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.
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.
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.
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 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.
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.
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.
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.
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.
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
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.
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.
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).
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.
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).
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.
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.
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’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 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 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.
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.
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.
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 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.
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.
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.
>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.
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.
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 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.
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?
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?
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
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.
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 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.
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 .).
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
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
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.
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).
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.
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.
thomas_witt | 14 hours ago
oefrha | 14 hours ago
As a result I still run sessions and processes I really don’t want to lose inside tmux, nested inside herdr. Tmux never crashes.
kkapelon | 7 hours ago
aranelsurion | 14 hours ago
breckenedge | 9 hours ago
yoyohello13 | 7 hours ago
littlecranky67 | 13 hours ago
sgarland | 9 hours ago
leizzo | 13 hours ago
MiliasGeiger | 13 hours ago
paweladamczuk | 13 hours ago
toppa33 | 13 hours ago
f311a | 12 hours ago
The text content occupies like 20% of the screen, the rest is empty. Resizing the window helps.
embedding-shape | 11 hours ago
acidburnNSA | 11 hours ago
ulimn | 10 hours ago
jasonlotito | 9 hours ago
f311a | 9 hours ago
mgr86 | 8 hours ago
pavel_lishin | 7 hours ago
Making it wider than about a thousand pixels shrinks the text column down to 400 pixels.
A weird design choice.
petesergeant | 12 hours ago
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
Reebz | 12 hours ago
whyho | 10 hours ago
pwillia7 | 9 hours ago
nklmilojevic | 12 hours ago
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.
nklmilojevic | 12 hours ago
andreypopp | 11 hours ago
We should compare notes!
nklmilojevic | 11 hours ago
cyanydeez | 11 hours ago
Seems like we all get tailored suits now.
teiferer | 11 hours ago
frumiousirc | 11 hours ago
The tmux send-keys + terminal scrape is the LLM version of the analog hole of DRM'ed audio.
hundchenkatze | 9 hours ago
_def | 9 hours ago
jpitz | 6 hours ago
frangonf | 11 hours ago
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).
tjoff | 11 hours ago
igor_nast | 11 hours ago
A nice alternative for ppl who struggle with terminal based solutions. It's a free indie product. https://shikigami.dev <--- more info there
michaelanckaert | 11 hours ago
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
cyanpencil | 10 hours ago
michaelanckaert | 10 hours ago
calops | 10 hours ago
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.
michaelanckaert | 10 hours ago
calops | 9 hours ago
michaelanckaert | 9 hours ago
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.
alchemist1e9 | 10 hours ago
> 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.
michaelanckaert | 10 hours ago
skeledrew | 2 hours ago
zackham | 10 hours ago
https://github.com/zackham/seance
blfr | 10 hours ago
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.
cromka | 10 hours ago
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.
LelouBil | 10 hours ago
axus | 7 hours ago
chasd00 | 9 hours ago
bntyhntr | 8 hours ago
piro0919 | 9 hours ago
breckenedge | 9 hours ago
jhogendorn | 9 hours ago
skeledrew | 8 hours ago
- https://gitlab.com/skeledrew/jaiver
pranav7 | 8 hours ago
https://domux.dev
kkapelon | 7 hours ago
nsagent | 8 hours ago
I'd love some perspective on what problem this setup solves and how do you address sandboxing.
rosod | 2 hours ago
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.
nedt | 8 hours ago
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.
kkapelon | 7 hours ago
Scea91 | 8 hours ago
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.
vardalab | 4 hours ago
wb14123 | 7 hours ago
hatradiowigwam | 7 hours ago
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.
kkapelon | 7 hours ago
Or just jump straight into herdr which offers a superset of what tmux offers.
wing-_-nuts | 7 hours ago
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.
klodolph | 6 hours ago
nater5000 | 6 hours ago
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.
simlevesque | 6 hours ago
benfrancom | an hour ago
kccqzy | 5 hours ago
bilalq | 5 hours ago
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.
kccqzy | 3 hours ago
artemave | 2 hours ago
So claude and I grew the replacement over the course of a few months. Really happy with it. Never looked back.
kccqzy | 2 hours ago
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/
hungryhobbit | 5 hours ago
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?
selectodude | 4 hours ago
nagaiaida | 41 minutes ago
absoluteunit1 | 5 hours ago
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
cosmojg | 2 hours ago
[1] https://zellij.dev/
olivewong | 29 minutes ago
I have tried to learn tmux, but the key bindings are really unintuitive to me vs my familiar vim setup
qudat | 7 hours ago
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.
jdormit | 7 hours ago
kkapelon | 7 hours ago
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)
alex7o | 7 hours ago
klodolph | 7 hours ago
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.
seniorsassycat | 6 hours ago
klodolph | 6 hours ago
yoyohello13 | 7 hours ago
symlinkk | 6 hours ago
mococa | 6 hours ago
0xpiguy | 5 hours ago
solumos | 5 hours ago
vantassell | 4 hours ago
mkw5053 | 4 hours ago
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
k__ | 4 hours ago
mkw5053 | 4 hours ago
artemave | 2 hours ago
Have you tried Kitty? Its remote clipboard integration works over SSH, including images. Might be worth a look.
jdonaldson | 4 hours ago
https://github.com/jdonaldson/headless-horseman
Ey7NFZ3P0nzAe | 4 hours ago
Aperocky | 4 hours ago
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).
vantassell | 4 hours ago
https://github.com/raine/workmux
benfrancom | 2 hours ago
febed | 7 minutes ago