Paper Trail is a free command line tool that reads the session transcripts your coding agents already write to your own disk, and turns them back into a record of what you decided. It answers two questions. Point it at a file and it returns the conversation that decided that file, joined to the commit that changed it. Ask it what you have been deciding and it writes three notes into your own vault: the things you dropped and never picked up, the rules you had to give more than once, and your decisions with the reason and the commits that followed. It is Python and the standard library, with no account, no API key and no dependencies, and it is published under the MIT licence.

Which coding agents does Paper Trail read, and does it run on Windows?

It reads Claude Code and Codex, and treats a project worked on with both as one project. No other agents are supported yet. It is tested on macOS and Linux. Windows is untested and should be treated as unsupported, because roughly seven places in the code assume a POSIX file path. Linking a decision to the code it changed requires that work to be in git.

What does it mean if you keep giving an AI agent the same instruction twice?

It usually means the instruction is not installed anywhere durable, so it has to be re-supplied by a person each time. Most AI reporting measures output, such as tickets closed or hours saved, which tells you the tool is running. Counting how often a human had to repeat something already settled measures something different: whether the way of working holds on its own, or only while the person who set it up is present. On one machine over a few months that count was 69. DETGAAO builds AI into companies so that settled rules do not have to be re-issued every session.

Can AI reliably tell you which conversation caused a code change?

Only if it is allowed to say that it cannot. Matching a commit to whatever was typed nearest to it in time is cheap and often useful, with a median gap of about thirteen minutes between a commit and the last message typed, but nearest in time is not the same as the cause. A stronger method reads the commit's actual diff alongside the messages typed before it and names which one caused that specific change. The important part is that it can return nothing. A tool that can only ever produce a match will be confident on exactly the cases where it is wrong.

How should you evaluate an AI tool before rolling it out?

Ask to see what it does when it does not know. Most evaluations test whether a tool produces a good answer, and fewer test whether it can decline to produce one. A system with no way to return an empty answer gives you no way to separate knowledge from a confident guess. A second check is who reviewed it: an AI system reviewed only by the same model family that built it has not been independently reviewed. DETGAAO builds the declined answer into the systems it puts into companies, because in that work a wrong answer costs more than a missing one.

← Signal

69 rules I had to give twice

Coding agents write every conversation to a file on your own disk, and then nobody ever opens it again. I built something that reads them. Fifteen seconds later I was looking at 69 instructions I had already given once, and by that evening two audits had found the tool breaking its one promise.

August 28, 20267 min readMichael Fellner

This is a technical one, be warned. Coding agents that run in your terminal write every conversation you have with them to a file on your own disk, and then nobody ever opens it again. Months of deciding things, sitting in a folder.

So I built something that reads them. I pointed it at 585 of mine, 1.6 GB, and about fifteen seconds later I was looking at a list of 69 instructions I'd already given once.

Not 69 similar ones. The same rule, given again, because the first time didn't stick.

It answers two questions

The tool is called Paper Trail.

Why is this file like this? Point at any file and you get the conversation that decided it, joined to the commit that changed it. Not the ticket, not the commit message somebody wrote afterwards. The sentence somebody typed.

What have I been deciding? Three notes, written into my own vault. The things I dropped and nothing since picked up, 11 of those. The rules I had to give more than once, the 69. And the decisions, 117 of them, each with the reason and the commits that followed.

It reads Claude Code and Codex, and treats a project you worked on with both as one project. Python and the standard library, so there's no account, no API key and nothing to install but a symlink. (Yes, a symlink. It's a free tool, not a launch.) The reading and the joining happen on your machine.

I went looking for one of these before I built it. There are a dozen free tools that draw you a map of your code, I've used a few, they're fine. I couldn't find one that reads the conversation instead of the code. They all map what you built. None of them map what you decided. If one exists I'd honestly rather use it than maintain mine, so tell me and I'll go and look.

Nobody counts the second time

The 69 isn't a guess.

It doesn't cluster sentences and call two things the same rule. I tried that against my own transcripts and it merged nine unrelated rules into one blob. So a repeat only counts when my own sentence says so. I told you. We agreed. How many times. You keep.

