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	file content read again after earlier reads already covered it
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
Harness write block	Claude Code refused a write or edit before it reached the filesystem

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.

Duplicate-read scoring uses coverage, not merely overlapping byte ranges. A larger read that covers content already fetched counts the duplicated portion, while genuinely new coverage does not. A successful write invalidates the file's prior coverage because reading the new version is useful; unrelated or failed writes do not reset it.

A harness write-block finding records the target path, tool, and whether the path is modelled by toryo's known sensitive-path policy. Modelled means the block fits a restriction toryo can explain and potentially avoid. Unmodelled means Claude Code refused a path outside that model, which is evidence of a capability or policy gap rather than proof the attempted write was safe.

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.