Cursor Bugbot Setup 2026: AI PR Review, Learned Rules & Autofix for Teams

Last updated: June 7, 2026

Cursor Bugbot is Anysphere's AI code reviewer. It plugs into your GitHub pull requests and leaves inline comments on logic bugs, edge cases, and standards violations — directly in the PR, where your team already reviews. The fastest way to get real value from it is not "turn it on and hope." It is three concrete moves: connect the repo, make the Cursor Bugbot status check a required pre-merge gate via branch protection, and encode your team's standards as Bugbot Rules so the reviewer knows what your organisation actually cares about.

This guide walks through the setup end to end, explains how learned rules and Autofix close the review loop, and shows Indian enterprise and BFSI teams how to turn Bugbot into a governance tool — not just a bug finder.

Key Takeaways

• Bugbot reviews PRs inside GitHub and is tuned for a low false-positive rate — it optimises for flags that get fixed, not flag volume.
• Make it a required status check. Branch protection requiring the Cursor Bugbot check turns it from "nice comments" into a real pre-merge gate.
• Bugbot Rules are a separate layer from .cursor/rules. Rules steer the reviewer; .cursor/rules steers the coding agent.
• Learned rules self-improve per repo from your downvotes, replies, and missed-issue feedback — Cursor reports that well over a hundred thousand repos have collectively generated tens of thousands of learned rules.
• Autofix proposes fixes you can pull into the Cursor editor or hand to a Background Agent; Cursor reports that a meaningful share of Autofix changes get merged into the base PR.
• It augments, never replaces, human review — keep a named human approver, which matters doubly under RBI/SEBI/IRDAI accountability expectations.

What Bugbot Is

Bugbot is the PR-review product from Anysphere, the company behind the Cursor editor. When a pull request opens (or you comment bugbot run or cursor review), Bugbot analyses the diff and posts inline comments where it finds real problems: off-by-one errors, missing null checks, race conditions, broken error handling, secrets in code, or deviations from your stated conventions.

The design philosophy that matters for teams is low false positives. A reviewer that cries wolf gets muted; Bugbot is tuned so that a flag usually means something worth fixing. Cursor's own reported numbers back this up:

• The resolution rate — the share of flags fixed before merge — has risen substantially since the out-of-beta launch; Cursor reports it now sits in the high-70s-percent range, up from roughly half at launch.
• Cursor states Bugbot reviews PRs at very large scale (millions of PRs per month); treat that as a Cursor-reported figure rather than something you should assert as independent fact.

Treat all of these as vendor-reported metrics. They are useful directional signals, not benchmarks you can independently verify, so cite them as "Cursor reports…" in any internal decision doc.

Step-by-Step: GitHub PR Integration

Bugbot's first-party integration is GitHub only as of mid-2026 — there is no native GitLab or Bitbucket support. If your organisation runs GitLab self-managed (common at Indian banks and PSUs), confirm that before you plan a rollout.

1. Sign in to the Cursor dashboard with an account on a plan that includes Bugbot (Teams or Individual usage-based plans).
2. Connect GitHub. Install the Cursor GitHub integration / app and grant access to the specific repositories you want reviewed — start with one or two, not the whole org.
3. Enable Bugbot per repository from the Bugbot section of the dashboard. Once enabled, Bugbot automatically reviews new PRs and leaves inline comments.
4. Trigger a manual review to test it: open a PR and comment bugbot run (or cursor review). You should see Bugbot pick up the diff and respond.
5. Tune effort. On usage-based plans you can set the analysis depth — Default (efficient, fewer/cheaper findings), High (extended reasoning, more findings, higher cost), or Custom (adjusts to your instructions). Use Default for routine PRs and High for risky areas like payments, auth, and migrations.

Making Bugbot a Required Pre-Merge Check

By default a Bugbot finding posts a neutral conclusion — the PR can still merge even with open comments. To make it a real gate:

1. Go to your repository's Settings → Branches and add or edit a branch protection rule for your default and release branches.
2. Enable Require status checks to pass before merging and select the Cursor Bugbot check.
3. If your organisation has the option, enable fail on unresolved issues so Bugbot returns a failing (not neutral) status when serious findings remain open — that is what actually blocks the merge button.
4. Pair this with Require a pull request before merging and at least one human approval. Bugbot becomes the automated first pass; the human approval remains the accountable sign-off.

This combination is the difference between "Bugbot leaves helpful comments people skim past" and "no code merges to main until Bugbot has reviewed it and a human has approved."

Writing Bugbot Rules for Team Standards

Bugbot Rules are a distinct layer from the .cursor/rules directory. The .cursor/rules convention (which replaced the legacy single .cursorrules file) steers the Cursor coding agent while you write code. Bugbot Rules steer the reviewer during PR analysis. Keeping them separate means you can run a strict review policy without changing how your agent generates code.

Bugbot applies rules hierarchically:

• Team Rules — created in the Bugbot dashboard, applied organisation-wide. Good for company-wide non-negotiables.
• Repository Rules — managed per repo, including learned rules. Good for service-specific conventions.
• Project Rules — stored in .cursor/BUGBOT.md at the repo root (and nested directories, traversed upward from changed files). Version-controlled, reviewable in PRs, and the right home for rules engineers should see and edit.

A starter .cursor/BUGBOT.md for a backend service might say:

# Bugbot Review Rules

- Flag any SQL built by string concatenation; require parameterised queries.
- Flag new endpoints that lack authentication or authorization checks.
- Flag logging of PII (PAN, Aadhaar, account numbers, phone, email) in plaintext.
- Flag money handled as float/double; require integer paise or a decimal type.
- Flag catch blocks that swallow exceptions without logging or rethrowing.
- Require new public functions to have corresponding tests in the diff.

