Cursor Approval Agents: Auto-Approve PRs and Route Reviewers

You configure PR Routing & Approval in Automations. It runs on your pull requests and does two jobs, which you turn on separately.

Both jobs also weigh applicable policy files, risk settings, AI reviewer findings and the current review state. The agent must have at least one primary action enabled, Request Reviewers or Approve PR, so there is no watch-only mode. The closest setup is reviewer assignment on and automatic approval off. The agent still weighs every PR in scope against your criteria and policy files, but it requests a reviewer instead of approving. Read a few weeks of its routing before you turn approval on.

It runs on the pull request events you turn on. You can scope triggers to repositories or organizations, and for team-owned repositories, team admins can configure broader team scopes.

With PR opened alone, the agent judges a pull request when it opens for review. Commits pushed after that aren't weighed against your criteria. PR pushed / updated closes that gap, but then the agent runs again after every push, which on an active branch can mean many runs a day.

PR commented gives you a manual re-run, because you write its regex. Someone posts the phrase you chose, and the agent evaluates the pull request again. Choose a phrase nobody types by accident.

Start at the repository scope. On a repository you know, you can predict what the agent should decide and check its calls against your own review habits. An organization-wide trigger reaches repositories whose review conventions nobody wrote down, and your criteria apply to all of them anyway. Widen the scope once the criteria have held up on one repository.

Beyond your written criteria, the agent can pull in findings from Cursor's other review systems and classify the PR by risk. Any of these signals can stop an approval.

Turning on either review context changes when the agent decides. It waits for those reviewer checks to finish on the PR's latest commit, for up to about 8 minutes. If a check still hasn't finished by then, the agent doesn't approve the PR. With PR pushed / updated on, the next push runs the agent again.

A check that never ran on the latest commit doesn't hold the decision up. If a reviewer hasn't started a check there, or skipped it, the agent decides without that reviewer's findings.

Maximum Risk for Approval is the setting that carries the trade-off, and Cursor's docs describe the mechanism without suggesting a level. Set it tight, and the agent spends its time assigning reviewers, so your reviewers keep roughly the queue they had. Set it loose, and you hand over calls you were making by feel. To pick a level, go through a month of merged PRs and note which ones a reviewer read closely.

The agent reads policy files committed to your repository before it decides. For each changed file, it checks that file's directory and every ancestor directory for an exact filename match, and it trusts only the exact basename.

APPROVAL_POLICY.md

Case and suffix both count, so the files that get skipped tend to look like the real thing. POLICY.md, approval_policy.md, APPROVAL_POLICY.md.bak and team_APPROVAL_POLICY.md are all ignored during directory policy discovery.

The closest applicable APPROVAL_POLICY.md has the highest priority for files under its directory. Ancestor policies still apply unless they conflict with a more specific policy.

The exact-name rule is the easiest one to break by accident. A directory picks up approval_policy.md, someone assumes the folder is governed, and discovery skips the file. Cursor's docs don't mention a warning when a file is skipped, so the check is yours to run. Until someone notices, the agent ignores the policy you wrote and judges those files by your generic criteria and any ancestor policy.

You need one when your policy boundaries stop matching your folder tree. Alongside directory discovery, the agent checks for a single top-level routing file.

.cursor/approval-policies/ROUTING.md

Each entry carries a product name, a boundary (a semantic boundary or an explicit path or glob) and policies pointers, given either as file paths or as semantic descriptions. If the routing file is missing, directory discovery still runs, and missing routing doesn't weaken policy discovery.

For a repo with one clear owner, skip routing and put a single APPROVAL_POLICY.md in the directory that worries you most. Routing is for the other kind of repo, where one product spans four directories or two products share one. Because boundary accepts a semantic boundary as well as a path or glob, you can name an area that has no single folder.

Applicable policy prompts override your generic approval criteria, risk thresholds, reviewer-selection guidance, custom approval instructions and the default automated-review posture. When policies conflict, the agent follows the most specific one. If specificity is unclear, it follows the stricter instruction and avoids auto-approval.

Because policy files win, write them first, for the areas that have real rules. Then write the custom prompt for everything no policy covers. Each policy you add later overrides the prompt for the files it covers, so a prompt written first ends up governing less than its wording suggests.

Cursor's docs don't say how a newly added policy file counts. We treat adding one as changing one, so plan the PR that introduces your first APPROVAL_POLICY.md as a human review.

You set it up on the PR Routing & Approval page in Automations. There you choose when it runs, which signals it trusts and what it is allowed to do.

1. 1Turn on the capabilities you want (reviewer routing, automatic approval or both), then choose the organizations and repositories where the agent should run.
2. 2Choose the pull request events that trigger the agent, scoped to repositories or organizations.
3. 3Turn on the review signals you need: BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. Review Context, Security Review Context, Risk Score and a maximum risk for approval.
4. 4Write a custom prompt with your team's approval criteria and the cases that require human review. Policy files still take precedence.
5. 5Enable at least one primary action, Approve PR or Request Reviewers, plus optional Slack or Microsoft Teams notifications and MCPModel Context Protocol. A standard that lets an AI agent pull in context from outside the repo, like Jira tickets or internal docs. Press Enter for the full definition. servers.
6. 6Save the agent. You can enable or disable an existing agent from its detail page.

Scope the first agent narrowly, to one repository. Pick the one with the most routine pull requests, because you are testing whether your written criteria match the calls your reviewers already make, and that test needs volume. The repository everyone is watching comes later.

Who can edit the agent depends on the plan. On Team plans, every team member can create and edit PR Routing & Approval. On Enterprise plans, only team admins can edit it, and other members can view it. A member who can't edit the agent can still commit an APPROVAL_POLICY.md next to their own code, and that file outranks the criteria an admin wrote.

Check the maximum risk threshold first, then look for findings that are still open, then check whether a reviewer check ran out of time.

Each of those is documented behavior. A PR over the threshold doesn't get approved, and neither does one where BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. or Security Agents reported findings that need human review. A reviewer check that hasn't finished when the wait ends also blocks approval. The fix is to raise the threshold, clear the finding or re-run the agent once the check is done.

Policy conflicts produce a quieter version of the same symptom. Two policies that disagree, with no clear winner on specificity, resolve to the stricter instruction and no auto-approval, which looks like a broken agent from the outside. Before you touch the configuration, find every APPROVAL_POLICY.md on the path to the changed file, ancestors included, and read them together.

Approving too much has different causes. First confirm that an exactly named APPROVAL_POLICY.md sits on the path of the files that changed. Then check whether BugbotCursor's automated PR reviewer that posts inline findings and can push fix commits from isolated VMs. Press Enter for the full definition. and Security Agents ran on the PR's latest commit, because the agent decides without a reviewer's findings when that reviewer skipped the commit or hadn't started its check. When Bugbot runs only once per PR, it skips every commit after its first review. If all of that looks right, find out whether anyone wrote a custom prompt; without one, Cursor's default criteria decide.