Notes · rollcall

Finding the work your AI coding agents left behind

When I run several AI coding agents at once, each one usually works in its own git worktree. That is a good habit: agents stay out of each other's files, and every task gets its own branch. It also creates a failure that makes no noise. An agent's process ends, through a crash, a closed terminal or a deleted session, and its worktree stays on disk with uncommitted changes in it. Nothing tells you. The work just sits there.

This is not hypothetical. Claude Code's own documentation for Agent View says some session deletes leave the worktree directory behind, that directories git no longer recognizes do not appear in git worktree list, and that you should "remove those by hand."

rollcall is a small, read-only command-line tool I wrote to find that state. It answers one question: who owns this work, and are they still alive?

rollcall terminal output: a roll call of live agents and worktrees, with SHARED and UNCLAIMED rows and findings underneath
rollcall's terminal output, from the project README. The findings at the bottom are the point; everything above them is a nicer ps.

Why no single source can answer it

Every comparable tool I looked at reads one source. Usage monitors read billing and token files. Session dashboards read session files. Worktree managers know about the worktrees they created. None of them can tell you that a dirty worktree has no live owner, because that fact exists only when three sources are put side by side:

rollcall joins the three. A worktree with one live owner is ACTIVE or IDLE, depending on whether its session reports it is working; two or more live owners make it SHARED. A worktree no live process owns is UNCLAIMED, and an unclaimed worktree that still holds uncommitted changes is the finding the tool exists for. When ownership genuinely cannot be determined, the answer is UNKNOWN, and rollcall reports it as unknown rather than guessing. Take away any one input and that finding cannot be computed at all.

Ownership is a claim, not a fact

rollcall never states ownership as a fact. Each claim carries the evidence it rests on and a confidence:

EvidenceConfidence
The provider named this directory for that session0.95
A live process's working directory is inside the worktree0.85
A live process's working directory contains the worktree0.45
The path looks like .claude/worktrees/<name>0.25

The last row matters most. A path like that is evidence of where a worktree came from, not of who owns it now, and it outlives the process that created it. Mistaking it for a live owner would hide exactly the case the tool is looking for.

Liveness gets the same care. A process ID is not an identity, because the operating system reuses them. rollcall counts a process as alive only when both its ID and its start time still match. An orphan check that trusts a stale process ID reports dead agents as alive, which is worse than no check at all.

Every number says where it came from

Different coding agents expose different things. Claude Code reports token counts, Codex also exposes quota, and neither reports cost. Showing an estimate in the same style as a figure the vendor reported is misleading, so every value rollcall shows is labelled as provider-reported, observed, derived, estimated or unavailable. An unavailable value is shown as a dash, never as zero.

What it will not do

What I cut before writing code

Before any code, I wrote a prior-art search for the idea. It changed the project's name, because the working title belonged to a large open-source project. It cut six planned features, and it demoted usage and quota tracking to a thin layer: several existing tools do that better, so rollcall names them in its README and keeps its own usage layer to one job they cannot do, attributing consumption to a worktree. The same document lists the claims rollcall is not allowed to make, such as being the first tool to find orphaned agent processes. It is not.

Limits

Try it

Nothing is published to a package index; it runs straight from GitHub with uv. The --demo flag renders a bundled, clearly labelled synthetic snapshot. Drop the flag to read your own machine.

uvx --from "git+https://github.com/jimmyjames177414/rollcall" rollcall --demo

rollcall --json emits the whole snapshot against a published schema. The table commands, such as rollcall risks, exit with code 2 when there is at least one critical or high finding, so they can run unattended. One example is a pre-push hook that stops you pushing while work is stranded in another worktree.

What would prove it wrong

I wrote down three ways the idea could fail before building it. If UNCLAIMED is always empty on real multi-agent machines, the headline finding is a non-event. If most worktrees come back UNKNOWN, the join does not pay for itself. And if reading git state in a worktree an agent is using interferes with that agent, the tool is harmful and should not exist. The third is why the read-only rule is enforced by tests rather than promised in prose.

rollcall is Apache-2.0, written in Python, and on GitHub at github.com/jimmyjames177414/rollcall. If you run several agents in parallel, I would like to hear what it finds on your machine.

← All projects