Herdr, seven months in

On Tuesday morning the workspace for this site came back from a restart with every Claude pane signed in to the wrong account. The panes were there, the tabs had the right names, and each agent had been resumed, but they’d been resumed as my work Claude, which had never heard of the conversations they were supposed to be continuing. It took me about twenty minutes to work out why, and the answer turned out to say a lot about how Herdr is built, so I’ll start there and work outward.

It’s been almost seven months since I wrote about a team of agents in my terminal, after a week with Herdr. I’m still using it every day. I’m on 0.9.5, installed from Homebrew, and the way I use it has settled enough that it’s worth writing down, along with the thing they shipped this month that I haven’t installed yet and have been reading about all week.

The wrong account

I have two Claude Code accounts, one for work and one personal, and Claude Code picks which one it’s using from a config directory, set by the CLAUDE_CONFIG_DIR environment variable. My personal sessions start from a shell alias that sets it. In April I said I kept work and personal in separate Herdr workspaces, and for months that was fine, because the alias set the variable in the pane and the agent in the pane used it.

The catch is in how Herdr brings agents back. Since 0.6.3 in May it persists sessions across server restarts and updates, and, once you turn it on, when it restores a Claude pane it runs a plain claude --resume with the conversation’s ID. It runs that with the environment of the Herdr server, not the environment the pane had when I started it. My server had been started from an ordinary shell, so the restored agents got the default config directory, which is the work one, and the work account had no transcript with that ID.

The fix I found came from a post by Giorgi Dalakishvili, Running Multiple Claude Code Accounts with herdr, which describes exactly this and went up about two weeks before it happened to me. One Herdr session per account. The personal one starts with herdr --session personal, from an alias that sets CLAUDE_CONFIG_DIR first, so the server has the variable, every pane inherits it, plain claude in that session is the personal account, and restores come back where they should. The one thing to remember is that the variable only counts when the session’s server starts. If the personal session is already running without it, re-attaching changes nothing, and you have to stop the session and start it again with the alias.

So the separation I described in April moved down a level, from workspaces inside one Herdr to two Herdrs. I don’t mind. It’s a cleaner line anyway, and nothing from one account can end up in the other’s sidebar.

How a workspace looks now

Inside the personal session it’s one workspace per repo, and inside each workspace the tabs are named for what’s in them. For the repo behind this site that’s agent-site, where the agent writing code runs, agent-reviewer, and nvim. lazygit lives in a pane too, which is where I actually read diffs, with delta rendering them (the setup is in the post about the rest of my workflow), and that matters more than it sounds when most of what I do all day is read diffs. Neovim is for reading files whole and for the edits I still make myself, which are mostly to Markdown.

In April the writer and reviewer were two panes in one tab. They’re separate tabs now, because when both were visible I kept reading whichever one was moving, and I’d rather look at one thing at a time and let the sidebar tell me when the other one wants me.

The handoff is the part that changed most since April. Back then I tried letting the writer run herdr wait on the reviewer and read its output, and turned it off within the week because it automated the one step I wanted to stand in. What I do now is in between. When I tell the writer a change is ready for review, it sends the reviewer the request itself with herdr agent prompt agent-reviewer "…" --wait, which types the prompt into the reviewer’s pane and waits until the reviewer has finished. The findings come back as a numbered list, and the writer’s instructions say to show me the list and do nothing else. I reply with the numbers I agree with, and it applies those.

That’s saved me a lot of copy and paste without moving the gate. The writer can start a review, but it can’t act on one. I’ve used exactly this setup for the last few weeks of real work, and it held up better than I expected over dozens of rounds.

What changed in Herdr

A lot, for a tool that wasn’t two weeks old when I first wrote about it. The Herdr blog has the full list, but the releases that mattered to me were these:

• 0.6.3 (27 May), with session persistence across restarts and live updates that replace the server while keeping pane processes alive. Since it updates itself, this is the one I’d have asked for first.
• “Ten agents, three clients, 95% less CPU” (3 August), which mostly came from not animating and repainting things nobody was looking at.
• 0.9, “Connecting the machines” (7 September), which brought local and remote machines into one TUI client.