Which means every one of those 69 is a decision that was already made, and then wasn't there the next time. The setup dropped it.

I think that's an operations number, not a memory one.

Everyone running AI in a business is measuring output. Tickets closed, hours saved, drafts produced, the slide with the arrow going up. Almost nobody is measuring how often a human had to go back and say the same thing again, and that second number is the one that tells you whether the thing took or whether it's just switched on.

Mine is 69, over a few months, one person who does this full time and tries to fix as I go, rather than "yell" at CC for doing the same 'mistake' twice.

If you're a team of ten, your number isn't ten times mine. I'd bet it's worse than that per person, because a settled thing has further to travel and more places to fall down on the way. I'd like to be wrong about that, and I can't check, because as far as I can tell nobody has ever counted it.

Then it broke its one promise

Paper Trail makes exactly one promise: it can't read anything you haven't allowed. Two lists, both empty on the first run, and nothing is readable until you switch it on. You delete a # in front of a project and that project becomes readable. Forget to allow something and nothing happens, which is the right way round for this to fail.

It went public on a Saturday afternoon. Within hours I had an audit on it, told to go and reproduce things against a running copy rather than read the code off the page. That audit came from the same model family the tool was written in, which I half expected to make it useless. It found the big one anyway.

Taking a project back out of the list did nothing until the next scan.

It kept printing that project's quotes. It wrote them into a new note. And the step that recovers reasoning would go and reopen that project's transcript and send it off to a model. The file on my machine said "not allowed" the whole time.

That's the one sentence the whole thing rests on, and it wasn't true.

Then the fix caused a second bug within minutes. Filtering the index also blinded the routine that remembers when each finding first turned up, so everything I'd ever found silently became new again. The tests caught that one. Without them the notes would have looked perfect and been wrong.

While I was in there I found that the README opened with "no network" while the setting it shipped with sent conversation extracts off to a cloud model. I wrote that sentence myself. Then the code moved underneath it and I never went back and read it again. It says something else now, and which model answers is still your pick, the local one included.

That was v1.0.1, out by early evening.

Then I ran a second pass from a different model family, told not to re-report anything the first one had already found. It came back with seven more, two of them sitting on the same boundary the first audit had already moved and thought it had closed.

One of those I'd have called small until somebody measured it. The index was filtered by project. The commits attached to each finding weren't. So taking a repository out of the list left its subjects, its hashes and its file names still turning up in the notes, and still going into the text sent to a model. 474 attached commits before revoking one repository. 388 after. The gap is what the first fix had been leaving behind.

Two of its findings I threw out after going and checking them myself, and one is worth arguing about. It said the tool would run out of memory on a big corpus. It doesn't, because what it keeps is what a person typed rather than the corpus itself, 2,750 messages out of that 1.6 GB. I overruled a machine on that one, so tell me if you think I got it wrong.

v1.0.2 went out about forty minutes after v1.0.1, same evening, each fix with a test pinning it so it can't come back.

Not all of it, though, and I'd rather say so than let you find it. Windows I left open on purpose and wrote down instead, because a half-done pass over seven path assumptions would have claimed support nobody has run. That one is still open today.

I don't think one review pass is enough anymore, however good the reviewer is.

I could have shipped and said nothing. Free tool, nobody harmed, low odds of anyone finding that hole in week one. Which is exactly why it's here.

It's allowed to say it doesn't know

Anyone can match a commit to whatever was typed nearest to it in time. Paper Trail does that for free, and it's right often enough to be useful. The median gap between a commit and the last thing I typed is thirteen minutes.

Ask it to try harder and it reads the commit's actual diff alongside everything typed in the window before it, then says which sentence caused that change. On one commit it walked straight past two nearer messages for one I'd typed ninety minutes earlier. On the very next commit it refused:

Neither message names anything in the diff. The actual cause isn't present in either typed message.

I'd rather it came back empty than guessed. Anything that always has an answer is reading a clock and calling it a reason, and it'll be at its most confident on exactly the commits you needed explaining.

