AI Code Review Tools That Approve Pull Requests, Compared

As of October 2026, at least five AI review tools document submitting a real GitHub APPROVE review: GitHub Copilot code review (approvals in public preview since 2026-09-01), Greptile (beta), cubic, Cursor's PR Routing & Approval and CodeAnt. They differ in three ways: what makes the bot approve, which changes it keeps out, and whether the approval satisfies your branch's required reviews. On that last point, most vendors leave the answer to your GitHub rules.

Everything below comes from each vendor's public docs as read in October 2026. Two of these features are labeled preview or beta, so check the linked pages before relying on a detail.

Side-by-side comparison

How each tool decides to approve

GitHub Copilot code review

Every Copilot review includes an approval assessment in its overview comment, saying whether Copilot considers the pull request ready to approve. GitHub's docs don't describe how Copilot reaches that judgment, and the assessment alone does not count toward merge requirements. By default Copilot leaves only Comment reviews.

Approvals need settings at three levels. The enterprise policy Allow Copilot to approve pull requests is disabled everywhere by default. Organizations decide whether Copilot approvals count toward merge requirements: everywhere, for selected repositories, or left to each repository. In the repository, one toggle lets Copilot submit approving reviews and a second lets those approvals count. The optional file-path field takes up to 15 globs, and an approval counts only when every changed file matches one. That is an allowlist for what counts, not a list of paths Copilot declines to approve. The changelog lists the Copilot Pro, Pro+, Max, Business and Enterprise plans.

Greptile

Greptile approves only a clean 5/5 review, read from the Confidence Score review section, on a pull request at or below your risk cap that passes your review filters. Its risk tiers are:

• Low: docs, tests, styling and small low-risk changes.
• Medium: ordinary business logic.
• High: dependency updates, build or runtime config, and core shared modules.
• Critical: auth, secrets, billing, database migrations, infra or CI, and public APIs.

With no cap the ceiling is Critical, so any 5/5 pull request can be approved. The docs recommend starting at Low.

It never approves a draft, closed or merged pull request, one that received commits after the review started, or one labeled do-not-merge or manual-review. Per-repository settings go in a .greptile file. When the file and the dashboard both set autoApprove, the stricter value wins for every field:

{
  "autoApprove": {
    "enabled": true,
    "riskCeiling": "low",
    "filters": {
      "excludePaths": ["src/auth/**", "db/migrations", ".github/workflows/**"]
    }
  }
}

cubic

cubic configures auto-approval per repository, with three behaviors: Disabled (comments only), Shadow (shows what it would have approved) and Live (submits approvals). The policy is Low-risk only (the recommended default), Custom (your own prompt) or Always (any clean review). By default any open cubic issue blocks approval, unless you allow open issues at priorities you choose. Under the Low-risk only and Custom policies, an approval agent "makes a fresh decision from the current PR diff"; under Always, cubic approves once no rule blocks approval. The agent sees the PR details, the diff, earlier decisions, and open or dismissed issues.

Never-auto-approve rules block on changed paths, author, head or base branch, labels or title. Only-auto-approve rules are an allowlist that every changed path must match. Never rules take precedence.

Cursor PR Routing & Approval

Cursor's agent assigns reviewers from code ownership and commit history and can approve low-risk changes. It decides from risk scoring, approval policy files, AI review agent findings, your configuration and the current review state. It won't approve a pull request above the Maximum Risk for Approval, or one where Bugbot or Security Agents report findings that need human review. Approval criteria come from a custom prompt or from Cursor's managed defaults, which the docs don't spell out. Policy files take precedence over the prompt.

For each changed file, the closest APPROVAL_POLICY.md in its directory or a parent directory has priority. When policies conflict and it isn't clear which is more specific, the agent follows the stricter instruction and doesn't auto-approve. A pull request that changes a policy or routing file is judged against the base-branch version, or sent to human review. The docs say the feature "does not replace a full code review."

CodeAnt

CodeAnt's Resolved comments mode approves once every thread CodeAnt opened is resolved; threads opened by people don't block it. A check runs 60 seconds after the review with the head SHA pinned, so a commit that lands during that minute cancels the approval. Policy agent mode runs after CodeAnt's threads are resolved and approves only when a model returns approve, reports no blockers, assigns a risk within your threshold (low, medium or high) and reaches at least 80% confidence. Its shadow mode posts the decision as a comment and never approves.

Policy rules live in .codeant/approval.json on the base branch, each with files, exclude_files and a decision. A matching human_review rule beats any allow rule, and human_review is the default decision. A pull request that changes .codeant/approval.json is never auto-approved. One with more than 300 changed files, more than 60,000 patch characters or a missing patch goes to a person.

