FAQ

Why doesn't Argus review my PR automatically?

The default depends on your deployment's configuration. With SELF_HOSTED=true, Argus reviews every PR by default. If SELF_HOSTED is unset or anything other than true (backend/.env.example ships SELF_HOSTED=false), auto-review is off until you enable it: a fresh repo gets a one-shot Trigger Argus review checkbox with a token + cost preview instead of an automatic run (tick it to run on demand). Either way, a repo or org that turns auto-review off explicitly stays off. If Argus stayed silent, other likely causes: the PR opened before Argus was installed, a webhook delivery failed, no API key is configured (you'll see an onboarding comment), or the base branch matches a Branch Filters skip pattern. A manual trigger (the checkbox, a review comment, or the dashboard) skips that filter and reviews the PR anyway.

To change the default: Settings → Org Defaults → Auto-review (org-wide) or Repo Overrides → Auto-review (per-repo). Repo setting beats org default.

Why did Argus post nothing on my PR?

If the header reads ## Argus · 10/10 — No findings, one of three things happened: the review raised nothing, nothing it raised cleared the judge's bar for the PR's class, or team feedback removed everything that did. The dashboard's review page lists anything team feedback removed.

If no summary posted at all, look for a checkbox comment (auto-review is off for the repo), a refusal (the PR is over the size limit), a setup comment (no model key yet), or a progress comment that says the review failed. If there is no Argus comment of any kind, see the question above.

The trigger checkbox doesn't appear on a PR — what now?

A few reasons the one-shot trigger comment may not be present:

• The PR opened before Argus was installed on the repo.
• A webhook delivery failed and wasn't redelivered.
• Auto-review is on — in that case no checkbox is needed.
• The base branch matches a skip pattern in Branch Filters. The review comment described below skips that filter.
• No API key is configured — you'll see an onboarding comment instead.

Someone with write access can also trigger a review by commenting @argus-eye review on the PR. argus-eye is the default App slug; your install answers to your own App's slug (GITHUB_APP_SLUG).

Who can click the trigger checkbox?

Ticking the box requires repository write access — Argus checks the editor's permission, not just the comment body. Clicks on pasted or forged trigger comments are ignored — only comments authored by your App's bot account (argus-eye[bot] with the default slug) count.

Who can start a review on my key?

With auto-review on (the default when SELF_HOSTED=true and no setting is stored), every pull request opened, pushed to or reopened on an installed repository is reviewed, including pull requests from forks. On a public repository, switch auto-review off so each PR waits for a tick from someone with write access. @argus-eye review needs write access too. Replies in an Argus thread and @argus-eye test from anyone still make a model call on your key.

Why not run an LLM on the diff in CI?

You can. Argus adds the change-class routing, the written rubric and judge thresholds, the 10-comment cap, re-checks of its own threads on push, and memory of what your team dismissed and settled.

What happens when I 👎 or reply to a finding?

Anyone who replies gets an answer in the thread. If you have write access, Argus also stores your reply as memory for the repo, and it records a 👎 from you at the next review of that PR or when someone replies to that comment. With an embeddings endpoint, a later finding that matches a dismissal at 0.80 similarity or higher is dropped before posting and counted in the summary. Security findings and the five permanent checks are lowered one severity at most. The memory rules, with where each one stops, are in Memory & learning.

Will it edit my PR description?

Yes, unless you turn PR enrichment off for the repo (Settings → Org defaults → Pipeline features → PR Enrichment, or per repo on Repo Overrides). After a review with findings, it appends an "Also in this PR" list and up to two Mermaid diagrams drawn only from edges in the repo's code graph. Diagrams need the dashboard's Mermaid validator configured; without it they are left out.

Can Argus block a merge?

Not on its own. It posts a GitHub review with the COMMENT event, never approves or requests changes, and creates no status checks, so merging stays with your branch rules and reviewers. If those rules require resolved conversations, open Argus threads count like anyone else's.

Does Argus run my code or my tests?

No. The review, the judge, the re-check on push and the "earlier findings may still apply" block are model calls over diff text and stored findings. Suggested fixes carry the line "Argus did not compile or run this fix", and @argus-eye test --code posts draft test code without committing, compiling or running it. staticcheck, ESLint and Semgrep, when the image has them, analyze changed files without executing them. Their results reach the reviewer's prompt, and under Deep Review they can also raise a matching finding's judge score.

How many LLM tokens does the issue acceptance check cost?

One extra LLM call per linked issue, for up to 5 issues per review. Each call sends the issue's criteria and each changed file's diff cut to 500 characters, and the response is capped at 4,000 tokens. The token breakdown in the review comment lists what the acceptance stage actually used.

