Comment by dgunay

9 hours ago

Over the last year I ended up duct taping a lot of functionality onto tmux to get what these new age multiplexers set out to do (session launch, live agent status, etc). And it works, but it definitely feels like duct tape.

I'm not sure the tmux project wants to evolve to support this natively so for now herdr seems like one of the best open and forkable options available. Considering how little I've had to really touch my tmux setup after getting it going I don't think it's necessarily the worst thing in the world if the FOSS community maintains a deshittified fork of herdr, should it come to that.

2 comments

dgunay

natsucks 4 hours ago

I've been wondering what the point of a lot of these new multiplexer projects are when tmux is so extensible. I'd be curious to see eactly what you've done. Care to share a tmux config?

dgunay 43 minutes ago

It's less the tmux config and more the scripting around it.

(shameless plug: I launch agents in tmux directly into docker containers with remuda, a tool I built at work & open sourced [0])

Anyway, I have a vibe coded script that shows me this overview for each of the agents I launch in tmux (hope this doesn't turn out mangled):

  ╭───────┬───────────┬────────────┬─────────────┬───────────────────────────────────────────────╮
  │ AGENT │ PR        │ REPO       │ BRANCH      │ ISSUE                                         │
  ├───────┼───────────┼────────────┼─────────────┼───────────────────────────────────────────────┤
  │ ready │ draft   │ <redacted> │ branch1     │ Fix data race in e2e mock AssertExpectations  │
  │ ready │           │ <redacted> │ branch2     │ Modernize such and such                       │
  │ ready │ open    │ <redacted> │ branch3     │ JIRA-123: some sprint work                    │
  ╰───────┴───────────┴────────────┴─────────────┴─────────────────────────────────────────────-─╯

The agent status column (ready/working/etc) is just using heuristics from the terminal title (since a lot of harnesses have the live status in the title) or tmux capture-pane

The rest of the fields are either the gh cli or from beads, detected from the branch name (using https://github.com/Dicklesworthstone/beads_rust).

My session switcher is cool (shows the session name and the issue title + a preview of the issue details) but ultimately also along those lines; tmux itself doesn't do a whole lot, it's just being extensible and letting me run an fzf pipeline enriched with data from beads.

This works great for me personally but the part that actually pulls data out of the agent sessions is built on heuristics, and I didn't even attempt to get notifications out of it, I just side channel those out using peon-ping[1]

[0]: https://github.com/yendo-eng/remuda [1]: https://github.com/PeonPing/peon-ping