jevwire

How we reviewed this: we ran its 1,461 tests in Docker offline, drove all six tools over stdio MCP against a local stand-in, and probed the path rules with planted files. We made no Jev calls.

What it does

Three things in one repository: an MCP server with six tools, an embeddable decision library with no MCP or schema dependencies, and a Claude Code hook plugin with a resident daemon.

The gate questions are the most carefully constructed we have read. Each names the state path it judges, carries examples on the true side and a not_for clause on the side a lookalike case would wrongly land in:

Does action delete, overwrite, or irreversibly change a file, a git ref, a database, or other state that existed before it ran?

with focus: “Judge the command or edit as written. Creating something new, or a change that git, an undo, or a re-run can put back, is not destructive.”

And the tool description says, in capitals, that this is not a security boundary and that text arguing for its own approval can shift the result. Nothing else in this ecosystem limits its own claims that way.

The file handling is the strongest part. Paths are checked for sensitivity three times — literally, relative, and again after realpath — and confined to a project root by realpath containment, so .., absolute paths and symlinks out are one rejection rather than three. Requests are priced before they are sent, at the only point where nothing has left yet. We pointed jev_rank at a planted .env, a key file and /etc/passwd: two skipped as sensitive, one as outside root, and the planted secret appears nowhere in the captured requests.

The one rule that cannot fire

const SENSITIVE_DIRS = new Set([".ssh", ".aws", ".gnupg", ".config/gcloud", ".kube", ".docker"]);
…
const parts = normalized.split("/").filter((part) => part !== "");
…
if (parts.some((part) => SENSITIVE_DIRS.has(part))) return true;

parts are single path segments. ".config/gcloud" contains a slash, so no segment can ever equal it. Five of the six entries work; that one is dead code. Running the compiled predicate: .ssh/id_rsa, .aws/credentials, .kube/config and .docker/config.json all return true; .config/gcloud/application_default_credentials.json returns false.

In the MCP server the gap is usually covered by root confinement, since gcloud credentials live outside a project. In the hook’s prefilter it is not covered: a command reading that file does not pick up the “sensitive path” reason that would send it to be judged.

The irony is in the file’s own header, which explains why there is exactly one copy of this predicate: “Two copies of a security predicate drift, and the copy that drifts is the one that stops refusing.” They prevented the drift and shipped a typo in the single copy. It is a one-word fix, and reported.

What to know before installing

The hook fails open. An upstream error is logged and the handler returns nothing, which means Claude Code proceeds. That is consistent with a plugin that only ever escalates and never approves — "allow" is not even representable in the handler, guarded by a 37-case test — but it means an outage removes the gate entirely and quietly.

And every installation command in the README is broken: jevwire does not exist on npm. The only route that works is the Claude Code plugin marketplace.

Verdict

1,461 tests, zero failures, a daemon memo cache that refuses to bill for calls it did not make, and a security predicate with a comment explaining its own design. The care here is real.

Fix the one dead entry, publish the package the README tells people to install, and know that when Jev is down this guard is not there.

For the same gate with a narrower scope, see jev-gates and pi-warden.

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.