The Agent List I Didn't Know I Had

I sat down at my desk this morning and realized I had no idea how many Claude Code sessions I had open. Two for sure. A third from last night that I thought I’d closed. And at least one more running in a herdr workspace I hadn’t looked at since Wednesday.

This is a new category of mess. Nobody warns you about it when you start running agents. For the first few weeks it feels like a superpower: you spawn a session for a task, it does the task, you move on. Then one day you look up and your terminal is a parking lot of half-finished conversations, each one holding a few hundred kilobytes of context that cost you real money to build, and you can’t tell at a glance which ones are safe to close.

The problem isn’t the agents. The problem is that there’s no ps aux for them.

The command I keep forgetting exists

I use herdr as my terminal multiplexer — tmux’s successor, specifically built for AI coding agents. It knows what a “Claude session” is in a way tmux doesn’t. And buried in the CLI, there is exactly the command I needed:

herdr agent list

It returns JSON. One object per Claude session, across every workspace and tab you have open, on every machine registered with your herdr server. Here’s a trimmed sample from this morning:

{
  "agents": [
    {
      "agent": "claude",
      "agent_status": "done",
      "cwd": "/home/brettr/Documents/FreeboDecember",
      "focused": false,
      "pane_id": "w6:p1",
      "terminal_title_stripped": "Project UI iOS app",
      "completion_seq": 127
    },
    {
      "agent": "claude",
      "agent_status": "idle",
      "cwd": "/home/brettr/Documents/FreeboDecember",
      "focused": true,
      "pane_id": "w7:p2",
      "terminal_title_stripped": "Herdr sessions and Freebo clutter",
      "completion_seq": 113
    }
  ]
}

Every field here is doing work.

agent_status: "done" means the model finished its last turn and is sitting at a prompt waiting for me. idle is similar but subtler — the pane has an active Claude process but no pending request. Neither of them is actively burning tokens. Both of them look identical from the outside. The one you want to kill is the one with the stalest conversation and the lowest completion_seq — the counter that ticks every time the agent finishes a response. A session with completion_seq: 2 has barely done anything. A session with completion_seq: 127 is a long thread with a lot of accumulated context, and reopening it is cheaper than starting over.

focused: true tells you where your cursor currently is. If you only see one focused: true, that’s the pane you were in. The others are the ones that snuck up on you.

cwd is the giveaway for sprawl. If three agents all report /home/brettr/Documents/FreeboDecember, they’re all in the same repo, probably stepping on each other’s working copy, and definitely stepping on your attention.

The pattern I kept seeing

I did this audit cold this morning and the shape surprised me. Not one of the agents was mid-request. All of them were parked at a prompt. All of them were waiting for me. Which means the sprawl isn’t a performance problem — nothing is pegged, nothing is running up a bill. It’s an attention problem. Every parked session is a tiny promise my future self has made to come back and finish something. And future me is very bad at honoring those promises.

What I close and what I keep

My rule, after this morning: a session is worth keeping only if the context inside it is more expensive to rebuild than it is to carry.

That cashes out as two concrete tests:

1. Is there a real thread I can resume from a one-sentence prompt? If yes, close the agent. The context isn’t load-bearing — I can rebuild it on demand.
2. Did the session accumulate something I’d lose? A long debugging dialog where the model has already ruled out five hypotheses. A multi-file refactor where it’s held the plan in its head for two hours. A conversation about a design decision I haven’t written down yet. Those stay.

Everything else gets herdr pane close-d without ceremony. I lose nothing. I get back a tab and a sliver of brain.

The small thing I added to my shell

Because I will forget this command exists again by next Thursday, I added a one-liner to my zsh config:

alias agents='herdr agent list | jq -r ".result.agents[] | \
  \"\(.agent_status | .[0:4])  \(.pane_id)  \(.terminal_title_stripped)\""'

Now agents at any prompt gives me a four-line table. No JSON, no scrolling, no decision fatigue. If I have more than three rows, I close something before I start the next thing.

The takeaway that’s bothering me

Nobody has really figured out how to live with multi-agent workflows yet. The tooling assumes you’re either running one agent at a time (fine, boring, no sprawl) or orchestrating many agents inside a single script (fine, bounded, the script handles cleanup). The in-between case — a human running three or four interactive agents concurrently across different problems — is where the mess happens, and it’s exactly where most heavy users are heading.

The fix isn’t more agents. It’s a tiny bit of ambient visibility: a one-line answer to “what did I leave running?” that I can get without context-switching. herdr agent list is the closest thing I’ve found to that, and I’m now treating it the way I treat git status — a reflex before I start anything new.

If you’re running two or more Claude Code sessions a day and you haven’t audited them this week, run the command. You will find at least one agent you forgot about. I’m genuinely curious what the record is.