Cursor Bugbot

My take: Bugbot belongs on your shortlist when your team wants PR findings connected to Cursor's fixing workflow. Keep human approval and your existing automated checks. On Azure DevOps, evaluate the reviewer on its own merits because Bugbot Autofix is unavailable there. On GitLab and Bitbucket, decide whether allowing fixes directly on the PR branch suits your workflow before enabling Autofix.

What Cursor Bugbot Checks

Bugbot looks for bugs, security issues and code-quality problems in a pull request's diff, the changes proposed for merging. Think of it as an inspector examining a renovation: the changed work is the starting point, and your repository rules supply the building's local requirements.

Reviews can run on PR updates or when someone comments cursor review or bugbot run. Existing top-level and inline PR comments provide context, helping Bugbot account for earlier feedback. Findings include explanations and fix suggestions, with links to continue in Cursor or on the web. How Bugbot works.

The practical payoff is earlier attention to a defect that might otherwise survive review. A comment count is not a measure of that payoff. Judge the findings by whether they identify a real failure, explain when it occurs and lead to a useful correction. Keep tests, security scanning and ownership review in place.

Set Up Bugbot for Each Repository

Connect your source-control provider through the Cursor integrations dashboard, then open Bugbot in Automations and enable the repositories you want reviewed. Connection and repository enablement are separate steps. Cursor's setup supports GitHub, GitLab, Bitbucket and Azure DevOps Services, including the documented self-hosted variants of the first three. Bugbot setup.

GitHub

You need Cursor admin access and GitHub organization admin access. In Integrations, choose Connect beside GitHub, or Manage Connections if connected already. Select All repositories or Selected repositories, complete the connection, then return to Cursor and enable the chosen repositories in Bugbot. GitHub Enterprise Server has its own setup tab and networking guidance. Cursor's GitHub integration.

GitLab

For GitLab.com, you need Cursor admin access, GitLab maintainer access and a paid GitLab Premium or Ultimate plan. Cursor requires project access tokens that GitLab Free does not provide. In Integrations, choose Connect or Manage Connections, complete the GitLab installation, then use Manage → Sync Repos before enabling repositories in Bugbot. Self-hosted installations have separate connection instructions. Cursor's GitLab integration.

Bitbucket

Bitbucket Cloud is currently a public beta. Connect your account from Integrations and authorize Cursor. The workspace also needs the Cursor app: a Bitbucket workspace admin opens the Bitbucket manage menu in Cursor, chooses Install Cursor app, and installs it in the workspace. A Cursor team admin with workspace access then opens Forge Apps → Cursor in Bitbucket workspace settings, selects Connect to Cursor, and links the team. Enable the repositories in Bugbot afterward. A personal account connection alone does not establish the app identity for review comments. Bitbucket Data Center uses a separate setup path. Cursor's Bitbucket integration.

Azure DevOps

Use the Bugbot-specific setup for Azure DevOps Services. It requires Microsoft Entra tenant admin consent. A Project Collection Administrator connects Azure DevOps and turns on Bugbot for a repository, which provisions Cursor's service principal, an application identity in your organization. A project administrator must add that identity to Project Administrators for each project being reviewed so it can manage service hooks, the notifications that trigger reviews.

Permission changes can take time to propagate; resolve any setup error and retry the repository toggle. Bugbot supports team repositories, not personal-scope repositories. Cursor's Azure DevOps Bugbot setup.

Choose the Review Behavior

For each enabled repository, decide whether to review updates or run only once per PR, and configure any author allow/deny lists. Personal settings can make an author's reviews mention-only, once per PR, or include drafts. Bugbot can review contributors outside your Cursor team on enabled repositories. Repository and personal settings.

Azure DevOps has an extra manual-trigger condition: the commenter's Azure DevOps sign-in address must match a Cursor account on the repository's owning team. Automatic reviews do not have that restriction. Azure DevOps triggers.

