Comment by natsucks

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