What it can't do yet

Claude Code and Codex, nothing else. Other agents write the same kind of file and I haven't done them.

Windows is untested, for the reason above. macOS and Linux.

Linking a decision to code needs the work to be in git.

There's one I can't fix from where I'm standing. Two folders called my-app and my_app come out with the same name in the allowlist, so allowing one allows both. Doing it properly needs a second, incompatible list. For now it spots the collision and prints both folders, rather than letting you find out on your own.

And a join is a strong hint, not proof. When a match is weak it says so, and it tells you how long after a sentence the commit landed, so you can disagree with it in about two seconds.

It's free and MIT, at github.com/DetGaao/paper-trail. No email, no signup, nothing behind a form.

Before you install anything though, guess. How many times this month did you tell an agent something it had already been told? Say the number out loud, then go and count it. The gap between those two numbers is the whole argument.

Mine was 69, and I've spent the week telling myself that's a respectable score for someone who does this full time. It isn't. Tell me yours and I'll feel better about it.

A dark portrait card headed 69 RULES I GAVE TWICE, with the 69 in red. Beneath it: 585 sessions, 1.6 GB, read in about fifteen seconds, every repeat counted because my own sentence said so. Below that, under the label AND IT JOINS THE DECISION TO THE CODE, a terminal window titled paper-trail shows the command paper-trail why lib/notes.py returning commit abc3288 dated 2026-08-21, with the subject 'The index page and the loops page now count the same thing'. It notes the commit changed lib/notes.py alongside one other file, that the message was said 2 min earlier in the cc-toolchain project, and quotes the message itself: 'Let me look at the file in more detail, but curious how you interprete the file?'. A red-ruled note closes the card: a dozen free tools draw you a map of your code, this one maps what you decided, and what it turned into.

Frequently asked questions

What is Paper Trail?: Paper Trail is a free command line tool that reads the session transcripts your coding agents already write to your own disk, and turns them back into a record of what you decided. It answers two questions. Point it at a file and it returns the conversation that decided that file, joined to the commit that changed it. Ask it what you have been deciding and it writes three notes into your own vault: the things you dropped and never picked up, the rules you had to give more than once, and your decisions with the reason and the commits that followed. It is Python and the standard library, with no account, no API key and no dependencies, and it is published under the MIT licence.
Which coding agents does Paper Trail read, and does it run on Windows?: It reads Claude Code and Codex, and treats a project worked on with both as one project. No other agents are supported yet. It is tested on macOS and Linux. Windows is untested and should be treated as unsupported, because roughly seven places in the code assume a POSIX file path. Linking a decision to the code it changed requires that work to be in git.
What does it mean if you keep giving an AI agent the same instruction twice?: It usually means the instruction is not installed anywhere durable, so it has to be re-supplied by a person each time. Most AI reporting measures output, such as tickets closed or hours saved, which tells you the tool is running. Counting how often a human had to repeat something already settled measures something different: whether the way of working holds on its own, or only while the person who set it up is present. On one machine over a few months that count was 69. DETGAAO builds AI into companies so that settled rules do not have to be re-issued every session.
Can AI reliably tell you which conversation caused a code change?: Only if it is allowed to say that it cannot. Matching a commit to whatever was typed nearest to it in time is cheap and often useful, with a median gap of about thirteen minutes between a commit and the last message typed, but nearest in time is not the same as the cause. A stronger method reads the commit's actual diff alongside the messages typed before it and names which one caused that specific change. The important part is that it can return nothing. A tool that can only ever produce a match will be confident on exactly the cases where it is wrong.
How should you evaluate an AI tool before rolling it out?: Ask to see what it does when it does not know. Most evaluations test whether a tool produces a good answer, and fewer test whether it can decline to produce one. A system with no way to return an empty answer gives you no way to separate knowledge from a confident guess. A second check is who reviewed it: an AI system reviewed only by the same model family that built it has not been independently reviewed. DETGAAO builds the declined answer into the systems it puts into companies, because in that work a wrong answer costs more than a missing one.

Want help thinking through what this changes for your marketing operations?

Start a conversation