tmux and Hooks

At HubSpot, tools like Conductor are seeing more and more use. These agent orchestrators have skyrocketed my own productivity, but I think they’re fundamentally built incorrectly.

These tools begin and live as harnesses around the coding agent. I don’t want that. I want to use the coding agent directly, and I want to use it in the terminal of my choice (Ghostty, in my case). Honestly, these tools end up feeling like a layer of indirection rather than a useful thing.

They got the primitive wrong

They got the problem right. “Help folks organize their agents” is a real problem, and it gets bigger every month as the number of agents you’re running at once goes from one to three to eight. But they reached for a wrapper as the solution.

In order to have my agents appear as tabs on a screen, they’re asking me to forgo my terminal, work a layer removed from Claude Code, and trust a brand new codebase to be the thing that holds all my in-flight sessions together. That’s a big ask.

I have a better idea. tmux + hooks. Don’t worry about a UI yet. It’s actually the less interesting half.

tmux

Every instance of Claude Code lives in a tmux session, managed by the tool. The tool can remember ids, metadata, whatever it needs to manage the tmux session. That’s its whole job.

But, importantly, because the agent just lives in tmux, you can open, close, and recall the session in whatever terminal you want and away you go. You’re right where you left off.

Want to connect from your phone? It’s just a tmux session. SSH in. Did your computer restart? Just resume the session. Want split panes, or eight agents across two windows? tmux already does that.

tmux is battle tested. Your vibe coded solution isn’t. Just use tmux.

Hooks

And hooks! Claude Code fires hooks at well-defined points in a session, and each hook is just a command that gets a JSON payload on stdin. That’s enough to wire an agent into anything.

Stop hooks can kick off a cheap summarizer that keeps titles and summaries up to date for every running session. That’s the “tabs with names” feature, for about fifteen lines of script. SessionEnd hooks can update a todo list. Notification hooks can ping you wherever you actually are when an agent needs input. Whatever. Hooks can massively power your workflow.

The config is small:

{
"hooks": {
  "Stop": [
    {
      "hooks": [
        { "type": "command", "command": "~/bin/agent-summarize" }
      ]
    }
  ],
  "SessionEnd": [
    {
      "hooks": [
        { "type": "command", "command": "~/bin/agent-close-out" }
      ]
    }
  ]
}
}

Each script reads the session id and transcript path off stdin and does whatever you want with them. Write to SQLite. Post to Slack. Update a status bar. And the session id in that payload is the same one you named the tmux session with, so the two halves line up for free.

Notice how unopinionated this is

I’m not pitching a specific tool that you have to learn or that asks you to compromise. I’m pitching the correct primitives, which let you build your own tool.

Build whatever UI you want on top of them. Add notifications if you want. Have it talk to your other tools via hooks. Or skip all of that and write a six-line script that starts an agent in the current repo.

Spin up a Claude Code session, tell it you want to build an agent orchestration IDE with tmux + hooks, and tell it what features you want.