Skip to main content
Auto-approve lets Greptile approve pull requests that it rates as low-risk and bug-free. It only approves PRs with a clean 5/5 Greptile review. You can cap the risk level Greptile approves, define what each risk level means, and restrict auto-approval to certain PRs. Auto-approve is in beta. We recommend using it only for low-risk changes, not as a universal rule for every PR. Auto-approve works on GitHub, GitLab, Bitbucket Cloud, and Gitea. It is not available on Bitbucket Data Center or Perforce.

​
Configure auto-approve

1

Open Auto-approve settings

On the Greptile dashboard, go to Settings -> Code Review -> Auto-approve PRs.
Auto-approve settings: Auto-approve PRs toggle with Cap risk level, Risk definitions, and Only certain PRs options
2

Enable auto-approve

Turn on Auto-approve PRs.The toggle requires the Confidence Score review section to be on. Auto-approve reads the 5/5 score from it.
3

Cap the risk level

Turn on Cap risk level, then choose the highest risk level Greptile is allowed to approve. Greptile only auto-approves PRs at or below this level.With no cap, the ceiling is Critical — Greptile can approve any PR with a clean 5/5 review, whatever it changes. Set the cap right after enabling auto-approve.Use Low for docs, tests, styling, and small code changes. Use higher levels only when you are comfortable with Greptile approving those changes without another human review.
4

Define risk levels (optional)

Turn on Risk definitions and write plain-language guidance for the risk assessment, such as which parts of your codebase are riskier than they look. See Risk definitions below.
5

Limit to certain PRs

Turn on Only certain PRs and add filters for authors, repositories, target branches, labels, keywords, or paths. Each filter either includes or excludes PRs from auto-approval. Add per-repo filters in your .greptile file.
Auto-approval still requires a clean 5/5 Greptile review. If Greptile finds an issue, or the PR does not meet the configured risk threshold, it will not approve the PR.

​
How risk levels work

Greptile assigns every reviewed PR a risk level by reading the diff. The risk cap controls the broadest class of changes Greptile can approve.
  • Low: docs, tests, styling, and small code changes assessed as low-risk
  • Medium: ordinary application or business-logic changes
  • High: dependency updates, build or runtime config, and core shared modules
  • Critical: auth, secrets, billing, database migrations, infra or CI, and public APIs. At this level Greptile approves every change with a 5/5 review.
The risk level comes from what the code does, not from the file path. A change under a sensitive directory that the assessment judges low-risk can pass a Low ceiling. For paths that must always get a human approval, use excludePaths below. Start with Low. Raise the cap only after your team has seen enough auto-approved PRs to trust the behavior for that class of change.

​
Risk definitions

The Risk definitions box takes natural-language guidance for the risk assessment that gates auto-approve. Use it to tell Greptile how risky specific kinds of changes are in your codebase:
Instructions adjust the risk level a change is assigned. They can raise or lower it, but only when the diff actually contains that kind of change. The risk cap still decides what gets approved: an instruction that lowers a change to Low does nothing if auto-approve is off, and an instruction that raises a change to Critical blocks approval under any lower ceiling. Instructions are a dashboard setting for the whole organization or team. They are not read from .greptile files, so a PR cannot change them.

​
Filters

Filters — the Only certain PRs section in the dashboard — keep PRs out of auto-approval even when Greptile rates them as safe. Use filters for changes that need a human reviewer every time, such as:
  • Sensitive branches
  • Release or migration labels
  • Critical files or directories
  • Authors whose PRs need extra review
Add per-repo filters in your .greptile file. When both the dashboard and a .greptile file set autoApprove, the stricter value wins for every field.

​
Protect specific file paths

Use excludePaths to list paths that always require a human approval. A PR that touches any matching path is never auto-approved, even if the rest of the diff qualifies:
Entries are glob patterns or plain directory paths (a directory entry covers everything under it, like a CODEOWNERS rule). Renames count on both sides, so moving a file out of a protected path still requires human review.

​
Limit auto-approve to specific paths

Use includePaths to auto-approve only when every changed file matches one of the listed paths:
See the config reference for all auto-approve fields.

​
What always blocks auto-approval

Even with a 5/5 review inside the risk ceiling, Greptile withholds approval when:
  • The PR is a draft, closed, or merged by the time the review finishes
  • New commits landed after the review started
  • The PR carries a do-not-merge or manual-review label
  • The PR fails any of your regular review filters (branches, labels, authors, keywords)
  • The Confidence Score review section is turned off
Greptile’s approval reflects its own assessment. Human requested-changes reviews and unresolved discussions do not block it. Your repository’s merge rules still enforce any required human approvals, checks, and discussion resolution before merging. Greptile reads the auto-approve policy from the PR’s base branch. A PR that edits .greptile cannot loosen the policy for itself. When new commits are pushed to an approved PR, Greptile dismisses its earlier approval. The next review that passes every check approves again. A withheld approval is silent. Greptile does not comment to explain why it did not approve. On GitHub the approval itself has no comment. On GitLab and Bitbucket it carries a one-line note.

​
When to use it

Auto-approve is useful when the cost of waiting for a human review is higher than the risk of the change. Good candidates include docs updates, test-only changes, formatting, and small changes Greptile rates as low-risk. Do not enable it broadly across all PRs. It is meant to save time on low-risk changes while keeping normal review paths for everything else.