I built a tiny CLI to see how my coding agent actually worked

Agent Pigeon reads local Claude Code and Codex session history after a run and turns it into a short Flight report. I built it because a final answer rarely shows the path that led there: the edits, checks, and retries in between.

From a long session to one report

npx agent-pigeon flight

I wanted one command that could turn a long coding-agent session into something I could scan in a few seconds.

The GIF uses sanitized synthetic history. The header shows the provider and session span. EDIT counts observed edits; VERIFY includes checks the parser recognizes; FAIL→PASS marks a recognized failure followed by a later pass. The final line shows the latest recognized verification state.

That screen is enough to see where activity went and whether a recognized check eventually passed. I open the original session when I need more context.

Missing data should look missing

Claude Code exposes Read tool calls directly. Codex can perform reads inside broader exec commands, so its history may not show individual reads in a form Agent Pigeon can attribute. When that happens, READ: N/A means the parser cannot count reliably. READ: 0 would imply it saw the full set and found none.

Why I made it read-only

I experimented with live warnings and intervention. While dogfooding it, I got false positives and noisy warnings because the event history was incomplete. I couldn't always tell whether a check had been skipped or the log had failed to capture it, so I stopped treating gaps as a reason to interrupt. The public CLI reads completed sessions in read-only mode; when the signal is incomplete, observation can be more useful than interruption.

Comparing sessions

agent-pigeon compare <session-a> <session-b>

Compare lines up observed facts from two sessions so I can scan them side by side. It has no model scores or declared winner. Provider logs can expose different details, so matching labels may still come from uneven evidence.

What it cannot tell me

• Verification detection is heuristic; custom scripts can be missed.
• READ attribution can be unavailable, especially inside broader command orchestration.
• FAIL→PASS shows sequence. It cannot tell me which edit led to the pass.
• Session span runs from the first to last recorded event, so idle time counts.
• EDIT counts file events, not lines changed or diff size.

Try it

npx agent-pigeon@latest flight

The source is on GitHub. If you try it, tell me what it misses or misreads, especially around edge cases or provider formats.

Disclosure: AI tools helped draft and edit this post and assisted with parts of the launch workflow. I reviewed the technical claims against the source code and the published v0.1.2 CLI.