pages/bugbot.txt

route: /docs/bugbot
title: Bugbot
description: Bugbot reviews pull requests and identifies bugs, security issues, and code quality problems. Configure repository rules, team rules, BUGBOT.md, and autofix with Cloud Agent.

Bugbot
Bugbot reviews pull requests and identifies bugs, security issues, and code quality problems.
How it works
Bugbot analyzes PR diffs and leaves comments with explanations and fix suggestions. It runs automatically on each PR update or manually when triggered.
Runs automatic reviews on every PR update
Manual trigger by commenting cursor review or bugbot run on any PR
Uses existing PR comments as context: reads connected PR comments (top-level and inline) to avoid duplicate suggestions and build on prior feedback
Fix in Cursor links open issues directly in Cursor
Fix in Web links open issues directly in cursor.com/agents
Setup
Connect your repositories through the Cursor dashboard to start using Bugbot.
GitHub (including GitHub Enterprise Server): See the GitHub integration page
GitLab (including GitLab Self-Hosted): See the GitLab integration page
Bitbucket Cloud: See the Bitbucket integration page
After connecting, return to the Bugbot dashboard to enable Bugbot on specific repositories.
CI check statuses
Bugbot publishes a status for each review run. On GitHub, this appears as a check named Cursor Bugbot. On Bitbucket, this appears as a build status with the key cursor-bugbot. The status uses these conclusions:
success: Bugbot found no issues, and there are no unresolved Bugbot comments from earlier runs.
neutral: Bugbot found issues, the run was cancelled by a newer commit, or Bugbot hit an internal error. This is the default conclusion when Bugbot reports findings.
failure: Bugbot found issues and the check is configured to fail on unresolved issues.
If you use branch protection, require the Bugbot check or build status to make sure Bugbot runs before merge. Requiring the status alone does not block merges on findings because findings default to neutral. If fail-on-unresolved-issues behavior is available for your organization, enable it to make unresolved findings produce a failing status. Bugbot does not emit a skipped conclusion.
When Bugbot Autofix is enabled, GitHub may also show a separate Cursor Bugbot Autofix check. That check only uses success or neutral.
Configuration
IndividualTeamRepository settings
Enable or disable Bugbot per repository from your installations list. Bugbot runs only on PRs you author.
Personal settings
Run only when mentioned by commenting cursor review or bugbot run
Run only once per PR, skipping subsequent commits
Repository settings
Team admins can enable Bugbot per repository, configure allow/deny lists for reviewers, and set:
Run only once per PR per installation, skipping subsequent commits
Bugbot runs for all contributors to enabled repositories, regardless of team membership.
Personal settings
Team members can override settings for their own PRs:
Run only when mentioned by commenting cursor review or bugbot run
Run only once per PR, skipping subsequent commits
Enable reviews on draft PRs to include draft pull requests in automatic reviews
Analytics
Bugbot dashboard
Incremental reviews
By default, Bugbot reviews the full pull request diff on every push. Turn on Incremental Review from the Bugbot dashboard to review only the changes since the previous Bugbot review.
Incremental Review setting in the Bugbot dashboard
Effort Levels
Effort levels control how much time Bugbot spends reasoning during a review. Higher effort levels can find more bugs, but each review may take longer and take more up usage.
Choose from these effort levels:
Default: Optimizes for efficiency and speed. Reviews are less expensive, but Bugbot may find fewer bugs.
High: Spends more time reasoning. Reviews are more expensive and take longer, but Bugbot may find more bugs.
Custom: Lets you describe when Bugbot should use longer and deeper reviews. Cursor dynamically sets effort levels based on your instructions.
Effort levels are available only for usage-based Bugbot plans.
Team rules
Team admins can create rules from the Bugbot dashboard that apply to all repositories in the team. These rules are available to every enabled repository, making it easy to enforce organization-wide standards.
When Team Rules, repository rules, and project rule files all apply, Bugbot merges them. Order of application: Team Rules → repository rules (learned and manual) → project BUGBOT.md (including nested files) → User Rules.
Repository rules
Project rules
Create .cursor/BUGBOT.md files to provide project-specific context for reviews. Bugbot always includes the root .cursor/BUGBOT.md file and any additional files found while traversing upward from changed files.
project/
.cursor/BUGBOT.md # Always included (project-wide rules)
backend/
.cursor/BUGBOT.md # Included when reviewing backend files
api/
.cursor/BUGBOT.md # Included when reviewing API files
frontend/
.cursor/BUGBOT.md # Included when reviewing frontend files
Learned rules
In the Bugbot dashboard, enable learning for your organizations and repositories.
Rules are generated automatically from your team's activity on GitHub for that repository or by manually backfilling from the history of the repository.
You can also teach Bugbot new rules inline by commenting @cursor remember [fact] on any PR. Bugbot saves the fact as a learned rule and applies it to future reviews.
Cursor will automatically enable or disable rules as it learns more about your team's activity over time.
Field
Description
Name
Short title for the rule.
Rule content
The instructions Bugbot should follow (i.e. style gates, paths, or review expectations).
Scoped paths
Optional glob patterns such as src/components/**. Leave empty to apply the rule across the whole repository.
Manual rules
In the Bugbot dashboard, you can create manual rules for individual repositories.
Field
Description
Name
Short title for the rule.
Rule content
The instructions Bugbot should follow (i.e. style gates, paths, or review expectations).
Scoped paths
Optional glob patterns such as src/components/**. Leave empty to apply the rule across the whole repository.
Rule analytics
Analytics on a Bugbot rule show how it performs on real PRs:
Metric
Meaning
Issues found
Number of findings Bugbot reported that involve this rule.
PRs reviewed
Number of pull requests where those findings appeared.
Accepted issues
Number of findings your team accepted.
Acceptance rate
Percentage of findings that were accepted.
Examples
Security: Flag any use of eval() or exec()
If any changed file contains the string pattern /\beval\s*\(|\bexec\s*\(/i, then:
- Add a blocking Bug with title "Dangerous dynamic execution" and body:
"Usage of eval/exec was found. Replace with safe alternatives or justify with a detailed comment and tests."
- Assign the Bug to the PR author.
- Apply label "security".
OSS licenses: Prevent importing disallowed licenses
If the PR modifies dependency files (package.json, pnpm-lock.yaml, yarn.lock, requirements.txt, go.mod, Cargo.toml), then:
- Run the built-in License Scan.
- If any new or upgraded dependency has license in {GPL-2.0, GPL-3.0, AGPL-3.0}, then:
- Add a blocking Bug titled "Disallowed license detected"
- Include the offending package names, versions, and licenses in the Bug body
- Apply labels "compliance" and "security"
Language standards: Flag React componentWillMount usage
For files matching **/*.{js,jsx,ts,tsx} in React projects:
If a changed file contains /componentWillMount\s*\(/, then:
- Add a blocking Bug titled "Deprecated React lifecycle method"
- Body: "Replace componentWillMount with constructor or useEffect. See React docs."
- Suggest an autofix snippet that migrates side effects to useEffect.
Standards: Require tests for backend changes
If the PR modifies files in {server/**, api/**, backend/**} and there are no changes in {**/*.test.*, **/__tests__/**, tests/**}, then:
- Add a blocking Bug titled "Missing tests f
…