Documentation

Use it with Claude — three ways

Five things it does for an agent, each one a real run with a screenshot in the agents guide:

1. Before a clone. git clone of a repository that comes back REVIEW: the answer is ask, Claude names what fired and the checks that did not run, clones nothing, and waits for you.
2. A blocked repository. One on the active malware-campaign list: preflight raises, the campaign is named, nothing is installed and no other route is tried.
3. A package install. npm install express or pip install flask names no repository, so the registry is asked which one the package declares and that repository is assessed — allowed, or asked about when it warns.
4. When the answer is REVIEW. With your yes to that call, a deep scan reads the files in a sandbox — one credit, a repeat within 15 minutes free, at most five agent-started scans a day.
5. Nothing to vet. ls, npm test, pip install -r requirements.txt: the hook says nothing and no request leaves the machine.

How a decision is made

1. A download starts from a gated GitHub URL. The extension recognises Download ZIP archives, codeload.github.com, release assets under /releases/download/, raw files, and downloads clicked from a repository page whose bytes come from a GitHub host. It holds the download while it decides.
2. It sends owner/repo to the verdict service at api.repogates.com — plus, if you arrived from a known AI surface, that surface's hostname. Never a full URL, never page or repository contents. (Through the Claude Code plugin or the MCP preflight tool it is the command line instead, with URL credentials and NAME=value assignments redacted, parsed on the server and not stored.)
3. The service runs the 22 checks against the repository's public GitHub metadata and file list, and returns a verdict — PASS, REVIEW or BLOCK — with the findings that fired. Verdicts are cached, so popular repositories answer in milliseconds.
4. The extension applies policy. Each fired check maps to allow, warn or block; the strongest wins. A warn or block cancels the download, discards the partial file and opens the decision page. A warn lets you proceed; a block lets you override only if your policy permits it.
5. The decision is recorded in the audit log on your device — including any proceed or override.

The whole decision is budgeted at about eight seconds, inside the fifteen-second ceiling Chrome gives a download listener. What happens when that ceiling is hit is described plainly in troubleshooting.

Verdicts at a glance

The full table, with what to do in each case, is in the personal guide.

The 22 checks

Four groups. The first three run on the verdict service; the last one can only run in the browser.

• Provenance (C1–C9) — owner account age, repository age, star velocity and traction, fork and lookalike, contributor concentration, licence, maintenance activity, OpenSSF Scorecard, release-asset binaries.
• Execution surface (C10–C17) — devcontainer auto-execution, nested bare repository, submodule definitions, editor and workspace config, build scripts and wrapper JARs, committed binaries, install scripts, directory-entry hooks (.envrc). Read from the file list — no clone — except the devcontainer configuration, which is read so that a command that runs on your host (initializeCommand) is told apart from one that runs inside the container.
• Agent surface (C18–C21) — agent config files, hidden Unicode in agent rules, MCP shell-launch config, credential redirect.
• Agent provenance (C22) — the repository was surfaced to you by an AI agent. Extension only; see how it works and AgentBaiting.

Four dimension verdicts, from the same roster. Beside the single verdict, the score answers the four things you might do with the repository — open it in an editor (C10, C11, C13, C14, C17, C18–C21), clone it (C1–C8, C11, C12), install and run it (C9, C10, C14, C15, C16), hand it to an AI agent (C10, C18–C22) — each PASS, REVIEW, BLOCK or not assessed, with your profile's action. A dimension is a maximum over its checks, never a sum, so the score does not change; it is PASS only when every check in it ran and none fired, and a Scorecard result that does not exist or the browser-only C22 is listed as not checked without withholding it. /v1/score, the MCP check_repo and the preflight carry them, and the preflight's one-line reason ends with the dimension the verb is about (clone: REVIEW, install: PASS). On the board they are the four chips above the family pills. Shipped 10 September 2026 on the API and the agent path; the chips arrive with the next extension release.

The repository timeline. Every fresh answer is kept for 180 days — the date, the verdict, the score and which checks fired, by number; nothing about who asked — and a new point is added only when the answer changed, so a repository that stays the same has one point that keeps being confirmed. /v1/score carries the last twelve as history and the difference since the previous one as drift: the score delta, the checks that newly fired or cleared, and whether the engine changed in between — in which case the movement reflects updated checks, not the repository. A point exists only when someone looked; nothing is re-checked on a schedule. The MCP check_repo and the preflight say the same as changed_since_last; on the board it is the delta beside the score and one line naming what changed. Shipped 10 September 2026 on the API and the agent path; the board part arrives with the next extension release.

Where things stand

This table is what exists today. What is being built, with a date and the gate it must pass, and what is not planned, with the reason, is on the roadmap. When something here changes, the table changes.

Support

Questions, bug reports, false blocks, security disclosures and procurement all reach the same human: support@repogates.com. For a false block, include the owner/repo and the check names shown on the decision page — that is everything we need.

Related: Privacy · Pricing · How we measured ourselves · Honest coverage.