Hey, yeah I have two rules:

1. I don't want to extend the the harnesses in any way, not even hooks/plugins/etc 2. I don't want to poll, ever. It must be system events, file system watches

So I have to basically watch each session file from every harness for changes and derive a state from that.

Most CLI's have a file per process with some stats like the pid, state, is idle or not, etc, which is really helpful.

Each agent has a small provider that knows how that specific harness works, and watches it for changes. e.g. ~/.claude/sessions/{pid}.json

Those registries are small and change much less than transcript formats do.

But yeah, I think this will always be a matter of keeping it up to date.

I would like to retain support for older harness versions as I go.

Yeah go for it. It was really fun to build and I learned a lot about how these harnesses work. Definitely recommend building something like this.

For me, the use case is in my Remote Terminal app I'm building [1].

I have an agents sidebar that shows every running agent on the machine with the state. So I end up creating a kanban like board for all the agents based on if it needs my attention, is done or still working.

1. https://terminay.com