What is Cursor Bugbot?

An automated pull request reviewer. It reads the diff, comments inline on bugs, security issues and code quality problems, and offers fixes that open directly in Cursor or in cursor.com/agents. It is configured from the Automations section of the Cursor dashboard.

How do I trigger a Bugbot review manually?

Comment either cursor review or bugbot run on the pull request. This also works when Bugbot is configured to review only when mentioned, which is the setting to use if automatic reviews on every push are too noisy.

Does requiring the Bugbot check block merges when it finds bugs?

No, and this is the most common misconfiguration. Findings produce a neutral conclusion by default, and a required check passes on neutral. Requiring the check only guarantees that Bugbot ran. To block on findings you need fail-on-unresolved-issues behaviour enabled for your organisation, which makes the conclusion failure instead.

How accurate is Bugbot?

Cursor's own claim is that more than half the bugs Bugbot finds are ultimately fixed by engineers, which is a fix rate rather than a precision figure. It uses a mix of frontier and in-house models. Treat it as a reviewer whose comments are usually worth reading rather than as a gate that is always right.

Which repository hosts does Bugbot support?

GitHub including GitHub Enterprise Server, GitLab including GitLab Self-Hosted, Bitbucket including Bitbucket Data Center, and Azure DevOps Services. Connect the provider through the Cursor dashboard, then enable Bugbot on specific repositories in Automations.

Does Bugbot review pull requests from people outside my team?

Yes. Once a repository is enabled, Bugbot runs for all contributors to it regardless of whether they are members of your Cursor team. That is usually what you want for open source, and worth knowing before enabling it on a busy public repository.

Can I customise what Bugbot looks for?

Yes, through Bugbot Rules, which let you state coding standards and project-specific guidelines the reviewer should enforce. Bugbot also reads existing pull request comments, top-level and inline, so it avoids repeating a suggestion a human already made.

Is there a free trial of Bugbot?

Cursor offers a 14-day free trial on all plans, which is long enough to see it run against a real week of pull requests rather than a synthetic one.

Can I run Bugbot without it commenting on the pull request?

Enterprise teams can, through the API. Setting dryRun to true runs the full analysis pipeline without posting comments, inline comments or checks. Findings are still stored and still billed, and you retrieve them from the analytics endpoint.

How do I see what Bugbot cost and whether its comments were acted on?

The analytics endpoint returns one item per completed review with the reviewed commit, the number of findings, the billed cost in cents, and a per-finding resolution status. Enterprise API keys need read scope for analytics and admin scope to trigger reviews.

Bugbot

Cursor's pull request reviewer. Straightforward to switch on, and easy to misconfigure in one specific way that makes it look like a gate when it is not.

Configured in Automations
14-day trial
GitHub, GitLab, Bitbucket, Azure DevOps

Checked against cursor.com on 25 September 2026

What it does on a pull request

Bugbot reads the diff and leaves comments where it believes something is wrong, with an explanation and a suggested fix. Each comment carries a Fix in Cursor link that opens the issue in your editor, and a Fix in Web link that opens it as a cloud agent task instead.

It reviews automatically on every update to a pull request, and you can trigger it by hand at any time by commenting on the thread.

Manual trigger, as a pull request comment

# cursor review
# bugbot run

It also reads the pull request’s existing comments, both top-level and inline, so it builds on feedback a human already left rather than repeating it. That is the difference between a reviewer and a linter, and it is the main reason Bugbot is tolerable on a busy repository.

The check that does not block

Bugbot publishes a status for every review run. Which conclusion it uses is the single most misunderstood thing about it.

Conclusion	What it means
success	No issues found, and no unresolved Bugbot comments left over from earlier runs on the same pull request.
neutral	Issues were found, or the run was cancelled by a newer commit, or Bugbot hit an internal error. This is the default conclusion when findings exist.
failure	Issues were found and the check is configured to fail on unresolved issues. Only appears when that behaviour is available and enabled for your organisation.

Provider	Appears as	Name
GitHub	Check	Cursor Bugbot
Bitbucket	Build status key	cursor-bugbot
Azure DevOps	Status context	cursor-bugbot/review

With Bugbot Autofix enabled, GitHub may show a second check named Cursor Bugbot Autofix. That one only ever reports success or neutral.

Setting it up

Connect the repository provider through the Cursor dashboard, then open Bugbot in Automations and enable it on specific repositories. Once a repository is on, Bugbot reviews pull requests from everyone who contributes to it, not only from members of your Cursor team.

Repository, set by team admins

Enable or disable Bugbot per repository
Allow and deny lists for reviewers
Run only once per pull request per installation, skipping later commits

Personal, for your own pull requests

Run only when mentioned, by commenting cursor review or bugbot run
Run only once per pull request, skipping later commits
Include draft pull requests in automatic reviews

