Direct answer
Did Claude Code Actually Run the Tests? How to Check
Do not trust the summary. A completion message is the model reporting on itself, and models report tests they never ran. The check has three parts: require the raw command output, add a stop hook that runs the suite itself and saves what it produced, and keep that run as a verifiable receipt a reviewer can recheck. Evidence the model does not control is the whole game.
Updated October 20, 2026.
Why completion claims fail
The failure is structural, not personal. A coding agent works in a loop: edit, run, read the result, edit again. Under time and token pressure, the loop shortens. The agent runs a subset and reports the suite, infers a pass from a clean compile, or describes the run it intended to make. The summary it writes at the end is generated text, fluent and confident either way, and nothing in it distinguishes a real run from an imagined one.
That is why the fix is never "ask the agent to be careful". The fix is evidence produced outside the model's control, checked by someone or something that is not the model.
Step 1: Require the raw output
Ask for the terminal output of the test command itself: the runner's header, the per-file results, the summary line with counts (run, passed, failed), and the exit code. A real run produces this in full, with numbers that add up and file names that exist in your repo. A claimed run produces a paraphrase. If the output is missing, truncated, or from before the last code change, the claim is unverified: run the suite yourself, it is the cheapest fact-check there is.
Step 2: Add a stop hook that runs the tests itself
Claude Code hooks are shell commands from your own configuration that fire at set points in the session, including when the agent stops. A Stop hook that runs the suite and writes the result to a file gives you a witness the model cannot edit:
Hook behavior, in plain terms: when the session stops, run the project test command, save the full output plus the exit code and the time to test-evidence/last-run.txt in the repo. The file is overwritten on every stop, so it always shows the most recent run, and its timestamp tells you whether that run came after the last edit.
Then the working rule is one line: no test claim is accepted unless the hook's file shows a full-suite run, after the last change, with everything passing. The agent can say what it likes. The file is the record.
Step 3: Keep the run as a receipt a reviewer can check
The hook's file lives in your repo, which solves your check today. It does not solve the reviewer next week, the client asking what was actually run, or the same question across a team. That is the step Zambo covers: the run is filed as a verifiable receipt, and anyone holding the receipt id can open zambo.dev/verify/ and see exactly what was saved, with no account. The pattern is the same one used for receipts in CI on the receipts in CI page: the pipeline produces the evidence, the receipt makes it checkable by people who were not there.
For $0.99, a Day Pass covers 24 hours of recorded work, which is enough to run your next real change with the record on. Ongoing use is the Zambo Pass at $29 a month or $290 a year, and $19 a month for $ZAMBO holders.
Honest limits
Three edges, stated plainly. First, a passing suite is not proof the code is right: tests can be weak, skipped, or aimed at the wrong behavior, and no record fixes that. The receipt proves the saved output was not changed after the run, never that the work was correct. Second, the hook checks the moment the session stops; work done after the last stop, or in a session where the hook was disabled, leaves no file. Third, re-running the suite yourself remains the strongest check when the suite is fast. Use the record for when it is not, or when the person asking is not you.
Frequently asked questions
Did Claude Code actually run the tests, or did it just say it did?
You cannot tell from the summary, and that is the problem. A completion message is the model reporting on itself. The check is to ask for evidence the model does not control: the raw terminal output of the test command, with the runner's own summary line (tests run, passed, failed) and the exit code. If the session cannot produce that output, treat the claim as unverified and run the suite yourself. It takes a minute, and it settles the question the summary leaves open.
What is a stop hook and how does it help?
Claude Code hooks are commands your configuration runs at set points in the session, including when the agent stops. A Stop hook can run the test suite itself, from the shell, outside the model's control, and save the output to a file. The model can still claim anything it likes; the hook's file either shows a real run with a real result or it does not. Because the hook produces the evidence, the evidence does not depend on the model being honest about what it did.
How do I set up the stop-hook check?
Add a Stop hook in your Claude Code settings that runs your project's test command and writes the output, the exit code, and the time to a file in the repo, for example test-evidence/last-run.txt. Then make the rule simple: no test claim is accepted unless that file shows a run from after the last code change, with the full suite passing. File the run as a verifiable receipt and anyone reviewing the work can check the record at zambo.dev/verify/ without an account, instead of taking the chat's word for it.
Can I re-run the tests cheaply instead of trusting any of this?
Yes, and for a small suite that is the best check of all: run the same command yourself and compare the result. The hook and the receipt matter when re-running is expensive, when the reviewer is not you, or when the question comes up days later and the session is gone. A saved record answers 'did it run, and what did it say' long after the chat that claimed it has scrolled away.
What does the receipt prove here, and what does it not prove?
A verifiable receipt proves the saved result was not changed after the fact: the output in the record is the output the hook produced. It does not prove the tests were the right tests, that they cover the change, or that the code is good. A suite can pass and still test nothing that matters. The receipt settles whether the run happened and what it reported; judging whether the suite is worth trusting is still engineering judgment, yours or your reviewer's.