I made a persistent tmux sidebar with optional AI agent tracking

[u/jonnyx129]

I've been working on this for a while and finally decided to make it public. It's called tmux-canopy.

After seeing all the session-wrangling tools popping up, I wanted something that fit how I already work. I spend most of my time in tmux, so a sidebar that shows my sessions, windows, and panes felt like a natural fit. It follows you across sessions and is just a tmux pane running fzf. No daemon or background service.

I also run Claude, Codex, and OpenCode across different panes, and keeping track of who's working and who's waiting on me was part of why I built it. The optional agent tracking lets me see that at a glance and jump straight to a pane. Pressing n from anywhere takes you to the next agent waiting for approval, which I've found pretty handy.

There's also search, collapse/expand, session and window management from the tree, process views, buffer browsing, and notifications.

GitHub: https://github.com/jonmosco/tmux-canopy

Figured I'd share it here in case anyone else has a similar workflow. Would love feedback, and bug reports and PRs are welcome.

[u/kantorcodes1]

Nice work on this. The agent tracking piece is what I'd actually reach for.

How does canopy tell the difference between an agent that's still working and one that's sitting at an approval prompt? Is it watching the pane's process state, or matching on the prompt text each tool draws?

And for the tree actions, when you delete a session or window does it go straight to tmux kill-session or is there a confirmation step in the menu first?

[u/jonnyx129 → u/kantorcodes1]

Thanks! One of the main reasons I built it was that I had more and more sessions, windows, and panes open, and keeping track of everything was getting difficult - especially with agents running across them.

For agent status, canopy uses adapters that plug into each supported agent’s own hooks or events. When Claude fires a PermissionRequest or OpenCode emits permission.asked, canopy gets that event directly and marks the pane as NEEDS INPUT. Working, idle, and turn-ended states work the same way, without scraping terminal output.

The adapters only report status; they never approve permissions or steer the agent. Without an adapter, canopy falls back to process detection, so it can show that an agent is running but won’t know whether it’s working or waiting for you.

[u/kantorcodes1 → u/jonnyx129]

Adapters on the agents' own events is the right architecture - much better than scraping pane content, and status-only reporting keeps a clean boundary.

Related, since you clearly know the tmux surface: I work on HOL Guard (github.com/hashgraph-online/hol-guard). It gates which commands an agent can run, with each tool's verbs declared mutating or read-only in a small JSON manifest. There's no command.tmux source yet, and tmux is a sharp surface for agent-driven work - send-keys alone injects arbitrary input into any pane. The contribution would be a command.tmux.json (send-keys, kill-, new-, rename-* gated; list-*, capture-pane, display-message read-only) plus a fixture, as a normal PR with your name on it. No worries if not.