How review works

What a review does

A review reads a pull request from Overlane’s own git service or from a GitHub repository you connect. A pull request on Overlane’s git service is reviewed when it opens and on every push, and overlane review run reviews one on demand. Posting comments to GitHub waits for the GitHub connection’s live leg (see Current limits).

The service loads the diff, skips generated and vendored files, and runs the deterministic checks on every remaining file before any model is involved:

1. a secret scan of the added lines (a credential becomes a critical finding that names the rule, never the text);
2. static rules such as no-eval, sql-concat, no-inner-html, empty-catch, insecure-url, debug-output and unresolved-todo;
3. diff validation: a finding must sit on a line of that file’s diff and match the schema, or it is dropped.

Files are ordered by a static risk score from their size and risky paths (auth, tokens, billing, migrations and similar). These checks cost no tokens. With no model configured they are the whole review, and the run says so.

The model pass is optional, and it comes second. When a model is available it triages the files and then reviews them within the token cap. Each model call has a fallback: if triage fails, the static order stands and every file is reviewed; if the model fails on a file, that file keeps its deterministic findings and the summary names the file. Model findings go through the same diff validation. The code map adds context when an index exists.

It posts inline comments that cite the line and the rule or reason, each with a severity (low, medium, high or critical), and one summary comment that is updated on every push, never duplicated. The summary lists the changes, the risks and the checks, and the files it skipped.

overlane review run 7 --repo acme/app
overlane review findings --status open

Log-only until you turn comments on

A new project is log-only: findings are recorded and shown in the CLI, and nothing is posted to GitHub. An agent or a person with write access to the project enables comments.

overlane review settings set --mode comments

Findings are tracked across pushes

Each finding is open, fixed or dismissed. A finding that comes back on the next push keeps its identity and is not commented twice. A finding that no longer appears becomes fixed. A dismissed finding stays dismissed.

Skips and the token cap

Paths under vendor or node_modules, build output, lockfiles, minified files, binaries and files that declare themselves generated are skipped and listed in the summary. You can add patterns.

overlane review settings set --skip 'docs/**'

Each pull request has a token cap. When a review reaches it, the service stops, posts what it has, marks the summary Partial review, and lists every file it did not cover. It does not retry past the cap.

Fork pull requests

A pull request from a fork runs with an empty secret environment. Nothing from your repository secrets is handed to the run.

Pull request text is data

Titles, descriptions, file paths and code are untrusted data. They are placed inside a fenced block with a random delimiter that the model is told never to obey, and the model’s output is checked: a finding must be on a line of the diff, in the file under review, and match the schema. In posted text, suggestion blocks, images, links and HTML are removed and mentions are defused. The service can only post comments and the summary; it cannot approve, merge, label or push.

Teaching the reviewer

Accept, dismiss and reply feedback adjusts later reviews. When your team keeps dismissing one rule, the reviewer stops reporting it, and the rule is stored as team memory you can read, export and delete. When your team keeps accepting one, the reviewer reports it with priority.

overlane review dismiss fnd_1 --note "intended"
overlane review dismiss fnd_2 --accept

Fix tasks

A finding can become a task whose scope is the finding’s file, optionally assigned to an agent or bot.

overlane review autofix fnd_1 --assign agent:fixer

What is sent to model providers

Only the optional model pass sends anything to a model: the diff of one file at a time, the code-map context around it and your review rules. The deterministic checks send nothing. Credentials that match a provider pattern are replaced before anything is sent, and are reported as a critical finding instead. Overlane does not train on your data. The model provider and its data terms for the hosted review model are not finalised, and the terms are not yet confirmed; this page will name the provider before a frontier model reads real code. Today the hosted pass defaults to an open-weight model on Cloudflare Workers AI through AI Gateway.

overlane review settings

Current limits

To review with your own model, register one under the alias review with the model add command (for example overlane model add review --kind provider --provider anthropic --model <name> --key-env REVIEW_KEY --max-dollars 0.50 --price-in <usd> --price-out <usd>). One review run is one model run, so the model’s token and dollar caps hold across the triage and every file; a file the caps stop is reported as not reviewed by the model. Without a review model the hosted open-weight model is used. When the model fails on a file, the summary says why in a few words.

Posting to GitHub needs the GitHub App’s pull-request write permission, which is not in place yet. Until it is, runs are logged and nothing is posted.