Auditing what an agent actually did
the diff says what changed; the transcript says what was tried
You want to review agent changes from a week ago: what was touched, and why. Or a build broke and the last person to touch it was a session, not a person. Or a review asks a question the diff cannot answer: what else did it try first.
The transcript records more than the conversation
What the harness writes is not only the words. Each turn carries the files it opened, the commands it ran and what they exited with, and the exact text an edit replaced. That is the part every summary throws away and the part an audit needs — a summary can tell you it "fixed the pool exhaustion"; only the record tells you which file, which command, and what the code said before.
Asking about a file
deja blame internal/index/ingest.go
The sessions that discussed or changed it — those that spelled out the path ahead of a bare mention of the name, then by how often they mention it, with a promoted note above the transcript it came from — each with the project, the agent and the line that settled something. Session history rather than git authorship: it answers why for changes that a commit message reduced to "fix ingest", and it covers work that never became a commit at all.
Asking about one line
$ deja blame internal/index/ingest.go:120
ingest.go:120 last changed in 8f31c0a9 · Sep 12 · fix: titles borrowed from plumbing
written in claude · 4c7e21b8 · deja-vu
replaced: if strings.HasPrefix(title, harnessOutputTitlePrefix) {
why, in full: deja ctx 4c7e21b8
the same line, asked of git and of the session history — recorded against a generated repository, so nobody's code or prompts are in the frame
Git says which commit last changed the line. Then two rules, in order. The strong one: a session whose recorded edit replaced the same text that commit deleted performed this change rather than merely having the file open, and the text it replaced is printed with it. The weaker one, for the commits that deleted nothing — 71% of them — is that some session wrote this very line, into this very file, before the commit carried it. The answer says which rule found it: replaced: or wrote this line:.
How often it answers, measured on this repository on 2026-09-20 over 150 random committed lines: 40% got a session, and 55% of the 88 lines whose last change was in the previous month. On the same 150 lines the replaced-text rule alone answered 6.7%, and nothing it answered was lost — the written side added 50 lines it had nothing to say about. Of those 50, every one was checked against the named session's own transcript on disk and the line was in it. Both rules are bounded by the same two things: the index holds only the sessions the ignore rules admit, and a line is attributed only on evidence — a replaced span or a written line, never proximity in time. The rest is silence, and deja says which silence it is: no indexed session wrote the line or what the commit replaced, the file is not tracked, the line is past the end of the file, the line has no commit yet. What it never prints is a reason — over 81 attributed lines the session's own conclusion overlapped the change zero times, so a single line lifted out of a session would read as the reason for a change it has nothing to do with. The session id and deja ctx are the honest answer to why.
The reverse question is deja files <topic> — which files the work on a topic actually touched — and it answers plainly when nothing matched rather than inventing a list:
$ deja files "zed extension licence" 3 sessions mention "zed extension licence", none of them recorded a file near it
Asking what the agent was told
An audit of the agent is incomplete without an audit of what it was handed. deja log lists every recall and injection — when, which kind, how much, and how many sessions it drew on:
$ deja log 2026-08-24 12:11 dejavu 895 B · 2 sessions 2026-08-24 10:50 hook 2.2 KB · 3 sessions
deja log --last prints the exact digest most recently served, so "what did it actually see" is a question with an answer rather than an inference. That includes the lines injected at the moment of action — before an edit, before a command, after one failed — which used to be counted but not kept, so the surface with the best evidence behind it was the one that could not be read back. Where a trust policy is in force, the receipt names the rule that allowed the injection.
What this is not
It is not a compliance trail. The records are whatever the harness wrote and whatever survived redaction — nothing here proves an agent did not do something, and a harness that logs sparsely leaves gaps that no index can fill. The format registry documents, per harness, what is recorded and what deja could not verify, including the gaps.
It is also not free of judgement: recall ranks, and ranking can be wrong. For an audit, read the session — deja show <id> and deja resume <id> open the real thing rather than a digest of it. In the screen bare deja opens, ↵ on a session reads it from the match, and n steps to the next one.
Where the transcripts live · What is indexed and what is stripped · CLI reference
Found this useful? Star deja-vu on GitHub.