Cora Code v0.19.0: the agent becomes the reviewer, no API key required

Your AI agent writes the code. Until this release, reviewing that code meant one of two things: hand a second LLM your API key, or settle for checks that skim the surface. Cora Code v0.19.0, released yesterday, takes a third path. The agent that wrote the change can now be the one that judges it, and cora itself runs fine with no key at all.

That split matters more this month than it did last month. Liquid AI put LFM2.5-24B-A2B, a model built for fast on-device agents, on the HN front page this week. Models keep moving toward the machine that runs your agent. A review tool that demands its own cloud key is starting to look like the odd one out.

What runs without a key

cora review and cora scan used to refuse to start without an API key. In v0.19.0 they run the deterministic half with no key configured: 12 built-in rules, 13 security patterns, and 15 secret detection patterns, straight from the README. A one-line notice on stderr says the LLM judge is off, and the result carries a cora.judge = none marker so nothing downstream mistakes a scanner-only pass for a full review. --no-llm forces the same mode and silences the notice.

Two commands still want a key: cora commit and the MCP cora.review_diff. Everything else works offline, out of the box.

Agent as judge, over MCP

The bigger change is the new review protocol. Four MCP tools split a review into three steps, and your agent owns the middle one:

1. cora.review_prepare returns the hardened review prompts, the list of valid files, cora's own deterministic findings, and the response schema the agent must answer in.
2. The agent reads the diff and judges it with whatever model it already runs. Cora never sees an API key, because there is no key to see.
3. cora.review_finalize takes the agent's findings, validates them through a judge::admit gate, merges them with the deterministic results, applies ignore.rules and inline cora-ignore: markers, runs the quality gate, and returns the verdict.

cora.scan_prepare and cora.scan_finalize do the same for whole-project scans, one batch at a time. The protocol is stateless: finalize recomputes the deterministic half from the same diff or path, so a stale or fabricated agent answer cannot override what the scanners found.

Setup is one command. cora install detects your agent and registers the MCP server, and it drops a /cora-review skill into ~/.claude/skills/ for Claude Code users. For Claude Code the server registers with claude mcp add cora -- cora mcp. Our earlier post on reviewing AI-generated PRs covered the accountability gap in tooling that reviewed agent output from the outside; this release moves cora into the loop from the inside instead.

The judge is untrusted input

Handing judgment to an agent only works if the tool treats the agent's answer as hostile until proven otherwise. v0.19.0 does:

• judge::admit strips rule_id from anything a judge submits (only deterministic scanners may carry one), truncates long fields, caps the list at 200 findings with the most severe kept, and drops findings that point outside the diff or scan batch. A judge can add findings, but it can never remove one.
• When a judge issue lands on the same line and topic as a scanner finding, the surviving entry takes the stronger severity and the scanner's rule. An "info" note can no longer quietly absorb a CRITICAL.
• A follow-up audit pass closed the diff-parsing tricks: --- and +++ lines inside a partially consumed hunk are content now, not file headers, so a removed SQL comment cannot swallow the rest of a hunk. cora scan stopped following symlinks, so id -> ~/.ssh/id_rsa stays out of your prompts.
• The review cache is keyed by the exact prompts plus model, provider, base URL, and temperature, so cached answers cannot leak across modes.
• And a small one that matters in CI: cora --help no longer prints environment-bound values, so CORA_API_KEY or GITHUB_TOKEN stay out of your build logs.

Why this shape

The deterministic half and the judgment half have different homes. Rules, secret patterns, and security checks are repeatable, cheap, and belong in a binary you can audit. Taste, intent, and "does this change make sense" belong wherever your model already lives. v0.19.0 stops pretending one tool should hold both, and stops asking you to route your code through a second vendor to get the second half.

It also fits where agents are heading. The Ars Technica piece this week argued agents generate more code but not more software; the bottleneck is shifting to review and understanding. A review gate that scales with agent output, runs offline, and never holds a key is built for that bottleneck.

Try it

v0.19.0 is on GitHub under Apache-2.0 and live on crates.io. Install with the quick installer:

curl -fsSL https://raw.githubusercontent.com/codecoradev/cora-code/main/install-bundle.sh | sh

Then run cora review with no key at all, or register the MCP server and let your agent call cora.review_prepare on the next diff. The agent-review workflow is documented in full, benchmarks included: ~936ms cold index and ~5ms hybrid search on this repository, measured per the README.