Cursor Approval Agents: Auto-Approve PRs and Route Reviewers

An Approval Agent watches your pull requests and takes one of two primary actions, depending on whether the PR meets the criteria you set. You configure them in the Approval Agents dashboard at cursor.com/dashboard/approval-agents.

The dashboard requires at least one of those two actions to be enabled, and neither is passive. A watch-only mode, which is what I'd want too, isn't one of the two. Enabling Request Reviewers and leaving Approve PR off is the closest thing: the agent still weighs every PR in scope against your criteria and your policy files, and what lands on the PR is a reviewer instead of an approval. Read a few weeks of its routing before you hand it the other action.

It runs on the pull request events you turn on: PR opened, PR pushed or updated, and PR commented when the comment matches a regex you supply. Triggers are scoped to repositories or organizations, and on team-owned repositories a team admin can configure broader team scopes.

Turn on PR opened alone and the agent reads the pull request as it was created, then does not look at it again, so the commits that land afterwards are never weighed against your criteria. PR pushed closes that gap, though it also has the agent re-running on every commit anyone pushes, which on an active branch is most of the working day.

PR commented is the one you write yourself, since the regex is yours. It gives you a manual re-run: someone posts the phrase you chose and the agent evaluates the pull request again. Choose a phrase nobody types by accident.

Scope is where a small team and a large one diverge. One repository you already know is a scope you can predict, and the whole exercise stays inside your own review habits. An organization-wide trigger reaches repositories whose review conventions nobody ever wrote down, and your criteria get applied to all of them anyway. Start at the repository scope and widen it after the criteria have been tested somewhere.

Beyond your written criteria, the agent can pull in findings from Cursor's other review systems and classify the PR by risk. These signals act as gates: any one of them can stop an approval.

• 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 uses Bugbot findings in the approval decision.
• Security Review Context uses Security Agent findings (Security Agents require a team or enterprise plan).
• Risk scoring classifies the PR; a maximum risk threshold sets the highest level the agent may approve.

Enabling either review context changes the timing of the decision, which the list doesn't say outright. The agent waits for those reviewer checks to finish before it decides, so the approval arrives after 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 have run rather than when the PR opens.

Maximum Risk for Approval is the setting that carries the trade-off, and the docs describe the mechanism without naming a level to use. Set it tight and the agent spends its time assigning reviewers, leaving your reviewers roughly the queue they had. Set it loose and you have handed over calls you were making by feel. Picking a level probably starts with a month of merged PRs and which of them anyone actually read.

Approval Agents read policy files committed to your repository before deciding. For each changed file, the agent checks that file's directory and every ancestor directory for an exact filename match, and trusts only the exact basename.

APPROVAL_POLICY.md

Case and suffix both count, so the misses tend to look like the real thing.

POLICY.md, approval_policy.md, APPROVAL_POLICY.md.bak and team_APPROVAL_POLICY.md are all skipped during directory policy discovery. The closest applicable APPROVAL_POLICY.md takes priority for files beneath it, and ancestor policies still apply unless a more specific policy conflicts.

The exact-name rule is, I suspect, the one that bites first. A directory picks up approval_policy.md instead of the exact name, somebody assumes the folder is governed, and discovery skips it. Nothing in the docs promises a warning when a file is skipped, so the check has to be yours. Until someone notices, your generic criteria are deciding the files you wrote a policy for.

You need one when your policy boundaries stop matching your folder tree. Approval Agents check a single top-level routing file alongside directory discovery, and if that file is absent, directory discovery runs anyway. Routing is an addition on top of directory discovery, not a replacement for it.

.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.

For a repo with one clear owner I would skip routing and put a single APPROVAL_POLICY.md in the directory that worries you most. Routing earns its place on the other kind of repo, where one product spans four directories or two products share one. boundary takes a semantic boundary as well as a path or glob, so an area with no single folder can still be named.

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

That precedence decides the order you should write these in, and the intuitive order is backwards. Fill in the custom prompt first, add policy files later, and the policy takes precedence over the prompt for every file it covers. Write the policies first for the areas that have real rules, then let the prompt cover whatever has no policy of its own.

Adding a policy file counts as changing one, as I read it, so the PR that introduces your first APPROVAL_POLICY.md is a PR a person reviews. Plan that one as a human review.

You create and tune Approval Agents from the Approval Agents dashboard. New agents start with default pull request triggers and approval behavior; from there you configure when they run, which signals they trust, and what they are allowed to do.

1. 1Create an agent: choose New Agent, or use the onboarding card to create a Pull Request Approver.
2. 2Configure triggers: choose which pull request events the agent runs on, and scope them to repositories or organizations.
3. 3Configure review signals: enable 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 as needed.
4. 4Write a custom prompt with your team's approval criteria and the cases that require human review (policy files still take precedence).
5. 5Configure tools and MCPs: enable 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 and enable the agent; you can enable or disable existing agents from the detail page.

My instinct with a step list like that is to scope the first agent as narrowly as possible, one repository, and watch. Narrow holds up. The choice of repository does not: pick the one with the dullest pull requests, because what you are testing is whether your written criteria match the calls your reviewers already make, and that needs volume. The repository everyone is watching comes later.

Permissions decide where a large team's rules end up living. Someone without admin on the dashboard cannot edit an Approval Agent, though they can commit an APPROVAL_POLICY.md next to their own code, and that file outranks the criteria an admin wrote. On a five-person team none of this matters and the dashboard alone is fine.

Check the maximum risk threshold first, then check for findings that are still open.

An agent that approves nothing is usually doing what it was configured to do. A PR over the threshold does not 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 have reported findings that need human review. Both refusals are documented behavior, so the work is either raising the threshold or clearing the finding.

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 identical to a broken agent from the outside. Before you touch the configuration, find every APPROVAL_POLICY.md on the path to the changed file and read them together, ancestors included.

Approving too much runs the other way. Check whether an APPROVAL_POLICY.md was on the path for the files that changed, and whether the PR touched the policy that should have governed it. If both look right, check whether anyone ever wrote a custom prompt for that agent.