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?
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:
- The operating system's process table: which agent processes are running, their working directories, and when each one started.
- Each provider's session metadata: Claude Code's agent list and Codex's session files, which say which session is working where.
- Git: every worktree, its branch, and whether it holds uncommitted changes.
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:
| Evidence | Confidence |
|---|---|
| The provider named this directory for that session | 0.95 |
| A live process's working directory is inside the worktree | 0.85 |
| A live process's working directory contains the worktree | 0.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
- It never writes to a repository. It reads working directories that live agents are using, so every git call runs with
--no-optional-locks, and a test checks that a real scan leaves each git index file's modification time and size, and the output ofgit status, unchanged. - It never launches, stops or controls an agent, and never deletes a worktree. It tells you a worktree looks abandoned. What to do about it is your call.
- It never reads conversation text. It reads session titles, and from session files it extracts only metadata such as the model, the last activity time and token counts.
- It never sends anything anywhere. The optional web view binds to
127.0.0.1and works offline.
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
- Two providers today: Claude Code and Codex. Gemini CLI, Copilot CLI and OpenCode are declared unsupported, because I could not verify how their live sessions behave, and an adapter that guesses would be inventing a capability.
- Claude background sessions expose no process ID, so their owner cannot be checked for liveness. rollcall says so.
- On WSL, Windows-side processes are invisible from Linux and the reverse. rollcall detects this and prints it as a limitation on every run, so a zero agent count comes with the reason.
- Below about four concurrent agents, you do not need it. Open a terminal and look.
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.