The two replies that have cost me the most time are short ones. "It's fixed." And "that isn't used anywhere." Both sound like a place you can stop. I would read one, move on to the next thing, and only find out later that nothing had run since the last edit, or that the agent had searched once and decided the question was settled.

I run a one-person company on long-running Claude Code sessions and scheduled AI jobs. When an agent tells me a bug is gone and I believe it, I move on. The mistake usually shows up after I've already started something else.

So I wrote a Stop hook. When the agent tries to end its turn after a claim like "fixed," "tests pass," "deployed," or "doesn't exist," the hook looks at what actually happened in the session. If the proof isn't there, it sends the agent back once and says what's missing. The note looks like this:

claim-check: you wrote "is fixed", but nothing ran successfully after the last edit. Run the check that proves it (the tests, the script, a request to the live URL) and show the result, or say plainly that it isn't verified yet.

It never blocks twice in a row, so the agent can't get stuck. If the hook itself crashes, it lets the turn end. And if the agent just says the work isn't verified yet, that always passes. I wanted a way to make it show its work, not a way to trap it.

On November 4, 2026, I ran the hook over my own Claude Code history to see what it would have done. After dropping 1,649 duplicate turns (resuming a session copies earlier turns into a new file), I had 3,977 turns left. 406 of them ended with a claim like "done," "fixed," "deployed," or "tests pass."

The version I measured this way, 0.2.0, would have blocked 86 of those 406. Most of the 86 were not the case I had built it for.

77 had no tool calls at all. Those were usually wrap-ups: the agent saying something was fixed or deployed, with no commit, test result, or status code in the reply. The proof may have been in an earlier turn, but the wrap-up is what I actually read, and it didn't show any. 8 had tool calls, but only reads, searches, read-only commands, to-do updates, or failed commands. 1 made the claim after a code edit with nothing run successfully since. That last one is the case I cared about. It's probably rare in my numbers because an older version of the hook was already catching it on my machine. Your count may be higher.

I hand-checked 24 of the 86: 20 drawn at random when the count was still 82, plus 4 that later rule changes added. Eighteen were wrap-ups that claimed finished work without citing a commit, test output, or status code. Three weren't claims of finished work at all: a research finding (a change had been tested and made the model worse), a condition (the work would count as done once merged), and a plan for work that hadn't started. The other three could be read either way.

After I posted those numbers, someone argued that the 77 wrap-ups were the ones that mattered, because a hook that blocks a correct wrap-up gets turned off. They had a point. In 76 of those 77, something had run successfully after the last edit, just in an earlier turn. So 0.3.0 started counting a check from earlier in the session, as long as no code was edited after it. Of the same 406 claims, it now blocks 2: the one after an edit with nothing run, and one wrap-up with nothing run since the last edit.

The tradeoff is real. A wrap-up no longer has to show its proof, so the wrap-ups I hand-checked get through now too. I'd rather catch the dangerous case and stay installed than win the argument about tidy endings.

Separately, 17 turns ended by saying something wasn't there, and in 2 of them the agent had looked once or not at all. That's the other reply that has burned me. For a "doesn't exist" or "nothing calls it" claim, the hook wants two lookups in that turn, of different kinds. Searching for the same text twice doesn't count, even in another folder or with different flags. A different text, a different file, or a different tool does.

For a "fixed" or "tests pass" claim, what it wants is simpler. Something has to have run after the last code edit and not failed: a shell command, an MCP tool, a URL fetch, or a subagent. git diff and cat don't count, and neither does a command that failed. If the turn didn't edit code, a successful check from earlier in the session is enough, as long as no code was edited after it. The hook will also accept proof cited in the reply itself: a commit hash, a line like "14 passed" with no failures, a 2xx status, "exit code 0," or a link to a CI run. "3 failed, 2 passed" does not count, and neither does "0 passed."

A few of the gaps are worth saying out loud, because they are how you end up turning a hook off.

It matches set phrases. "The redirect loop is fixed" and "Fixed." get caught. "Fixed the redirect loop," "Fixed, deployed to prod," and "I'm done" do not. A sentence that opens with a condition, like "After the restart, everything is deployed," gets through. One honest "not verified" anywhere lets the whole reply through, including an unrelated one like "Fixed. Do not test on prod." It only understands claims in English and Chinese. And a command after the edit only proves that something ran. It doesn't prove the command tested the right thing.

If you want to see what it would do on your own history before it starts sending the agent back, clone the repo and run python3 claim_check.py replay. It reads past sessions in ~/.claude/projects and prints how many claims it would have blocked. Nothing leaves your machine. You can also set the plugin's log_only option to true, leave it for a week, and read the log before you turn blocking on.

For Claude Code, the install is:

/plugin marketplace add Balance0014/claude-code-claim-check /plugin install claim-check@claim-check

Then reload plugins if Claude Code asks, or start a new session. It needs Python 3.9+ and has no dependencies. If you don't use the plugin system, you can point a Stop hook in ~/.claude/settings.json at claim_check.py. For Codex and other agents, npx skills add Balance0014/claude-code-claim-check installs the rules as a skill. The agent can read them, but nothing makes it follow them. There's no hook for Codex in this release.

The hook and the replay script are in claim-check. In the week before I published the first version, the older copy on my machine blocked 19 times. That was enough to keep it on.

If the thing eating your week isn't a false "fixed" but the way long conversations get re-read on every reply, I also made when-to-clear. It reads the token counts Claude Code already saves locally, tells you when it's time to /clear, and can write a handoff note so a new session can pick up the work. Different problem, same machine.