Write rules as crisp, testable assertions. Vague rules ("write clean code") produce vague reviews; specific rules ("money must not be a float") produce specific, actionable flags.

Learned Rules: How Bugbot Self-Improves

On top of the rules you write, Bugbot generates learned rules per repository. It turns live review feedback into candidate rules using three signals (per Cursor's 2026 learned-rules announcement):

1. Downvotes on a Bugbot comment — a signal the finding was not useful.
2. Replies to a Bugbot comment — developers explaining what was wrong or how the suggestion could improve.
3. Comments from human reviewers — flagging issues Bugbot missed.

Bugbot evaluates candidate rules against incoming PRs, promotes ones that prove effective to active status, and disables ones that generate consistent negative signal. You can also edit or delete learned rules from the dashboard. Cursor reports that since the beta, well over a hundred thousand repos have enabled learning, collectively generating tens of thousands of learned rules (treat these as Cursor-reported figures, not independently verified counts).

The practical takeaway for a team: be deliberate with feedback. Every downvote and reply is training signal. Tell your reviewers that thumbs-down and short explanatory replies are not just venting — they measurably shape next month's reviews. Still author explicit Bugbot Rules for the things you cannot afford to leave to inference: security and compliance.

Autofix: Closing the Loop

Bugbot Autofix goes beyond comments. It spawns cloud agents that work in isolated VMs to produce proposed fixes for issues it flags. Per Cursor's reported numbers, a meaningful share of Autofix changes get merged into the base PR.

Crucially, the fix does not stay locked in the PR. Cursor states Bugbot "provides fixes directly in your Cursor editor or through our Background Agent" — so a developer can pull a proposed fix into their editor to refine, or hand it to a Background Agent to carry out, rather than retyping it. A Fix All action lets you apply multiple proposed fixes at once.

For teams, the right mental model is: Bugbot flags, optionally proposes, a human decides. Autofix is a jumpstart, not an autopilot — review every proposed change before it merges, especially on regulated code paths.

Where Bugbot Fits in the Cursor Platform

Bugbot is one part of Cursor's broader agent-first toolchain — the editor, the coding agent, Background Agents, and the reviewer all share context. The useful boundary to hold in your head: the agent writes code (steered by .cursor/rules), and Bugbot reviews it (steered by Bugbot Rules / .cursor/BUGBOT.md). You can adopt Bugbot for PR review even if your developers use other editors, because the review runs server-side against the GitHub PR. Avoid over-claiming a specific Cursor version number when you brief stakeholders; the durable facts are the GitHub PR integration, the two separate rule layers, learned rules, and Autofix.

Enterprise and India Angle: Governance for BFSI and Offshore Teams

For Indian IT services firms and BFSI (banking, financial services, insurance) engineering teams, Bugbot's biggest value is governance, not just bug-catching.

Encode compliance-relevant patterns as Bugbot Rules

Bugbot has no built-in regulatory module — but you can author Rules that encode the technical patterns your compliance posture requires. For example, a fintech regulated by the RBI, SEBI, or IRDAI might write Bugbot Rules such as:

• Data handling / DPDP and sectoral norms: flag plaintext logging or external transmission of PII and financial identifiers (PAN, Aadhaar, account numbers); flag PII leaving approved data stores.
• Auditability: flag changes to transaction or ledger code that remove audit-trail writes.
• Localisation: flag new external service calls in payment paths that could route regulated data outside approved boundaries (then verify manually — Bugbot flags the pattern, humans confirm the policy).
• Contractual / data-handling checks: flag third-party SDK additions or data-sharing calls that should trigger an Indian Contract Act / DPA review before merge.

Frame all of these as example custom Rules your team authors, reviewed by your security and legal stakeholders — not as features Bugbot ships. The accuracy point matters: Bugbot enforces patterns you define; it does not certify regulatory compliance.

Solve the review-bottleneck for distributed and offshore teams

Many Indian enterprises run large, distributed, multi-timezone teams where senior reviewers are the bottleneck — a PR raised at 9 PM IST may wait for a US-morning reviewer. Bugbot gives every PR an immediate first-pass review regardless of timezone, so by the time a human reviewer arrives, the obvious issues are already flagged (and often Autofix-proposed). For a 200-engineer delivery centre, that can shift senior reviewers from triage toward architecture and intent.

A sane rollout: pilot on one or two repos, make the Cursor Bugbot check required only on release branches first, seed .cursor/BUGBOT.md with your security and money-handling rules, instruct reviewers to downvote and reply so learned rules improve, and keep a named human approver on every merge for accountability. Expand once your false-positive rate on those repos feels acceptable.

The Honest Limits

Be clear-eyed in your decision doc:

• It does not replace human review. Keep the human approver; do not let Bugbot's approval be the only sign-off.
• It is GitHub-only for first-party integration as of mid-2026.
• Pricing is in transition — formerly ~$40/seat/month, moving to usage-based (Cursor has cited ~$1.00–$1.50 per run) at renewals after June 8, 2026. Confirm current numbers before budgeting.
• Vendor metrics are vendor metrics. The resolution rate (Cursor reports the high-70s percent), the Autofix-merge share, the monthly PR volume, and the repo / learned-rule counts cited here are all Cursor-reported and deliberately kept qualitative in this guide. Use them to set direction, then measure your own resolution rate after a month.

Set up correctly — required status check, explicit Bugbot Rules, feedback-driven learned rules, and human approval kept in the loop — Bugbot becomes a governed, low-noise first pass that genuinely reduces the load on your senior engineers without pretending to be them.