Does the AI approval count toward required reviews?

Your GitHub rules decide. Branch protection can require approving reviews "from people with write permissions in the repository or from a designated code owner". It can also require each code owner to approve the code they own, and require the most recent push to be approved by someone other than the person who pushed it. GitHub's branch protection page doesn't say whether reviews from apps count.

The vendor docs say:

• Copilot: an enabled approval "satisfies your repository's required-approval rule the same way a teammate's approval would". The docs don't address code owner review.
• CodeAnt: counts as one normal review, but doesn't satisfy CODEOWNERS or requirements for specific users or teams unless the CodeAnt installation user is listed.
• cubic: "GitHub branch protection still applies, including required checks, required reviewers, and code owner rules."
• Greptile: "Your repository's merge rules still enforce any required human approvals, checks, and discussion resolution before merging."
• Cursor: not addressed.

After a new push:

• Copilot's approval is dismissed.
• Greptile dismisses its own earlier approval.
• CodeAnt says GitHub dismisses its approval like any reviewer's.
• cubic decides from the review of the latest commit.
• Cursor's page doesn't say.

Turn on GitHub's Dismiss stale pull request approvals when new commits are pushed so no approval outlives the diff it covered. Keep Require review from Code Owners on, with human teams owning auth, migrations and infrastructure. Then test in a sandbox repository whether the bot's approval satisfies your actual ruleset.

How Warpway's Auto-approve trust level differs

Warpway is a review orchestrator for GitHub pull requests. Lenses such as Correctness and Security investigate each change, and questions AI can't resolve go to a person as human tasks. Its highest trust level, Auto-approve, submits an APPROVE review only when every deterministic condition holds for the exact commit it reviewed. Code computes eligibility from stored review results immediately before approving. Warpway never approves because a model reported high confidence.

What Warpway checks before approving:

• It waits for the required review to finish. Every required lens must be Cleared. This is stricter than the merge gate: a lens whose findings are merely below the blocking severities doesn't count. No required lens may be Incomplete, no required human task may be open, and every required sign-off must be present.
• Findings from any lens block. No finding at a blocking severity may be open in any lens, including lenses set to warn or none.
• CI must succeed. Configured checks must conclude success (neutral and skipped don't count). No other check on the commit may be failing or still running, and every runtime verification run must have succeeded.
• Commit and policy are pinned. The head must be the reviewed commit, and the review must have used the base branch's current policy. Configuration always comes from the base branch, so a pull request can't loosen the rules that approve it.
• Exclusions fail closed. excluded_paths and excluded_categories block approval, and path rules fail if Warpway couldn't get the complete list of changed files. docs_tests_only is decided by file path, never by the change analysis.
• It withdraws only its own approval. If a later investigation demonstrates a material defect, Warpway withdraws its own approval of that head commit; if GitHub's protected-review permissions prevent that, the dashboard and check show that a repository administrator must dismiss it. It never dismisses a person's review.

version: 1
auto_approve:
  enabled: true
  docs_tests_only: true
  max_changed_lines: 300
  excluded_paths:
    - auth/**
    - migrations/**
  required_ci_checks:
    - unit-tests

Turning it on takes:

• the Team plan;
• an Owner enabling it for the organization and then for the repository;
• trust level 4;
• auto_approve.enabled: true in policy.

Every approval writes an audit event with the commit, the policy version and the result of each condition. Warpway never merges, and as with the tools above, your GitHub rules decide whether its approval counts. The auto-approval docs list all thirteen conditions.

The limits: Warpway works with GitHub only. The gate is deterministic, but whether a lens is Cleared comes from AI investigation. Semantic categories come from a model's change analysis, with code adding the ones file paths reveal, such as migrations. The trust-level docs suggest Auto-approve only for narrow, low-risk classes of change, such as documentation and test-only pull requests or small Dependabot updates.

Rolling out AI approvals

1. Pick one narrow class of change, such as docs and tests or dependency bumps. Greptile recommends starting at Low.
2. Watch before approving. The shadow modes in cubic and CodeAnt post the decision without approving, and Copilot's assessment appears in every review.
3. Put sensitive paths on the tool's deny list: Greptile excludePaths, cubic never-auto-approve rules, CodeAnt human_review rules, Cursor policy files or Warpway excluded_paths. For Copilot, keep the allowlist of paths that count narrow.
4. Turn on stale-approval dismissal and code owner review, then confirm in a sandbox how the bot's approval interacts with your ruleset.
5. Keep a required check in front of merges. For Warpway that is merge gating at Gate or above.

For what a person should still examine in agent-written changes, see How to review AI-generated pull requests.