The Exact .cursor/config/bugbot.yaml File

Store review behavior in the repository when you want changes to it to go through code review. This is the example published in Cursor's repository configuration documentation:

# .cursor/config/bugbot.yaml
version: 1

triggers:
  drafts: false
  frequency: everyPush # everyPush | oncePerPr

review:
  effort: default # low | default | high | smart
  smartPrompt: ""
  incremental: true

prSummary:
  mode: comment # disabled | description | comment
  riskScore: true

autofix:
  mode: disabled # disabled | newBranch | existingBranch

Commit and push the file at that path from the repository root. Bugbot reads it from the PR's base branch, the branch receiving the changes. It does not use the version on the PR's head branch, so a proposed change cannot rewrite its own review configuration. Use CODEOWNERS, the repository's file-ownership mechanism, to control who reviews configuration changes.

All fields are optional. Missing or invalid fields fall through to the next source of settings; files larger than 64 KB are ignored. The priority is:

1. The PR author's personal overrides for their own PRs.
2. The repository YAML file.
3. Team and organization dashboard settings.

That order matters: checking the YAML alone does not prove which settings an author will get. Also, autofix.mode can reduce what the dashboard permits, but cannot turn Autofix on when the dashboard has disabled it. Configuration behavior and precedence.

The example selects a summary comment; it is not a list of every dashboard default. Without that override, PR summaries default to the description. Incremental review examines changes since the previous Bugbot review. Higher effort can spend more time and usage looking for bugs; Smart lets your instructions determine the effort level. Summaries, incremental reviews and effort.

Put Review Instructions in BUGBOT.md

Use .cursor/BUGBOT.md for the knowledge a reviewer needs about your project. The root file is always included. Bugbot also finds nested .cursor/BUGBOT.md files by walking upward from changed files, so a backend directory can carry instructions that differ from the frontend's. Cursor editor rules in .cursor/rules/*.mdc do not apply to Bugbot. Bugbot project rules.

A useful rule names an invariant and the failure to watch for. For example, a payments team could describe its requirement that retrying an operation must not charge a customer again. A backend team could explain which state transitions require an audit entry. These are suggested rule topics, not promises that Bugbot will detect every violation.

Team rules, project rule files, learned rules and manual repository rules are combined. Dashboard learned and manual rules require learning to be enabled for the organization and repository. Keep instructions focused: each rule is truncated at 30,000 characters, and the combined review rules are capped at 100,000 characters. To inspect what actually loaded, comment bugbot run verbose=true or cursor review verbose=true; the response identifies included, truncated or omitted rules. Rules and limits.

How Bugbot Bills Now

Budget Bugbot as usage, with Autofix accounted for separately. Cursor's current wording is:

Those are the current Bugbot billing terms. Do not assume a team's editor allowance pays for Bugbot reviews. Autofix consumes Cloud Agent credits, charged at your existing plan's rates. Autofix billing.

The May pricing change applies to existing subscriptions at their next renewal after June 8, 2026, so a legacy annual subscription may remain on its prior terms until renewal. Cursor's pricing-change announcement.

There is no fixed per-review tariff to substitute into your budget from the current Bugbot docs. PR complexity, review frequency and effort affect the work being done. Treat a provider's average run cost as context, not a guaranteed rate for your repository.

For the business case, compare review spend + Autofix spend + engineer time assessing findings with the review and rework effort the team avoids. Your existing human-review budget remains. The decision turns on useful findings and attention saved, not whether another bot can produce comments.

Autofix and MCP Have Different Requirements

Autofix starts a Cloud Agent, an agent that works on the code remotely, to address Bugbot findings and report back on the PR. It requires on-demand usage to be enabled and storage to be enabled; Legacy Privacy Mode does not meet that storage requirement. Choose a supported mode in Bugbot Automations. Autofix requirements.

