nice one, been looking for something like this. how does it handle a harness updating its file format down the line, do you have to manually track each one's internals or is there a more general way you're detecting sessions?
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.
nice one, been looking for something like this. how does it handle a harness updating its file format down the line, do you have to manually track each one's internals or is there a more general way you're detecting sessions?
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.
why would i not build this tool myself as these are agents running on my machines so i would be aware of which agents are running?
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