herdr vs cmux, after two months on each

I left cmux for herdr at the start of June because its remote support did not fit how I work. Maybe I should have waited a little longer! cmux shipped a daemon that keeps SSH terminals alive across reconnects on 1 June, then added SSH agent forwarding on 4 June.

I stayed on herdr anyway. I’ve now spent about two months with each, moving between Linux boxes and my Mac while running several coding agents at once.

| licence | AGPL-3.0 | GPL-3.0 |

## Where the agents live [#](#where-the-agents-live)

cmux is a native macOS app with terminal panes. You install it on the Mac in front of you and connect to other machines from there. herdr runs on the machine doing the work, and you attach a terminal client to it. They can look similar locally. Over SSH (Secure Shell), that difference matters.

herdr is stable on Linux and macOS, which covers the two systems I switch between. Windows support is a preview beta, and the docs warn that it may be reduced or removed. I already use Windows Subsystem for Linux (WSL) for development on my gaming PC, so that’s how I run it there.

Both support the agent CLIs I use, and new ones tend to arrive within weeks. cmux added hooks for OMP, the Oh My Pi coding agent, in June. The support list is not a reason to pick one.

The tools differ more in how they detect agent state. herdr checks the foreground process, then uses lifecycle hooks when an agent provides them. Without a full hook, it falls back to a screen manifest that checks the last few terminal lines for known prompts. That still gives it a rough state for agents without a direct integration. Claude Code takes that path because its hooks do not report every state change, so herdr can take a few seconds to recognise a blocked prompt. I mostly run Claude Code with Fable or Opus at the moment, but sometimes use pi with GLM 5.2, which has direct lifecycle hooks. The agent I use most is slower to update in the sidebar.

With herdr, the panes and agents stay on the remote box. herdr --remote workbox

attaches the local client over SSH. cmux now keeps its remote terminal alive through a detachable daemon and forwards the local SSH agent, so reconnects and Git access work there too. The difference is smaller now, but I still want the multiplexer on the same machine as the agents.

## Plugins [#](#plugins)

The [herdr plugin marketplace](https://herdr.dev/plugins/) indexes public GitHub repositories tagged `herdr-plugin`

. A working plugin also needs a herdr-plugin.toml

manifest, and herdr plugin install owner/repo

installs it straight from GitHub. There is no submission queue. cmux’s extension API, CmuxExtensionKit, is still in preview. Custom sidebars use a Swift interpreter behind the Beta Features flag.

I run two herdr plugins. reviewr puts the code review loop I use beside the agent. I select a line range and write a comment, then keep going through the diff. “Add all to chat” writes each note into the active agent’s input as path:start-end - comment

. It never edits the worktree or sends a comment on its own. Its last turn

scope limits the diff to changes made since the agent’s most recent turn began. Neither base tool has that view.

herdr-browser handles local previews. When a dev server prints http://localhost:5173 , I Control-click the link and the plugin opens Chromium in a right split. A normal click still goes to the terminal, and a non-local URL opens in my desktop browser.

That browser does not work with the remote setup I prefer. Its README says the image stream sends too much data per frame over SSH. reviewr only draws text in the terminal, so it works over --remote

. herdr-browser needs Kitty’s image protocol, which the remote connection does not carry. When I am attached to another box, I use Playwright screenshots to check Flutter and React changes instead.

I already had Playwright Model Context Protocol (MCP) configured, so the agent had two ways to open a browser and tried the wrong one in the screenshot above. The fix is in the herdr-browser README: connect Playwright MCP to the plugin’s Chrome DevTools Protocol (CDP) endpoint with --cdp-endpoint

. That way, Playwright controls the browser beside the agent instead of opening another one.

What cmux does better # #

cmux has the better browser. herdr-browser keeps a Chromium profile for each herdr session, so cookies and logins survive pane and daemon restarts. It cannot reuse the Chrome profile I already use. cmux can import browser data and sessions from more than 20 browsers, so its browser panes open already signed in. The native WebKit view also looks much better.

I took these on separate runs and different ports, 8099 and 5173. They show the same login page, but not the same run.

cmux’s remote support is good now too. I went back and checked the changelog: the detachable daemon keeps terminals alive across reconnects, and SSH agent forwarding lets remote sessions use local keys without copying them to the box. My original reason for leaving no longer applies.

Neither project is finished software. herdr is still pre-1.0. The cmux changelog includes a June memory leak that grew the app to 4.4 GB over about 23 hours. An earlier Git search bug pushed memory from about 450 MB past 8 GB and triggered the out-of-memory killer.

Why I picked herdr # #

cmux has the better browser, and it fixed the SSH problem that made me leave. I still use herdr because reviewr is now part of how I work. The multiplexer also runs on the same box as the agents, so I get clickable panes and agent state in the sidebar without moving those sessions into a macOS app.

If you work locally on a Mac, pick cmux. If your agents run on boxes you attach to, pick herdr. I work the second way, so herdr is the one I kept.

Why not just use tmux? #

tmux already keeps sessions alive. I use herdr because it marks which panes contain agents and which one is blocked, then lets me jump there from the sidebar. Its plugins also use that agent state. If you run one agent and do not need the status, tmux is enough.

Can I run cmux on Linux or Windows? #

No. cmux is a native macOS app built with Swift and AppKit. It can connect from a Mac to Linux or Windows machines over SSH, but the app runs on macOS.

Will my tmux shortcuts work in herdr and cmux? #

Not automatically. herdr uses Ctrl-b as its default prefix, and some bindings will feel familiar, but its keymap is not tmux’s. cmux defaults to macOS Command shortcuts, though

it supports two-step chordsso you can recreate the bindings you use. Neither imports your .tmux.conf

. If you run tmux inside either tool, give one layer a different prefix so they do not both consume Ctrl-b

.## I'm on a Mac and work locally. Which should I pick?

Pick cmux. It runs natively on macOS, and its browser panes can import your existing sessions. Pick herdr if you want the multiplexer to remain inside the terminal.