What if the issue body has no acceptance criteria section?

Argus uses the issue body, cut to 500 characters, as one free-form criterion and asks the LLM to judge it. You'll get one verdict instead of a per-criterion checklist. Add a structured section to get per-criterion verdicts.

Why does a linked PR say "Not checked"?

Argus fetches linked PRs through the GitHub App installation of the primary PR. If the linked PR lives in a repo where Argus isn't installed, the GitHub API returns 404 or 403, and the Cross-Repo PR Coverage section lists that PR as Not checked with the reason, for example "not found (Argus may not be installed on this repo)". If no linked PR can be read, no cross-repo section is posted. The primary review still completes normally.

Add the linked repo to the same installation of your Argus GitHub App (same account or org) so the cross-PR check can read it.

Can I disable these features?

Yes. Auto-review lives under Settings → Org defaults → Auto-review (per-repo on Repo Overrides); the verification features live under Settings → Org defaults → Verification features:

• Auto-review — when off, opened PRs get a trigger checkbox instead of running automatically (default: on with SELF_HOSTED=true, off when SELF_HOSTED is unset or anything else, such as the SELF_HOSTED=false in backend/.env.example; an explicit repo or org setting wins either way).
• Issue acceptance check — toggles the issue verification worker (default: on).
• Cross-repo PR checks — toggles the cross-PR worker (default: on).
• Max linked PRs per review — caps how many PRs the cross-PR worker fetches (default: 5, range 1–20).

What if the linked issue is in a different repo?

Argus tries to fetch it via the installation that owns the primary PR. If that works (i.e., the installation has access to both repos), the check runs normally. If not, the issue is skipped: it does not appear in the Issue Coverage section, and the review continues.

Does this work with GitLab/Bitbucket?

No. Argus is a GitHub App and works with GitHub only. Linked issues come from GitHub's GraphQL closingIssuesReferences field plus a regex over the PR body.

What leaves my servers?

Six destinations, and the last two only when you configure them:

• Your LLM provider: diffs, file contents, PR title and body, and memory excerpts.
• Your embedding endpoint: finding and memory text. backend/.env.example points it at https://ai-gateway.vercel.sh/v1; unset, the default is https://api.voyageai.com/v1.
• Clerk: dashboard and MCP sign-in.
• OpenRouter: its public model and price list, with no code or keys. The backend fetches it unless OPENROUTER_PRICING_ENABLED=false. The dashboard's server also fetches it, and each model's endpoint list, when someone opens the /pricing estimator; that flag does not stop those requests.
• TypeSafe, for the opt-in Jev classifier: finding text, PR metadata and a body excerpt, the stated goal, diff excerpts and stored conventions. Only if you set TYPESAFE_API_KEY and opt an installation in, or an installation stores its own TypeSafe key on the Integrations page (see the TypeSafe question below).
• PostHog: from the server only when POSTHOG_API_KEY is set, and from the dashboard only when NEXT_PUBLIC_POSTHOG_PROJECT_TOKEN is set.

The self-hosting guide covers where data is stored and what to change before the host is reachable.

Does it stop prompt injection in pull requests?

It reduces it; it does not prevent it. PR titles, bodies, labels, replies and stored memory are redacted against a list of English injection phrases and wrapped as data before they reach the model. Diffs and file contents go to the model as they are.

Does Argus send my code to TypeSafe?

Only if you opt in. The Jev classifier is off by default — with no key configured, Argus makes zero Jev calls. On the server-key path, egress needs both TYPESAFE_API_KEY set on the backend and the jev_classifier feature flag enabled per installation (a database flag, with no dashboard toggle). Alternatively, add your own key in Integrations → TypeSafe Jev — saving the key is the consent to egress.

When enabled, Jev calls send finding text, PR metadata plus a body excerpt, the extracted PR intent, diff excerpts for up to 40 files (triage shadow) plus inter-diff hunks for up to 20 auto-resolve candidates per push, and stored conventions to api.typesafe.ai (or your stored custom endpoint) — for that installation only. See TypeSafe Jev classifier.

Can I pick Jev as the model for a review stage?

No. Jev is a typed classifier — it answers yes/no, choice, and score questions with probabilities and can't emit prose, so it's never an LLM provider. It runs as a front-runner on narrow decisions: confident answers skip the LLM call, and the uncertain band escalates to your configured models unchanged.

What does Jev cost?

$0.042 per million input tokens; output tokens are free. Answers come back in roughly 200–300ms, and a confident Jev answer can skip a much more expensive generative call. Jev spend is recorded in the token usage of the stage it front-runs.