Session debugger
Finds waste in how your agents work. The session debugger reads Claude Code session transcripts and looks for behavioral waste: work an agent did more than once, or work that never succeeded.
Part of the brain.
What it looks for#
| Pattern | What it means |
|---|---|
| Duplicate read | the same file read repeatedly in one session |
| Retry loop | the same tool failing several times in a row |
| Compaction reread | a file re-read after the session compacted its context, so knowledge was lost and rebought |
| Failed tool | errors grouped by tool |
None of this needs a model. The detectors are pure analysis over transcripts that are already on disk, so they cost nothing to run and cannot fail in interesting ways.
How it runs#
Analysis happens per session, automatically, when a worker session ends. It runs out of process so it never delays teardown, and it is read-only, so there is nothing to opt out of.
Aggregation happens nightly, on the scheduler's system lane.
This is the step that matters: a pattern in one session is noise, and a pattern
across several runs is a real problem. When one crosses the threshold, it is
filed as a rule-gap idea for you to triage.
Refiling is safe. The idea's text is stable and count-free, so a repeated report bumps that idea's recurrence counter rather than creating another one.
Why it exists#
This closes a loop. Friction shows up in transcripts long before anyone thinks to complain about it; a rule that would have prevented it is usually one line. The debugger turns the first into the second without you having to read transcripts.
A rule-gap idea you promote typically becomes a project directive, which then
governs every future session in that project. See directives.
In board#
There is no Session Debugger screen. What the debugger produces for you arrives
as rule-gap ideas on the Ideas screen, where you triage them and promote
the ones worth acting on.
Full command surface: CLI & contract reference.