How do I know an AI coding agent actually finished the job?

By deciding which of four questions you are asking, because the agent's report answers only the first. Does the session believe it is finished — that is the report itself. Has somebody who did not write the code read it and agreed. Is the commit contained by the branch you ship from, which is the one a command settles: git merge-base --is-ancestor $commit main exits 0 or it does not. And did the tests that went green run against the tree that contains the change. Four facts, four different ways of being absent, and none of them implies the next.

Can Claude Code review its own code?

It can read it, and that is not the same thing. A session reviewing its own output is missing distance rather than ability: the text it produced is the text it finds most plausible, and confirming costs a sentence while checking costs opening a file. The useful version is a reader that did not write the code and has to name what it opened — a file and a line, or a command and its output. In Clawdline a review step is not satisfied by a reviewer session reporting success; it has to come back with a verdict on three named axes, and each finding carries a severity and evidence you can go and look at yourself.

The tests passed — does that mean the change is on main?

No, and in a checkout shared by several agent sessions those two things come apart routinely. A passing suite is evidence about the tree it ran against, and in a shared checkout the tree is the union of everybody's work while your commit is only your slice. It happened twice in one day in our own repository in August 2026: a commit carried lines whose type was defined in a file that stayed in the working tree, and the tree was green at the moment of committing both times. The question is never is it green, it is green on what — and whether the commit you are asking about is an ancestor of the branch you ship from.

When Claude Code says it's done: delivered, reviewed, or actually on main?

Here is a sentence you have read many times: “I’ve implemented the fix and all tests pass.”

It is usually true, and it does not answer your actual question: whether the change is on the branch you ship from. Four separate facts sit inside the word done, none implying the next.

“All tests pass” is a claim about one of four different things

The third column earns its place: it tells you what to look at.

What “done” might mean	Who is asserting it	What settles it
The session believes it is finished	The session, about its own work	Nothing. This is the claim; it is not evidence for itself
Somebody who did not write it has read it and agrees	A reader with no stake in the code	A review that names what it opened: a file and a line, or a command and its output
The commit is contained by the branch you ship from	The repository	`git merge-base --is-ancestor $commit main`
The tests that passed cover what changed	The test run	Which suite, and which tree it ran against

The third and fourth go missing quietly. On 26 August 2026 a whole-file git add in our own repository twice carried three lines whose type stayed in the working tree. Both trees were green; neither commit could build alone.

In a shared checkout the tree is the union of everybody’s work and your commit is only your slice. A green suite answers a question about the tree, not about what you are pushing.

the session, about itself

I am done

A claim by the party with the least distance from the work. A starting point, not evidence.

somebody who did not write it

Read, and agreed with

A review that can say what it opened: a file and a line.

git

The commit is on the branch you ship from

Bytes do not move themselves. There is an integration in here, and three other sessions to conflict with.

the test run

Green on the tree that contains the change

Green on a different tree is a true statement about something else.

Four things, four different parties asserting them, and none of them implies the next. The orange mark is the only one the session gets to stamp itself. A tool that shows you one tick has decided those four parties are the same one.

For one session in one tab, taking that claim at its word is the right call

One agent, one terminal, one repository: read the report, glance at git log, move on. Trusting it costs one scroll-back the rare time it is wrong, and anything more is ceremony you will drop by Thursday.

What breaks that is arithmetic, not distrust. Four tabs, and “is that one on main?” costs four scroll-backs. A week later the session is closed, and the claim survives only in a transcript nobody will reopen.

What the extra buys is a place where the four facts are written down separately, each at the moment it becomes true.

In Clawdline the four are four separate marks, and no session can write its own

Every session row carries four independent status axes rather than one good/bad icon, and one of them is what the session still owes. A debt survives until it is explicitly cleared.

One check means Delivered; awaiting approval, written only from a result bound to the exact process in that terminal now. Review, integration and landing may all still be outstanding.

The second check the app takes nobody’s word for. Recording a landing means naming a target branch and a commit. The app refuses the record unless that commit is an ancestor of that branch. The check is git merge-base --is-ancestor: your own tool, run by something with no stake in the answer. It gates nothing; a pending landing blocks nobody. What it cannot do is quietly become a tick because the session that wrote the code said so.

A review step works the same way: a reviewer reporting success does not advance it. The verdict has to name three axes: does the change do what was specified, does it break the invariants, does it fail properly. “Looks fine to me” is agreement, not verification.

The screen this buys you is a list called “Delivered, not landed”

The join is a group on the Projects page with that name. Its description is this post in two sentences: nothing says the work reached the tree: no landing record, and no branch git has merged. It is done; nothing merged it.

Every row carries its landing evidence in the app’s words. A root recorded and verified it; git: the branch is in HEAD; git: the branch is still unmerged; git: the branch is gone. Next to it is what would clear the row: land it, or write it off.

The fifth answer is git could not be asked. A stale, missing or ambiguous reading gets an explicit unknown rather than a tidier list. Doubtful evidence does not merely remove a row; it makes the list’s completeness unknowable. A list you cannot trust to be complete gets read as a checklist.

The Clawdfather page is the same idea from the other end: one coordinating session holds the machine-wide picture, not every session a partial copy.

What this does not prove

The containment check proves the commit is an ancestor of the branch you named, on your machine. Not that you pushed, that anybody deployed, or that the green tests ran against that tree.

Nor does recording a landing prove the review was independent. The app can refuse a session’s claim about itself and check a commit against a branch. It cannot tell you whether the reviewer opened the file.

A person working in the same checkout with nothing dispatched is invisible to all of it: no task, no row, no owner, no landing owed.

The four columns, with or without us

Keep four facts where you were keeping one. The report goes where reports go, and the review goes next to the file and line it names. The landing is one command: git merge-base --is-ancestor $commit main && echo on-main. A test result is worth nothing until you record git rev-parse HEAD beside it. That is the difference between “green” and “green on the tree I am asking about”.

Then the rule no tool gives you. Never let the party that did the work write the mark that says it is finished.

The workflows guide covers dispatch, delivery and landing in order. Two neighbours: sending work out in a way you can still cancel at minute three, and what happens when two sessions share one git index.