Six independently built, named open-source projects gated Claude Code tool calls with Jev inside the same ten-day window in September 2026, and every single one of them defaults to failing open. That's not a coincidence, and it's the first thing worth understanding before you pick one. This isn't another single-hook tutorial; a solid one already exists. This is a comparison of what six people built independently to solve the same problem, where they agree, where they differ, and what that agreement actually means for you.
The framing that applies everywhere Jev shows up: Jev is not a replacement coding LLM, and it does not power Claude Code. In every tool below, Claude Code's own model still decides what to do and writes the command. Jev's only job is to score that action, read-only or destructive, before it runs.
Key Takeaways- Six named projects (RavenRepo/jevengineeringgate, brunopivetta88/jev-claude, codaaiteam/jev-computer-use, dr-dimitru/claude-jev-plugin, pur4v/jeveloper, RahulBalakavi/claude-code-jev) independently gate Claude Code tool calls with Jev, all within a roughly ten-day window.- Every one of them fails open by default: if the gate itself breaks, the action it was checking is allowed through, not blocked.- They differ meaningfully on threshold source (calibrated from test cases versus fixed defaults), vendor lock-in (Jev-only versus multi-provider), and what part of the tool call lifecycle they actually cover.- Insight: Six people independently arriving at fail-open isn't a safety oversight repeated six times. It's a UX constraint winning over a safety instinct. One project's own docs state it outright: "a hook that breaks the agent when an API is down gets uninstalled within a day," a real trade-off worth deciding for yourself, not inheriting by default.- None of these replace a human decision on anything genuinely high-stakes. They're a fast probabilistic pre-check, not a safety guarantee.
Key Takeaways
- Six named projects (RavenRepo/jevengineeringgate, brunopivetta88/jev-claude, codaaiteam/jev-computer-use, dr-dimitru/claude-jev-plugin, pur4v/jeveloper, RahulBalakavi/claude-code-jev) independently gate Claude Code tool calls with Jev, all within a roughly ten-day window.
- Every one of them fails open by default: if the gate itself breaks, the action it was checking is allowed through, not blocked.
- They differ meaningfully on threshold source (calibrated from test cases versus fixed defaults), vendor lock-in (Jev-only versus multi-provider), and what part of the tool call lifecycle they actually cover.
- Insight: Six people independently arriving at fail-open isn't a safety oversight repeated six times. It's a UX constraint winning over a safety instinct. One project's own docs state it outright: "a hook that breaks the agent when an API is down gets uninstalled within a day," a real trade-off worth deciding for yourself, not inheriting by default.
- None of these replace a human decision on anything genuinely high-stakes. They're a fast probabilistic pre-check, not a safety guarantee.
Because a good single-hook tutorial already exists, and repeating it wouldn't add anything. Grizzly Peak Software's walkthrough (grizzlypeaksoftware.com, September 21, 2026) gives a complete, working Python `PreToolUse` hook. It calls a Jev `Choice` question to classify a shell command as `read_only`, `reversible`, or `destructive`, then asks for confirmation when the command is classified destructive or when Jev's confidence drops below 0.8, whichever triggers first. It runs in shadow mode initially, alongside your existing permissions rather than replacing them, and never auto-approves anything. That's a genuinely good, careful walkthrough of one pattern.
What's missing from the wider conversation is a comparison of the six independent implementations against each other. That comparison means checking which ones lock you into Jev alone, which ones calibrate their thresholds against real test cases instead of guessing, and what a gated call actually costs and delays across all of them. That's the gap this piece fills.
The shape of the pattern, and the failure default. `PreToolUse` is the Claude Code hook every one of these tools hangs off, firing before a proposed tool call actually runs. Each project sends that proposed action to Jev, or in one case to Jev plus a set of deterministic rules, for a probability and a category. It then decides allow, ask, or block based on a threshold. And every one of them fails open. `jevengineeringgate` returns an "escalate" fallback when the API is down. `jev-claude` states outright that it "never fails closed by default." `claude-jev-plugin` documents an extensive list of failure conditions, missing key, timeout, malformed response, rate limits, that all resolve to no denial. `jeveloper` exits its hook cleanly and lets the action proceed untouched. `jev-computer-use` and `claude-code-jev` follow the same pattern.
The reasoning shows up explicitly in more than one project's own documentation: a safety hook that breaks your agent every time an API call times out gets disabled, not fixed. Fail-open is the pragmatic choice for keeping a tool usable day to day. It is also a real decision with a real consequence, one that's easy to inherit without noticing: the moment your safety check is least available is also the moment it doesn't block anything.
On scope, threshold source, vendor lock-in, and cost, more than on the core idea.
Two differences matter more than the rest. First, only one project, `jevengineeringgate`, calibrates its thresholds against a labeled test set rather than shipping a fixed guess. On its own 26-case set, it reports zero wrong decisions and a 25-of-26 hit rate on the primary label, a real, checkable methodology, not a marketing claim. Second, only `jev-claude` is built to be multi-vendor from the start. It combines a Jev score with roughly 35 deterministic regex rules using a "take the higher signal" rule, so Jev can raise an alarm but never suppress one already raised by a plain pattern match. That's a meaningfully different design position from the other five, which are Jev-only end to end.
`claude-code-jev` deserves a specific callout for how it presents its own numbers. Its author reports a 264-millisecond decision time against roughly 4 seconds for an LLM-judge baseline, and about $0.0000227 per decision against roughly $0.0022 for a frontier-model classifier, an apparent 93% latency cut and 99% cost cut, both figures computed from the numbers in the project's own README. The author states plainly that these figures come from five passes of an 18-case synthetic fixture, 90 total decisions against OpenRouter's Jev endpoint, not production traffic, and that the saving only applies if you're replacing an existing slow, LLM-based gate. Running Jev on top of Claude Code's own built-in permission checks, rather than instead of a slower gate, adds latency instead of removing it. That caveat is easy to miss if you only read the headline percentages.
Whichever one matches what the action can cost you if it's wrong. Fail-open is the right default for anything where a false block costs you a minor interruption, and a missed detection is recoverable. It's the wrong default for anything genuinely irreversible, for example a destructive shell command, a payment, or a production deploy. Every project reviewed here defaults to fail-open, and every one of them can be modified to fail closed instead; none of them ship fail-closed as the out-of-the-box setting. If you're wiring one of these into a workflow where the worst case is expensive or irreversible, that's a change you make deliberately, not a default you leave in place because nobody asked.
`claude-jev-plugin`'s documentation is the most thorough on this specific point. It lists out missing keys, invalid config, timeouts, network failures, retry exhaustion, rate limits, and malformed responses as distinct conditions, all resolving to "no denial" in the plugin's own terms. Reading that list is a reasonable first step before adopting any of these six, whichever one you end up choosing, because it names the specific ways a gate can silently stop gating.
Don't wire any of these six straight into blocking mode on day one. Every implementation reviewed here supports, or can be adapted to, a shadow run first: log what the gate would have decided, let the action proceed regardless, and compare the log against what actually happened. Grizzly Peak Software's own walkthrough runs this way by default, alongside your existing permissions rather than replacing them, and that's the right starting posture for any of the six, not just that one.
A concrete four-step procedure. First, run the gate in shadow mode against a real week of your own traffic, not a synthetic test set, so it sees the actual mix of trivial and risky actions your setup produces. Second, pull every case where the gate would have blocked or asked, and check by hand whether that call was right. A high false-block rate here means your threshold is too aggressive for your workload, before it's cost you anything real. Third, pull a sample of the cases it allowed through, not only the ones it flagged. A gate that never blocks anything is failing silently in the other direction, and a sample of clean-looking allows won't tell you that on its own. Fourth, only flip it to enforcing after that week's false-positive and false-negative rates are ones you'd actually accept in production, and re-run the same check after any threshold change, not just once at setup.
Treat the vendor-reported numbers in the table above as a starting point for what to expect, not a substitute for this test. `jevengineeringgate`'s 26-case calibration and `claude-code-jev`'s 90-decision synthetic fixture are both real, checkable methodologies, but neither one ran against your codebase, your commands, or your own risk tolerance.
A probability score is a fast, cheap opinion, not a guarantee. Every one of these tools reduces the odds that an obviously risky action slips through unexamined. None of them eliminate the risk. Three concrete reasons why: thresholds are calibrated against small test sets at best, 26 cases, in the one project that calibrates at all, and guessed at worst. Every implementation fails open, meaning the gate is least present exactly when its infrastructure is under stress. And a probability score, however well calibrated, is still a probability, not a certainty, on a case the model hasn't seen before.
The practical conclusion is the same one we've made elsewhere: a probabilistic pre-check belongs in front of routine, recoverable actions, and a human belongs in front of anything genuinely high-impact, hard to reverse, or expensive to get wrong. That's not a knock on any of these six projects. It's the same distinction we cover generally in bounded permissions and human approval for AI agents: a permission boundary and a probabilistic score both narrow the space of what can go wrong. Neither one is a decision by itself.
Start with what you're trying to protect and what you can't tolerate.
If you want thresholds backed by an actual test set instead of a guess, `jevengineeringgate`'s calibration script is the only one of the six that does this out of the box. If you don't want to depend on Jev alone, or you want a deterministic-rule floor under a probabilistic score, `jev-claude`'s multi-vendor, take-the-higher-signal design is built for exactly that. If you want the most explicit, most exhaustively documented handling of what happens when the gate itself fails, read `claude-jev-plugin` first, even if you end up using something else. If you want coverage beyond the moment before execution, checking whether an action actually succeeded and whether a session is genuinely finished, `jeveloper`'s three-hook route/check/warden pattern is the only one of the six built for that. If you're specifically trying to replace an existing slow, LLM-based classifier rather than adding a new check on top of Claude Code's built-in permissions, read `claude-code-jev`'s caveat closely before assuming it'll help. And if your setup spans more than Claude Code, `jev-computer-use` is the one built to gate Codex and OpenCode the same way.
Yes, in every implementation reviewed here. Each one can be modified to fail closed, but none ships that way out of the box. Check this explicitly before relying on one for anything where a missed block has a real cost.
`RavenRepo/jevengineeringgate` is the only one of the six with a built-in calibration script that fits thresholds against a labeled test set rather than shipping fixed defaults; it reports zero wrong decisions across 26 test cases in its own published results.
Yes, with `brunopivetta88/jev-claude`, which combines a Jev score with roughly 35 deterministic rules and can route to other model providers as well, using whichever signal is higher rather than letting Jev override a rule-based flag.
No. It's a fast, cheap probabilistic pre-check on routine actions, not a safety guarantee. For anything genuinely high-impact or hard to reverse, a human approval step is the appropriate control, not a probability threshold.
That guide is a complete, well-built walkthrough of a single implementation pattern. This piece compares six independent, real implementations of that same idea against each other on fail-open behavior, threshold source, vendor lock-in, and cost. That way you can pick the one that actually matches your risk tolerance, instead of the first one you find.
For the official way to get Claude Code building Jev-powered features in the first place, see how to use Jev with Claude Code. For the same kind of official-versus-experimental comparison applied to context management instead of tool-call safety, see do you need fast-jev-compaction, or is /compact enough.
Maxpertise is an AI-native engineering company. We embed native AI engineers inside your team, live in about 10 days. Please enable JavaScript to view the site, or email contact@maxpertise.net.