Complete Bugbot Review (2026)

Published Updated

BugBot is Cursor's pull-request reviewer for teams that want another pass over changed code before merge. It comments on potential bugs, security issues, and code-quality problems, then offers links that can send the finding into Cursor or Cursor's web agent.

Bugbot suits teams that want review findings close to Cursor's repair tools. The convenience is real; so is the cost of rerunning reviews on every push. Start with a few representative changes, then decide whether automatic review earns its place. Our AI code review tool comparison covers the alternatives.

BugBot at a Glance

Bugbot’s pricing and usage limits can change. Check your account dashboard for the terms that apply to you.

AreaCurrent PositionBuyer Check
Review methodPull-request diff analysisCross-file blind spots
TriggersAutomatic or commentSpend under automation
Billing unitUsage per runRuns each month
May 2026 estimate$1.00 to $1.50 average runYour own run costs
Effort levelsDeeper review costs moreRisk-based policy
RulesRepository BUGBOT.md filesRule scope and precedence

How Does Bugbot Review a Pull Request?

Cursor describes BugBot as a tool that analyses pull-request diffs, leaves explanations and suggested fixes, and can run automatically on each update or from a comment trigger. The documented manual comments are cursor review and bugbot run.

A finding should lead to a small investigation. Read the changed code and the caller or consumer it affects. Try to construct the state that would fail.

Check which cases the existing tests cover and which they miss. Then decide whether to fix, dismiss, or turn the observation into a repository rule. This is ordinary code review work, and BugBot only makes the possible failure easier to notice.

That distinction matters when a comment arrives with a confident explanation. A plausible comment can still miss a guard in another file or misunderstand a deliberate trade-off. Require the same evidence you would require from a human reviewer: a reachable path, a broken invariant, or a test that demonstrates the failure.

How Do You Set Up Bugbot?

BugBot connects through the Cursor dashboard and supports Origin, GitHub including Enterprise Server, GitLab including self-hosted installations, Bitbucket including Data Center, and Azure DevOps Services. Connect the provider with the required administrative permissions, then check which repositories have review enabled. GitHub connections can enable reviews for granted repositories automatically; the other providers need repository-level activation.

  1. Choose one repository with an active pull-request habit.
  2. Confirm which people and repositories BugBot can access.
  3. Start in mention-only mode while you assess the findings.
  4. Review results on several ordinary application changes.
  5. Enable broader automatic coverage only where findings justify it.

Use the first run to see which bugs Bugbot can find. Choose a pull request that changes authentication, data ownership, an external API, a migration or error handling. Small content edits and lockfile refreshes can wait.

These changes give Bugbot something useful to check.

I paused BugBot across my repositories on July 19, 2026 because of Cursor usage limits, and it is now back in our review workflow. Our team uses it alongside Codex and Claude Code across our projects. The pause is still a good reminder to check the dashboard's current allowance before turning on automatic reviews across a busy organisation.

How Do You Write Bugbot Review Rules?

Write Bugbot review rules in .cursor/BUGBOT.md files, naming the risky paths and behaviour the reviewer should check. Cursor says the root file is always included, and nested files apply when the review reaches their directory. This lets a repository state one project-wide invariant while giving an API directory its own security and validation guidance.

# .cursor/BUGBOT.md

- Check every write preserves the authenticated tenant boundary.
- Do not comment on generated clients under src/generated/.
- Flag a changed public API when its contract test is absent.

# src/api/.cursor/BUGBOT.md

- Trace authorisation before every database read and write.
- Check validation rejects unknown fields before persistence.

Name the unsafe operation and the evidence that would prove a defect. For tenant security, the boundary is the authenticated organisation, the operation is a database write, and the evidence is the authorisation path. Start with failures the team has seen and paths that are intentionally generated or experimental.

Rules can create noise when they restate broad preferences, contain exceptions nobody can test, or ask the reviewer to enforce an entire style guide. Remove a rule that repeatedly yields low-value comments. Add rules for concrete defects you can explain and reproduce.

A few specific rules are easier to maintain than a second style guide.

How Do You Run Bugbot Manually?