The company side moved just as fast. They joined Y Combinator in August and announced a $6M seed led by Bessemer Venture Partners in September. In April my one reservation was that a project this young sat between me and every agent I ran and pulled down its own updates. Funding doesn’t answer that, exactly, and in some ways it adds a question, since funded companies have to make money from something. They did say in the YC announcement that the runtime is Apache 2.0 and stays open, and so far it has.

The app

This month they shipped something new, a native desktop app for macOS on Apple silicon, Linux and Windows, which is a separate program from the Herdr I use. It’s built on herdr-core, a small server with a CLI called hc, and the agents live in the core, not in the window. Closing or updating the window doesn’t stop them. The site is clear that the app and Herdr TUI don’t share agents, so anything I start in the TUI won’t show up in the app, and the TUI is staying.

I haven’t installed it. Everything below is from reading the site and the README, and some of it I’ll probably have wrong.

Three things in it caught my attention. The first is that the whole app is plain files under ~/.config/herdr-app, with layouts in JSON and “mods” in JavaScript, and an AGENTS.md in that folder telling an agent what it’s allowed to change. The pitch is that you customize the app by asking your agent to. That’s the same move I made with Neovim, except here the instructions to the agent ship with the app. The README is honest that mods are trusted code, not sandboxed extensions.

The second is status. The TUI works out what an agent is doing either from the screen or, for Claude Code, from hooks. The app instead uses OSC 7501, which they’re calling the Program Status Protocol, an escape sequence any program can print to say it’s working, done or blocked. Their example is one line of shell:

printf '\e]7501;state=blocked:app=my-agent\e\\'

So my little notification script from April could be an “agent” as far as the sidebar is concerned. If other tools pick that protocol up, I suspect it’ll outlast the app, because it’s the kind of small open thing that ends up everywhere.

The third, and the one I’ve thought about most, is that agents can run other agents and hear back. The example on the site is a Claude session starting a Codex helper with hc run --bg codex "review my diff. Done: hc send t1", steering it with hc send t3 "take another look", and getting its report, its exit or its “needs you” delivered into the parent’s input as a message tagged <hc from="t3 reviewer">. Remote machines join the same sidebar with hc machine add, and their agents keep going while the laptop sleeps.

One difference from the TUI is directly relevant to my Tuesday. The app’s FAQ says that if the machine reboots or herdr-core stops, the panes come back with a shell in the same folder, but it doesn’t restart the agent or resume its work. That’s less convenient, and it also means the restore that put my panes on the wrong account couldn’t happen there, as far as I can tell.

Different models checking each other

The obvious thing to try with hc run is a reviewer from a different provider. My writer and reviewer are both Claude, and I’ve had a nagging feeling for a while that they share blind spots. When the reviewer misses something, it’s often the kind of thing the writer also got wrong, a plausible-sounding default or a confident claim about an API, which makes sense if they were trained on much the same idea of what plausible looks like. A Codex reviewer, or one of the local models on my laptop as a cheap first pass, would at least be wrong in different places. I don’t have any evidence for that yet beyond the feeling, and I could be wrong about how much the blind spots overlap.

The part I’m wary of is the line on the site that says, about the helper’s reports, “You only hear the result.” That’s precisely the loop I turned off in April. A Claude session that gets Codex’s findings dropped into its input will do what agents do with a list of findings, which is fix all of them, including the ones that are wrong. Two different models agreeing with each other isn’t much better than one agreeing with itself if nobody who knows what the code is for gets a look. And there’s the point I made about agents talking to agents in February: what comes back from another agent is input, not instructions, and the parent should treat a helper’s report the way it’d treat a file it opened.

From the example, though, it looks like the helper is told where to report with hc send and a terminal address, so I think the report could go to a terminal I’m watching, not to the writer. If that works, the shape I want is two reviewers from two providers, each producing a numbered list, and me picking from both. I’d expect them to overlap on the obvious things and to differ on the interesting ones, and the differences are the part I’d read first.

What I’m going to try

The app goes on my personal Mac first, alongside the TUI, with one repo in it. I’ll give it a Claude writer and a Codex reviewer, try to get the reviewer’s report delivered to a terminal of mine rather than the writer’s input, and see whether the two of them catch different things over a couple of weeks of real work. I’ll keep the TUI as it is in the meantime, since that’s the setup I trust, and the two don’t share agents, so there’s nothing to migrate until I decide there should be.