hrdx: I Built My Own Agent Multiplexer, Because of Course I Did

I built hrdx, an experimental, minimal terminal multiplexer for coding agents. Your projects live as workspaces in a sidebar, each workspace has tabs, and every pane is a real terminal running Codex CLI, Claude Code, zot, pi, or whatever agent CLI you throw at it. Kick off an agent in one project, switch to the next, and let the sidebar spinners tell you who is still working.

If that sounds familiar: yes. Tools like this exist. Good ones.

The honest origin story

I spent a few weeks using herdr after a friend of mine recommended it, and I genuinely liked it. It is a well made tool, the agent-aware sidebar clicked with me immediately, and running a whole herd of agents from one terminal turned out to be one of those workflow upgrades you do not want to give back.

But anyone who has read this blog before knows what happens next. I used a tool I liked, and somewhere around week two a familiar itch showed up: I want my own version of this.

It is the same itch that produced zot. I like Go. I like small binaries. I like knowing every corner of the tools I live in all day. And there is something about a terminal multiplexer, sessions, PTYs, escape sequences, state that has to survive a detach, that makes it an almost irresistible thing to build yourself. So I stopped resisting and built it.

No mission statement, sorry

Let me set expectations properly, because this part matters to me.

hrdx is an experiment. There is no grand thesis here, no "rethinking the terminal for the agent era" pitch deck. I built it because building it sounded like fun, and because I wanted a multiplexer that works exactly the way my brain does.

If somebody else uses it: great. If somebody wants to contribute: even better, genuinely, come say hi. If somebody hates it and writes a spicy comment about how tmux plus a shell script does all of this already: also fine. They are not even wrong. That is the beauty of building for yourself first, every possible outcome is a good outcome.

The one feature I refused to compromise on

There was exactly one thing I knew hrdx had to have from day one: custom harnesses via JSON.

Agent CLIs come and go at a frightening pace right now. A multiplexer that hardcodes its list of supported agents is signing up for an eternal game of catch-up, and every wrapper or nix-shim in between breaks the detection anyway. I did not want to release a new version every time someone ships a new agent.

So in hrdx, an agent harness is just a small JSON file. You describe the command, and you describe how to tell whether the agent is busy, and that is it. Your custom harness shows up in the sidebar, gets a spinner, appears in the agents list, and behaves exactly like the built-in ones. When the next hot agent CLI drops, adding it is a five minute job that requires zero code and zero waiting for upstream.

That extensibility point is, to me, the actual core of the tool. Everything else is a sidebar around it.

What else is in the box

A quick tour, because a few of these decisions fell out of daily use rather than planning:

• Real terminals, not wrappers. Every pane is a genuine PTY with a full terminal emulator behind it. Agent TUIs run exactly as they do standalone.
• Everything in view. Workspaces with git branch and ahead/behind counts, live status dots per pane, and an agents list that jumps you straight to any running agent.
• Picks up where you left off. Quit and relaunch: shells and agents keep running in a lightweight session holder and reattach exactly where they were.
• Scriptable from outside. A JSON socket API lets scripts inspect workspaces, spawn panes, type into agents, wait for them to finish, and read their screens. An agent driving the multiplexer that runs agents is exactly as fun as it sounds.

It is MIT licensed, written in Go, and runs on macOS and Linux:

curl -fsSL https://www.hrdx.dev/install.sh | bash

Where the journey goes

I honestly do not know, and I mean that in the best way. hrdx exists because I wanted it to exist. It already earned its keep as a learning project, and it is now the thing my agents live in every day, which is more than most experiments can say.

Maybe it stays a personal tool with a handful of users. Maybe it grows into something more. Either way I get to keep hacking on a Go codebase I enjoy, and you get another data point in the great "everyone builds their own agent tooling" experiment of 2026.

If you try it, tell me what breaks. If you build a custom harness for an agent I have never heard of, definitely tell me. That is the whole point.