On a provider that supports comment triggers, run Bugbot manually by commenting bugbot run on a pull request after the implementation and tests are ready for inspection. Bitbucket Data Center supports automatic reviews only. Add verbose=true if troubleshooting is needed; Cursor documents verbose triggers for detailed logs and a request identifier.

Check a Finding Before You Fix It

A Bugbot comment needs a reachable failure, not just a plausible explanation. Read the affected function and its callers, check whether an existing guard prevents the problem, and reproduce the issue where practical.

If the finding is correct, fix it and add a regression test. If it is wrong, explain which check or requirement protects the code. Do not rewrite working code merely because a comment sounds confident.

Bugbot can hand findings to a coding agent for repair through Fix in Cursor links that open an issue directly in the editor and Fix in Web links that open the web agent. The handoff can save the context-switch of locating the file and copying the review comment. It does not remove the review step after a change has been proposed.

Check the finding and the proposed fix in this order:

  1. Confirm the finding describes a reachable defect.
  2. Send the finding to the chosen repair tool.
  3. Inspect the proposed diff before accepting any part of it.
  4. Add or adjust a test that proves the repaired behaviour.
  5. Request another review only when the fix changes the relevant path.

This keeps the convenience of an agent handoff without converting a review comment into an automatic code change. If the suggestion is wrong, dismiss it with a reason and return to the pull request. There is no need to open a repair task.

BugBot also offers optional Autofix, which starts a Cloud Agent and can push a repair according to your settings. That is a separate, write-enabled workflow from opening a Fix link. Autofix requires available usage and storage, uses Cloud Agent billing, and should leave the resulting patch subject to your normal checks.

How Much Does Bugbot Cost?

Bugbot charges usage against your account's available credit. Teams use prepaid credit, with on-demand spending retained on some legacy plans. Review effort, pull-request size and repeat runs affect the bill; Autofix adds Cloud Agent usage.

Cursor estimated US$1.00 to US$1.50 per run in its May 2026 announcement. That historical average is not a current fixed price. Use the dashboard's actual charges when setting a budget.

Low, Default, High and Smart effort let you choose how much work a review does. Higher effort can help on a difficult change, but it should earn the extra spend through useful findings.

Set a Budget Before Automatic Review

Choose mention-only, once-per-pull-request or automatic review to match your update frequency. A busy branch can trigger several reviews before the author has finished a single fix.

  • Set a spending limit and name the person who can change it.
  • Track review effort, reruns, confirmed defects and time spent dismissing incorrect comments.
  • Before raising the cap, check which repositories and triggers caused the unexpected bill.

The review trial method gives you a consistent way to compare those costs with the value of the findings.

What Are Bugbot’s Main Limitations?

Bugbot can miss defects, raise incorrect findings and generate variable usage costs. Its repair options also differ between source-control providers. Autofix can create a new branch or commit to the existing branch on GitHub and Origin; GitLab and Bitbucket Cloud support existing-branch fixes. Bitbucket Data Center supports automatic review only on Teams and Enterprise, without comment triggers or Autofix; Azure DevOps also has no Autofix. Check permissions, review settings and billing for your provider before enabling it.

Keep responsibilities clear. A human reviewer owns the merge decision. Tests and static checks remain separate gates.

Judge Bugbot by the real problems your team fixes after reading its comments. For more configuration options, read the CodeRabbit guide. For another codebase-context approach, read the Greptile guide.

My Verdict

Choose Bugbot if your team uses Cursor and can track what each review costs. Use it on code where a bug would matter, write BUGBOT.md rules for failures that can actually occur, and cap automatic spending in your account. If the cost stops you running the reviews you need, compare another tool.

Frequently Asked Questions

Is Bugbot included with Cursor?

Bugbot uses Cursor usage-based billing, so a Cursor subscription should not be treated as unlimited Bugbot review access. Teams draw from prepaid credit or legacy on-demand spending. Check your account allowance and spending controls before enabling automatic reviews.

Does Bugbot review every pull request?

Bugbot reviews pull requests according to the enabled repositories and trigger settings. Automatic review, mention-only review and once-per-pull-request modes provide different coverage. Check those settings before assuming a new pull request will receive a review.

Sources

  1. [1]
  2. [2]
  3. [3]
    Cursor pricing
    (cursor.com)