Auto approvalbeta
Skip human review on clean, low-risk pull requests when your rules allow.
Auto approval lets a clean, low-risk pull request move without waiting for a human. When a review finds nothing and the pull request passes the rules you set, Angada can clear it so docs, test-only, and small config changes stop queuing behind the work that needs a human.
Auto approval is in private beta and available on paid plans (Pro and Enterprise). Live approval is coming soon. Today you run it in shadow to validate your rules. Contact Angada support to request access.
How it works
A pull request is eligible for auto approval only when two things are true: the review is clean, and the pull request passes your filters.
Angada weighs these in order. Each check can withhold approval on its own, and the first few run before your filters are ever considered:
- The review must not be degraded. A review that could not complete normally never auto-approves.
- There must be no open findings. Any unresolved finding withholds approval.
- The pull request must not edit a review-policy source. A change that touches the configuration that governs reviews withholds approval, so a pull request can never relax the rules that gate itself.
- Change metadata must be verifiable. If the changed-file list is missing or truncated, Angada cannot confirm what the pull request touches and withholds approval.
- The pull request must pass your filters. Only now are your include and exclude rules weighed.
If every check passes, the pull request is one Angada would approve.
Behavior modes
Auto approval has three modes. You choose how far it goes.
| Mode | What happens | Status |
|---|---|---|
| Disabled | Nothing is auto-approved. | Default |
| Shadow | Angada records what it would approve; nothing is posted. | Available |
| Live | Angada posts a real approval on the pull request. | Soon |
Live approval is not available yet. Run auto approval in shadow first — it records every decision so you can confirm your rules behave the way you expect before any approval is ever posted.
Set it up
- Open Settings → Review.
- Set the auto-approval behavior to Shadow.
- Add your include and exclude filters across the dimensions below.
- Open some pull requests and watch the shadow records to see what each decision would have been.
- Switch to Live when it becomes available.
Filters
Filters decide which pull requests may qualify once a review is clean. Each of six dimensions has two sides:
- Only approve when… — an include rule the pull request must satisfy.
- Never approve when… — an exclude rule that withholds approval on a match.
The six dimensions are paths, authors, head branch, base branch, labels, and title.
| Example rules | Filter result |
|---|---|
Include path docs/**; all changed paths are under docs/ | The pull request matches the include path rule. |
Include path docs/**; one changed path is outside docs/ | The pull request does not match the include path rule. |
Exclude path migrations/**; a changed path matches it | The pull request is excluded, even if an include rule matches. |
Exclude label dependencies; pull request label is Dependencies | The pull request is excluded, because label matching ignores case. |
Include author renovate[bot]; pull request author is Renovate[bot] | The pull request matches, because authors match case-insensitively. |
The rules behind those results:
| Rule | Semantics |
|---|---|
| Exclude beats include | If any exclude rule matches, the pull request is withheld regardless of include rules. |
| Exclude paths | Match when any changed path matches the rule. |
| Include paths | Match only when all changed paths match the rule. |
| Renames | Matched on both the old and the new path. |
| Paths, branches, title | Glob patterns, case-sensitive. |
| Labels | Matched exactly, case-insensitive. |
| Authors | Matched case-insensitively. |
What blocks auto-approval
A pull request is withheld when any of these hold, regardless of your filters:
- There are open findings.
- The review run is degraded.
- The pull request edits a review-policy source.
- The changed-file metadata is unverifiable or truncated.
GitHub branch protection still applies on top of this. An auto approval does not bypass required checks, required reviewers, or any other rule your repository enforces.
Protect sensitive paths
Use exclude rules to keep high-stakes changes in front of a human. A common starting set:
migrations/**— database migrations- authentication and authorization code
- billing and payments
- infrastructure and deployment configuration
Because exclude beats include, a pull request that touches any of these is withheld even when the rest of it would qualify.
Shadow records
In shadow mode, each pull request produces a record of the decision Angada would have made. A record shows the withheld reason and the rule that applied, so you can see exactly why a pull request would or would not have been approved, and tune your filters before you turn on live approval.
FAQ
For the rest of the review controls, see Review settings. To read what a clean review looks like, see Understand a review. For help, see Support.