These are Cursor's documented Autofix modes. Existing-branch mode permits at most 3 attempts per PR to prevent loops. My starting recommendation is to leave Autofix off until your team agrees how to review generated fixes; GitHub teams can then choose the new-branch mode to inspect them separately.

MCP, a protocol that gives an AI tool access to other tools and context, can extend Bugbot's review process. Configure the MCP server and add its tools to Bugbot in Automations. Bugbot MCP support is only on Team and Enterprise plans. MCP availability.

Bugbot vs CodeRabbit vs Greptile

Choose by workflow fit and the cost model you can manage. These are published prices, not results from a comparative test.

Sources: Cursor Bugbot, CodeRabbit pricing, Greptile pricing. CodeRabbit's annual amounts are monthly equivalents under annual billing. Greptile credits are not interchangeable with Cursor usage or CodeRabbit's reviewed-file charges.

The budgeting comparison is straightforward: CodeRabbit adds a seat subscription and potential continued-review charges; Greptile combines seats with credits; Bugbot's current model makes review usage the central variable. No honest comparison can declare the cheapest option for your team from seat prices alone.

For the closer head-to-head, read Greptile vs CodeRabbit. For a wider shortlist, use CodeRabbit Alternatives and Best AI Code Review Tools for Small Teams.

Where a Team Could Get the Most Value

I would prioritize workflows where a missed defect costs more than the attention required to assess a finding. These are possible uses, ranked by where I would start, not measured outcomes.

The review, context, rules and Autofix mechanisms behind these examples are documented in Cursor's Bugbot guide. Their value depends on your code and reviewers.

What Is Worth Building Around Bugbot

The strongest opportunity is helping an engineering lead understand review cost and outcomes. Another comment generator is a harder proposition when review already comes from established tools.

A Review Cost and Outcome Ledger

A platform team could build a dashboard connecting repository spend to findings that engineers accepted, dismissed or fixed. Engineering leads would be the buyers. Greptile's $30/seat/month Pro price is evidence of an established paid review category, not proof that those customers would pay for this add-on. Greptile pricing.

The smallest useful version would combine findings and billing records with a human usefulness label. Cursor's Enterprise review API exposes review analytics, including findings and billed cost; the cost field may contain no billed amount. A non-Enterprise version would need approved manual inputs rather than assuming access to that API. Bugbot API and analytics.

The catch: resolved comments are an imperfect proxy for valuable bugs, and incomplete billing attribution can make a dashboard misleading. I would build this first because it answers the recurring renewal question: is this reviewer worth its total cost?

A Repository Review-Policy Auditor

A platform engineering group could use a tool that checks repositories for approved Bugbot configuration, missing project rules and unreviewed policy changes. CodeRabbit Team's $60/developer/month monthly price places team review operations in a paid product category; willingness to buy a separate policy tool would still need validation. CodeRabbit pricing.

The smallest version could read repository files and produce a report for owners to review. The catch: personal settings outrank YAML, so a file audit alone cannot certify the effective review behavior. Keep that limitation visible and bring dashboard settings into the process where authorized access permits. Bugbot configuration precedence.

Keep Merge Approval Explicit

A required Bugbot check does not automatically mean unresolved findings block the merge. Findings produce a neutral result by default. Requiring the status ensures the check runs; when available for your organization, fail-on-unresolved-issues changes findings into a failing status. Review that setting before relying on branch protection. Bugbot check statuses.

My recommendation is to use Bugbot as additional evidence for the reviewer. A clean report does not demonstrate that the feature meets its requirements, and an automatically generated patch still needs the same scrutiny as other code.

Your Monday Move

Pick a repository whose owners can define the failures they want caught. Have the relevant administrator complete the provider connection, enable Bugbot for that repository, commit the configuration to the base branch and write focused review rules. Name the budget owner and keep Autofix a separate decision. Use normal review work to record useful findings, dismissed suggestions and time spent assessing both before extending the rollout.

If you need review reporting or repository controls built into your delivery workflow, we can help with AI automation.