jev-gates

How we reviewed this: we ran its 48 tests in Docker and reproduced two findings against its own local stand-in. We made no Jev calls. (Its test suite needs git in the image — on a slim Node image two files hang.)

What it does

jev-gates, by Rashed Parvez, puts seven questions at four moments in a Claude Code session: what does this message actually ask for; is this edit in scope; does it break a rule from your CLAUDE.md; does the commit message match the diff; is the work claimed as done actually done; are the claims in the final message true; and was each change exercised after it was edited.

That last one is the best question in the set:

Editing, reading, or searching the file is not evidence. A failed run is not evidence. Runs that happened before the edit are not evidence.

Note the timing, because it differs by gate. The rule, scope and commit gates run before the action and can stop it. The done, claims and proof gates run at Stop — they can’t prevent an unverified change from being written, only stop Claude from calling it a day.

The calibration table in the README says “one run each, a small sample, not a benchmark”, and lists two of its own false positives. That’s rarer than it should be.

Every failure opens every gate

Each hook ends the same way:

main().catch(() => {
  // No opinion. Normal permission flow applies.
});

A missing key, a timeout, an API outage, a malformed answer — all produce exit 0 and no output, and the session continues as if the plugin weren’t installed. The README states this as a rule, so it isn’t a surprise. But it’s worth being clear about what it means: anything that can make the request fail can turn off all seven gates, silently, and you won’t see it happen. For a guardrail, that’s the property to decide about before installing.

Two things that don’t match the README

“Writes under /tmp are ignored” is true for writes the shell gate detects, and not true for the Write and Edit tools, which have no path exclusion at all. We wrote to /tmp/scratch/.env and watched STRIPE_SECRET_KEY=sk_live_… and DB_PASSWORD=hunter2 go out in the request body verbatim. Nothing in this plugin redacts anything; only length limits apply.

The -a detection over-matches. The commit gate decides whether to include unstaged work using:

/\s(?:-a|--all|-[a-zA-Z]*a[a-zA-Z]*)\b/.test(command.replace(/-m\s+"[^"]*"/g, ""))

Any short flag containing an a matches, and only double-quoted messages are stripped. We reproduced it:

Command	Unstaged work sent?
git commit -m "docs: tidy"	no
ls -la && git commit -m "docs: tidy"	yes
git commit -m 'fix -a handling in the parser'	yes

So work you deliberately didn’t stage — including a file with a token in it — can end up in the request, and the commit message gets compared against a diff larger than the commit. The README’s Limits section says “the commit guard reads the staged diff only”, which contradicts both the code and the README’s own commit-guard section.

Both are reported.

What it sends

More than any other plugin we’ve reviewed: your prompt, the whole file for a Write, the full command line for a Bash call, your absolute working directory, and up to forty tool calls from the turn with 1,200 characters of each result. Length caps only — no redaction of any kind. The reason text shown back to you rewrites your home directory to ~; the request doesn’t.

Verdict

The questions are well written and the escalate-only design is the right shape for a guardrail. Weigh two things against it: everything your agent touched this turn goes to a third party unredacted, and any failure quietly removes the whole thing.

Zero dependencies, which for a hook with this much reach counts for a lot. For the narrower version of the same idea, see jev-belay and winnow.

See how it compares with other tools in Best Jev tools, tested hands-on.

Review updated Sep 20, 2026. Numbers quoted from the project are its author's own; we don't publish our own measurements of Jev.