Jev Code Reviewer

How we reviewed this: in node:24-slim with git, against stand-ins for both providers and a fake gh on PATH that logged every invocation and refused anything resembling a write. Both endpoints are constants in the source, so we changed the two lines and showed the diff. We made no Jev calls; nothing here measures Jev.

What it does

A local reviewer for pull requests your own coding agent opened. A decision model classifies each change unit — a diff hunk — and an OpenAI model writes the explanation; the result is a set of cards your browser extension renders on GitHub’s Files-changed page. Its first line is the promise worth testing: it “runs on your computer, for reviewing your own coding agent’s PRs, and posts nothing to GitHub”.

Setup

Node 22+, npm install, then jev-reviewer setup to store keys, serve to run the local server, and an unpacked extension loaded in Chrome. npm run demo is the part to try first: a replay on port 4731 that needs no keys.

doctor is unusually candid. On our box it reported the missing tools, then this about our shell environment:

! TYPESAFE_API_KEY: only in this shell's environment, not stored. Other shells and coding agents
  will not see it. Run jev-reviewer setup in your own terminal.
✗ Jev request failed (HTTP 401). Key used: TYPESAFE_API_KEY from this shell's environment.

Naming which source a key came from, and whether anything else will see it, is a small thing that saves an afternoon.

Using it

The demo behaves as documented: /demo served 200 and our stand-ins logged zero provider requests and zero gh invocations while it ran.

A real analyze against a local clone and a stubbed PR completed end to end:

Reviewing OWNER/REPO #1 at f823874d: 1 change units (diff hunks).
Checking TypeSafe Jev and OpenAI access (one small request each)…  Providers OK.
Running Jev classification and OpenAI explanations on 1 unit, one at a time…
  [1/1] P0 src/app.js (0s)
Saved 1 cards (1 P0, 0 P1, 0 P2).  Report: …/reviews/owner--repo--1.json

Two refusals we hit on the way are worth naming as credits. When the PR metadata did not match the repository we pointed it at, it stopped with “GitHub returned a different repository” rather than reviewing the wrong tree. And when our stand-in returned a reply that was not in the provider’s structured shape, it stopped with “Provider check failed; nothing was analyzed” — the check runs before any code is sent, which we confirmed by counting: at that point the request log held two small probes and no code at all.

Permissions and data

This is what the fake gh was for. Across the whole run it made exactly one GitHub call:

api repos/OWNER/REPO/pulls/1

No writes, and no write was even attempted — our stand-in would have logged and refused one. It also never asked GitHub for the diff: the code under review comes from your local clone, which is why the tool insists the clone’s origin matches the PR.

What does leave the machine is the code. With canaries in the diff and in the file around it:

canary	where it lives	reached a provider
CANARY-DIFF-LINE	the changed line	2 (both providers)
CANARY-SOURCE-SECRET	another line of the same file	2 (both providers)
CANARY-PR-TITLE	the PR title	0
CANARY-PR-BODY	the PR description	0

So it sends code and its surrounding context, not the PR’s prose — the right trade for the job, and worth knowing if the file you changed also holds something you would not paste into two SaaS APIs. The report stays local, in the cache directory.

Both endpoints are constants:

-const OPENAI_RESPONSES_URL = 'https://api.openai.com/v1/responses';
-const TYPESAFE_SYSTEM_ONE_URL = 'https://api.typesafe.ai/v1/systemone';

src/providers.mjs, two lines, no environment override — so a gateway or one of the self-hosted Jev-compatible servers in this directory is a patch away rather than a setting away. Two insertions and two deletions in one file, which is how we tested it.

Maintenance

MIT, Node 22+, npm run test:core is 28 tests passing, and there is a demo, a skill directory and a written install path for the extension. The extension is unpacked developer-mode only, and the README says GitHub’s newer /changes page is not supported yet.

Verdict

The clearest “no writes” claim we have been able to verify by instrumentation rather than by reading: one GitHub read, no write attempted, the diff taken from your own clone. Use it when you want a second opinion on an agent’s PR without a bot account and without anything appearing in the thread.

Know that both providers see the changed file’s code, and that redirecting either endpoint means editing one line. For a reviewer that runs in CI instead of a browser, see Jev Review; for the same local-only posture on rules rather than diffs, Abide.

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

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