The run-once settings matter more than they look. On a repository where people push fixups all day, reviewing every update means a comment thread that nobody reads by Thursday. Run-once plus manual cursor review when a pull request is genuinely ready tends to hold attention better.

The API, for Enterprise teams

Two endpoints. One queues a review, one returns analytics. Authentication is HTTP Basic with an API key from the dashboard as the username and an empty password.

Queue a review

$ curl --request POST \
$   --url https://api.cursor.com/bugbot/review \
$   -u YOUR_API_KEY: \
$   --header 'Content-Type: application/json' \
$   --data '{"prUrl": "https://github.com/your-org/your-repo/pull/42"}'

Triggering needs an admin:* scope key and is limited to 30 requests a minute per team. Analytics needs read:*.
The call returns as soon as the review is queued and includes a request_id. Keep it; that is how you match the completed review in analytics later.
Add "dryRun": true to analyse without posting anything to the repository host. Dry runs are still billed and still persist findings, and get their own limit of 10 requests a minute.
If Bugbot cannot review the pull request you get a 400 with a reason, such as Bugbot being disabled for that repository.

Fetch review analytics

$ curl --get https://api.cursor.com/analytics/team/bugbot-reviews \
$   -u YOUR_API_KEY: \
$   --data-urlencode 'startDate=2026-09-01' \
$   --data-urlencode 'repo=github.com/your-org/your-repo'

Each item includes the commit reviewed, how many bugs were found, the billed cost in cents, and per-finding severity and resolution status. Posted findings identify themselves by comment ID; dry-run findings return the title, description and file locations instead, because there is no comment to point at. The range defaults to the last seven days.

Is it worth turning on

The honest measure is the resolution data in the analytics endpoint, and it is the reason that endpoint is worth wiring up early. Cursor reports that more than half the bugs Bugbot finds end up fixed by engineers. Your own number will differ, and after a month you can read it directly rather than arguing about it.

Where it tends to earn its place is large changes and machine-written code, both of which are hard for a human reviewer to hold in their head. Where it tends to annoy people is small, frequent pull requests, where the comment-to-value ratio drops and the run-once setting becomes necessary rather than optional.

Treat it as a second reviewer with a good memory and no judgement about what matters, and configure it accordingly. Treating it as a merge gate without enabling fail-on-unresolved-issues produces the worst outcome available: a required check that always passes.

Checked against cursor.com/bugbot and the Bugbot documentation on 25 September 2026.

Frequently asked questions

What is Cursor Bugbot?: An automated pull request reviewer. It reads the diff, comments inline on bugs, security issues and code quality problems, and offers fixes that open directly in Cursor or in cursor.com/agents. It is configured from the Automations section of the Cursor dashboard.
How do I trigger a Bugbot review manually?: Comment either cursor review or bugbot run on the pull request. This also works when Bugbot is configured to review only when mentioned, which is the setting to use if automatic reviews on every push are too noisy.
Does requiring the Bugbot check block merges when it finds bugs?: No, and this is the most common misconfiguration. Findings produce a neutral conclusion by default, and a required check passes on neutral. Requiring the check only guarantees that Bugbot ran. To block on findings you need fail-on-unresolved-issues behaviour enabled for your organisation, which makes the conclusion failure instead.
How accurate is Bugbot?: Cursor's own claim is that more than half the bugs Bugbot finds are ultimately fixed by engineers, which is a fix rate rather than a precision figure. It uses a mix of frontier and in-house models. Treat it as a reviewer whose comments are usually worth reading rather than as a gate that is always right.
Which repository hosts does Bugbot support?: GitHub including GitHub Enterprise Server, GitLab including GitLab Self-Hosted, Bitbucket including Bitbucket Data Center, and Azure DevOps Services. Connect the provider through the Cursor dashboard, then enable Bugbot on specific repositories in Automations.
Does Bugbot review pull requests from people outside my team?: Yes. Once a repository is enabled, Bugbot runs for all contributors to it regardless of whether they are members of your Cursor team. That is usually what you want for open source, and worth knowing before enabling it on a busy public repository.
Can I customise what Bugbot looks for?: Yes, through Bugbot Rules, which let you state coding standards and project-specific guidelines the reviewer should enforce. Bugbot also reads existing pull request comments, top-level and inline, so it avoids repeating a suggestion a human already made.
Is there a free trial of Bugbot?: Cursor offers a 14-day free trial on all plans, which is long enough to see it run against a real week of pull requests rather than a synthetic one.
Can I run Bugbot without it commenting on the pull request?: Enterprise teams can, through the API. Setting dryRun to true runs the full analysis pipeline without posting comments, inline comments or checks. Findings are still stored and still billed, and you retrieve them from the analytics endpoint.
How do I see what Bugbot cost and whether its comments were acted on?: The analytics endpoint returns one item per completed review with the reviewed commit, the number of findings, the billed cost in cents, and a per-finding resolution status. Enterprise API keys need read scope for analytics and admin scope to trigger reviews.