Bugbot

Bugbot prüft Pull Requests auf Bugs, Sicherheitslücken und Probleme bei der Codequalität.

Konfiguriere Bugbot unter Automatisierungen.

So funktioniert es

Bugbot analysiert PR-Diffs und hinterlässt Kommentare mit Erklärungen und Lösungsvorschlägen. Es wird bei jeder PR-Aktualisierung automatisch ausgeführt oder manuell gestartet.

• Führt bei jeder PR-Aktualisierung automatische Reviews durch
• Manueller Start durch einen Kommentar mit cursor review oder bugbot run in einer beliebigen PR
• Verwendet bestehende PR-Kommentare als Kontext: Liest verknüpfte PR-Kommentare (auf oberster Ebene und inline), um doppelte Vorschläge zu vermeiden und auf vorherigem Feedback aufzubauen
• Fix in Cursor öffnet Issues direkt in Cursor
• Fix in Web öffnet Issues direkt in cursor.com/agents

Einrichtung

Verbinde deine Repositories über das Cursor-Dashboard, um Bugbot zu nutzen.

• GitHub (einschließlich GitHub Enterprise Server): Siehe die GitHub-Integrationsseite
• GitLab (einschließlich GitLab Self-Hosted): Siehe die GitLab-Integrationsseite
• Bitbucket (einschließlich Bitbucket Data Center): Siehe die Bitbucket-Integrationsseite

Öffne nach dem Verbinden Bugbot in Automatisierungen, um Bugbot für bestimmte Repositories zu aktivieren.

CI-Prüfstatus

Bugbot veröffentlicht für jede Review-Ausführung einen Status. Auf GitHub erscheint dieser als Prüfung mit dem Namen Cursor Bugbot. Auf Bitbucket erscheint er als Build-Status mit dem Schlüssel cursor-bugbot. Der Status verwendet die folgenden Ergebnisse:

• success: Bugbot hat keine Issues gefunden und es gibt keine ungelösten Bugbot-Kommentare aus früheren Ausführungen.
• neutral: Bugbot hat Issues gefunden, die Ausführung wurde durch einen neueren Commit abgebrochen oder bei Bugbot ist ein interner Fehler aufgetreten. Dies ist das Standardergebnis, wenn Bugbot Findings meldet.
• failure: Bugbot hat Issues gefunden und die Prüfung ist so konfiguriert, dass sie bei ungelösten Issues fehlschlägt.

Wenn du Branch Protection verwendest, fordere die Bugbot-Prüfung oder den Build-Status an, um sicherzustellen, dass Bugbot vor dem Merge ausgeführt wird. Das Anfordern des Status allein blockiert Merges bei Findings nicht, da Findings standardmäßig zu neutral führen. Wenn das Verhalten „Bei ungelösten Issues fehlschlagen“ für deine Organisation verfügbar ist, aktiviere es, damit ungelöste Findings einen fehlschlagenden Status verursachen. Bugbot gibt kein Ergebnis skipped aus.

Wenn Bugbot Autofix aktiviert ist, kann GitHub auch eine separate Prüfung Cursor Bugbot Autofix anzeigen. Diese Prüfung verwendet nur success oder neutral.

Konfiguration

Analytics

Öffnen Sie Bugbot in Automatisierungen, um Review-Aktivitäten und Ergebnisse anzuzeigen.

API

Enterprise-Teams können die Bugbot API nutzen, um Reviews auszulösen und Analysedaten zu einzelnen Reviews abzurufen. Erstelle einen API-Schlüssel über Cursor Dashboard → API Keys und authentifiziere dich mit Basic-Authentifizierung.

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"  }'

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",    "dryRun": true  }'

{  "outcome": "success",  "message": "Bugbot review queued",  "request_id": "6e0d261c-86a2-4383-89f0-9162c1c10662",  "dry_run": false}

{  "outcome": "error",  "message": "Bugbot is disabled for this repository"}

curl --get https://api.cursor.com/analytics/team/bugbot-reviews \  -u YOUR_API_KEY: \  --data-urlencode 'startDate=2026-06-01' \  --data-urlencode 'endDate=2026-06-29' \  --data-urlencode 'repo=github.com/your-org/your-repo' \  --data-urlencode 'prNumber=42' \  --data-urlencode 'page=1' \  --data-urlencode 'pageSize=100'

curl --get https://api.cursor.com/analytics/team/bugbot-reviews \  -u YOUR_API_KEY: \  --data-urlencode 'dryRun=true' \  --data-urlencode 'repo=github.com/your-org/your-repo' \  --data-urlencode 'prNumber=42'

{  "data": [    {      "request_id": "6e0d261c-86a2-4383-89f0-9162c1c10662",      "timestamp": "2026-06-29T19:42:18.000Z",      "repo": "github.com/your-org/your-repo",      "repo_node_id": "R_kgDOABCDEF",      "pr_number": 42,      "commit_sha": "9f3c2a1b7d8e4f5061728394a5b6c7d8e9f0a1b2",      "bugs_found": 2,      "cost_cents": 42.5,      "dry_run": false,      "publication_status": "posted",      "bugs": [        {          "comment_id": "2147483999",          "resolution_status": "resolved",          "severity": "high"        },        {          "comment_id": "2147484000",          "resolution_status": "unresolved",          "severity": "medium"        }      ]    }  ],  "pagination": {    "page": 1,    "pageSize": 100,    "totalItems": 1,    "totalPages": 1,    "hasNextPage": false,    "hasPreviousPage": false  },  "params": {    "metric": "bugbot-reviews",    "teamId": 12345,    "startDate": "2026-06-01",    "endDate": "2026-06-29",    "repo": "github.com/your-org/your-repo",    "prNumber": 42,    "page": 1,    "pageSize": 100  }}

{  "data": [    {      "request_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",      "timestamp": "2026-06-29T20:15:03.000Z",      "repo": "github.com/your-org/your-repo",      "repo_node_id": "R_kgDOABCDEF",      "pr_number": 42,      "commit_sha": "9f3c2a1b7d8e4f5061728394a5b6c7d8e9f0a1b2",      "bugs_found": 1,      "cost_cents": null,      "dry_run": true,      "publication_status": "dry_run",      "bugs": [        {          "comment_id": null,          "resolution_status": null,          "severity": "medium",          "title": "Unbounded retry loop",          "description": "retry() recurses without a ceiling.",          "locations": [            { "file": "src/net.ts", "start_line": 5, "end_line": 9 }          ]        }      ]    }  ],  "pagination": {    "page": 1,    "pageSize": 100,    "totalItems": 1,    "totalPages": 1,    "hasNextPage": false,    "hasPreviousPage": false  },  "params": {    "metric": "bugbot-reviews",    "teamId": 12345,    "startDate": "2026-06-01",    "endDate": "2026-06-29",    "repo": "github.com/your-org/your-repo",    "prNumber": 42,    "dryRun": true,    "page": 1,    "pageSize": 100  }}

Eine Review auslösen und abrufen

1. Rufe POST /bugbot/review mit der Pull-Request-URL auf. Übergib "dryRun": true, um die Analyse ohne Veröffentlichung im SCM durchzuführen.
2. Speichere die zurückgegebene request_id.
3. Frage GET /analytics/team/bugbot-reviews regelmäßig ab und filtere nach repo und prNumber. Verwende dryRun=true, wenn du eine Dry-Run-Review ausgelöst hast.
4. Suche das Element, dessen request_id mit der Antwort auf das Auslösen übereinstimmt.

Nach dem Einreihen einer Review kann es einen Moment dauern, bis die Analytics verfügbar sind.

Inkrementelle Reviews

Standardmäßig prüft Bugbot bei jedem Push den gesamten Pull-Request-Diff. Aktiviere Inkrementelles Review in Bugbot-Automatisierungen, um nur die Änderungen seit dem letzten Bugbot-Review zu prüfen.

Aufwandsstufen

Aufwandsstufen steuern, wie viel Zeit Bugbot während eines Reviews für die Analyse aufwendet. Höhere Aufwandsstufen können mehr Fehler finden, aber jedes Review kann länger dauern und mehr Nutzung verbrauchen.

Wähle aus diesen Aufwandsstufen:

• Standard: Optimiert auf Effizienz und Geschwindigkeit. Reviews sind günstiger, aber Bugbot findet möglicherweise weniger Fehler.
• Hoch: Wendet mehr Zeit für die Analyse auf. Reviews sind teurer und dauern länger, aber Bugbot findet möglicherweise mehr Fehler.
• Benutzerdefiniert: Ermöglicht dir, zu beschreiben, wann Bugbot längere und gründlichere Reviews verwenden soll. Cursor legt die Aufwandsstufen anhand deiner Anweisungen dynamisch fest.

Regeln

Steuere Reviews mit Teamregeln, Repository-Regeln und .cursor/BUGBOT.md-Dateien im Projekt.

Team-Regeln

Team-Admins können in Bugbot-Automatisierungen Regeln erstellen, die für alle Repositories im Team gelten. Diese Regeln stehen in jedem aktivierten Repository zur Verfügung und erleichtern die Durchsetzung organisationsweiter Standards.

Regellimits

Jede Regel wird bei der Einbeziehung in ein Review auf 30.000 Zeichen gekürzt. Die Gesamtzahl der Zeichen aller Regeln, die Bugbot in ein Review einbezieht, ist auf 100.000 begrenzt. Bei Überschreitung dieser Gesamtgrenze können einige Regeln ausgelassen werden. Erforderliche Teamregeln haben Vorrang vor nicht erforderlichen Regeln.

Anzeigen, welche Regeln bei einer Review verwendet wurden

Kommentieren Sie einen Pull Request mit bugbot run verbose=true oder cursor review verbose=true. Bugbot veröffentlicht eine Tabelle aller in diesem Durchlauf verwendeten Regeln und kennzeichnet gekürzte oder ausgelassene Regeln.

Repository-Regeln

Projektregeln

Erstellen Sie .cursor/BUGBOT.md-Dateien, um Bugbot projektspezifischen Kontext für Reviews bereitzustellen. Bugbot bezieht stets die .cursor/BUGBOT.md-Datei im Stammverzeichnis sowie alle zusätzlichen Dateien ein, die beim Durchlaufen der Verzeichnishierarchie von geänderten Dateien nach oben gefunden werden.

project/  .cursor/BUGBOT.md          # Stets enthalten (projektweite Regeln)  backend/    .cursor/BUGBOT.md        # Enthalten beim Review von Backend-Dateien    api/      .cursor/BUGBOT.md      # Enthalten beim Review von API-Dateien  frontend/    .cursor/BUGBOT.md        # Enthalten beim Review von Frontend-Dateien

Gelernte Regeln

Aktiviere in den Bugbot-Repository-Regeln das Lernen für deine Organisationen und Repositories.

Regeln werden automatisch anhand der GitHub-Aktivität deines Teams in diesem Repository erstellt oder manuell aus dem Repository-Verlauf nachgetragen.

Du kannst Bugbot auch direkt in einer PR neue Regeln beibringen, indem du @cursor remember [fact] kommentierst. Bugbot speichert die Information als gelernte Regel und wendet sie bei zukünftigen Reviews an.

Cursor aktiviert oder deaktiviert Regeln automatisch, wenn es im Laufe der Zeit mehr über die Aktivität deines Teams lernt.

Manuelle Regeln

In den Bugbot-Repository-Regeln kannst du manuelle Regeln für einzelne Repositories erstellen.

Regelanalysen

Analysen einer Bugbot-Regel zeigen, wie sie sich bei echten PRs bewährt:

Beispiele

Wenn eine geänderte Datei das Zeichenfolgenmuster /\beval\s*\(|\bexec\s*\(/i enthält:- Einen blockierenden Bug mit dem Titel „Gefährliche dynamische Ausführung“ und folgendem Text hinzufügen:  „Es wurde eine Verwendung von eval/exec gefunden. Durch sichere Alternativen ersetzen oder mit einem ausführlichen Kommentar und Tests begründen.“- Den Bug dem PR-Autor zuweisen.- Das Label „security“ anwenden.

Wenn der PR Abhängigkeitsdateien (package.json, pnpm-lock.yaml, yarn.lock, requirements.txt, go.mod, Cargo.toml) ändert:- Den integrierten Lizenzscan ausführen.- Wenn eine neue oder aktualisierte Abhängigkeit eine Lizenz aus {GPL-2.0, GPL-3.0, AGPL-3.0} hat:  - Einen blockierenden Bug mit dem Titel „Nicht zulässige Lizenz erkannt“ hinzufügen.  - Die Namen, Versionen und Lizenzen der betroffenen Pakete im Bug-Text angeben.  - Die Labels „compliance“ und „security“ anwenden.

Für Dateien in React-Projekten, die **/*.{js,jsx,ts,tsx} entsprechen:Wenn eine geänderte Datei /componentWillMount\s*\(/ enthält:- Einen blockierenden Bug mit dem Titel „Veraltete React-Lifecycle-Methode“ hinzufügen.- Text: „componentWillMount durch constructor oder useEffect ersetzen. Siehe React-Dokumentation.“- Ein Autofix-Snippet vorschlagen, das Nebenwirkungen zu useEffect migriert.

Wenn der PR Dateien in {server/**, api/**, backend/**} ändert und es keine Änderungen in {**/*.test.*, **/__tests__/**, tests/**} gibt:- Einen blockierenden Bug mit dem Titel „Fehlende Tests für Backend-Änderungen“ hinzufügen.- Text: „Dieser PR ändert Backend-Code, enthält aber keine begleitenden Tests. Bitte Tests hinzufügen oder aktualisieren.“- Das Label „quality“ anwenden.

Wenn eine geänderte Datei /(?:^|\s)(TODO|FIXME)(?:\s*:|\s+)/ enthält:- Einen nicht blockierenden Bug mit dem Titel „TODO/FIXME-Kommentar gefunden“ hinzufügen.- Text: „TODO/FIXME durch eine Referenz auf ein getracktes Issue ersetzen, z. B. `TODO(#1234): ...`, oder entfernen.“- Wenn das TODO bereits auf ein Issue-Muster /#\d+|[A-Z]+-\d+/ verweist, den Bug automatisch als gelöst markieren.

In deinem Agent ausführen

Verwende die Skills /review-bugbot oder /review, um Bugbot vor dem Pushen des Codes in deinem Agent auszuführen.

Welcher Diff geprüft wird: Standardmäßig prüft /review-bugbot die Änderungen in deinem Branch: jede Änderung gegenüber dem Base-Branch, einschließlich committeter und nicht committeter Änderungen. Bitte den Agent, nur deine nicht committeten Änderungen zu prüfen, wenn du gezielteres Feedback möchtest.

Vergleichs-Branch: /review-bugbot vergleicht mit deinem Standard-Base-Branch. Wenn dein Base-Branch nicht der Standard ist (z. B. main), teile dem Agent mit, mit welchem Branch verglichen werden soll, oder lass ihn dies aus dem Kontext ableiten.

Mit deinem Pull Request synchronisieren

/review-bugbot-Reviews bleiben mit Bugbot in deinem verbundenen SCM (GitHub, GitLab oder Bitbucket) synchron.

Im Hintergrund speichert /review-bugbot die Patch-ID des überprüften Diffs. Erkennt Bugbot in deinem SCM ein Diff mit derselben Patch-ID, überspringt es die Review und hinterlässt einen Kommentar, dass es dieses Diff bereits überprüft hat.

Ein häufiger Anwendungsfall: Führe /review-bugbot aus, öffne dann einen Pull Request mit demselben Diff. Bugbot erkennt die Review und überspringt die PR-Review im Remote-Repository.

Autofix

Bugbot Autofix startet automatisch einen Cloud-Agent, um bei PR-Reviews gefundene Bugs zu beheben.

So funktioniert es

Wenn Bugbot während einer PR-Review Bugs findet, kann es automatisch:

1. einen Cloud-Agent starten, um die gemeldeten Issues zu analysieren und zu beheben
2. Fixes in den bestehenden oder einen neuen Branch pushen (abhängig von deinen Einstellungen)
3. einen Kommentar mit den Ergebnissen zur ursprünglichen PR posten

Konfiguration

Konfiguriere das Autofix-Verhalten in Bugbot-Automatisierungen.

Anforderungen

Für Autofix ist Folgendes erforderlich:

• On-Demand-Nutzung muss aktiviert sein
• Speicher muss aktiviert sein (nicht im Legacy Privacy Mode)

Abrechnung

Autofix nutzt Cloud-Agent-Credits und wird zu den Tarifen deines Plans abgerechnet. Für Cloud Agents gilt dein bestehender Preisplan.

MCP-Unterstützung

Bugbot ist in deine MCP-Server integriert, sodass deine AI-Tools direkt mit Bugbot interagieren können. Nutze den MCP-Server, um Bugbot zusätzliche Tools für den Review-Prozess bereitzustellen.

So legst du los:

1. Folge den Anweisungen zur Einrichtung des MCP-Servers in der MCP-Dokumentation.
2. Füge die Tools zu Bugbot in Automatisierungen hinzu.

Admin-API für die Konfiguration

Team-Admins können mit der Bugbot Admin-API Repositories verwalten und festlegen, welche Nutzer Bugbot nutzen können. Damit können Sie die Repository-Verwaltung automatisieren, Bugbot für mehrere Repositories aktivieren oder die Nutzerbereitstellung in interne Tools integrieren.

Authentifizierung

Für alle Endpunkte ist ein Team-Admin-API-Schlüssel erforderlich, der als Bearer-Token übergeben wird:

Authorization: Bearer $API_KEY

So erstellen Sie einen API-Schlüssel:

1. Öffnen Sie API Keys im Cursor-Dashboard.
2. Klicken Sie auf New API Key.
3. Speichern Sie den API-Schlüssel.

Alle Endpunkte sind auf 60 Anfragen pro Minute und Team begrenzt.

Repositories aktivieren oder deaktivieren

Verwenden Sie den Endpunkt /bugbot/repo/update, um Bugbot für ein Repository ein- oder auszuschalten:

curl -X POST https://api.cursor.com/bugbot/repo/update \  -H "Authorization: Bearer $API_KEY" \  -H "Content-Type: application/json" \  -d '{    "repoUrl": "https://github.com/your-org/your-repo",    "enabled": true,    "manualTriggerOnly": false  }'

Parameter:

• repoUrl (string, erforderlich): Die vollständige URL des Repositorys
• enabled (boolean, erforderlich): true, um Bugbot zu aktivieren, false, um ihn zu deaktivieren
• manualTriggerOnly (boolean, optional): Bei true wird Bugbot für dieses Repository nicht automatisch bei PR-Aktualisierungen ausgeführt. Manuelle Auslöser wie Kommentare mit cursor review oder bugbot run funktionieren weiterhin.

Repositories auflisten

Verwende den Endpunkt /bugbot/repos, um alle Repositories und ihre Bugbot-Einstellungen für dein Team aufzulisten:

curl https://api.cursor.com/bugbot/repos \  -H "Authorization: Bearer $API_KEY"

Die Antwort enthält für jedes Repository den Aktivierungsstatus, die Einstellung „Nur manuell“ und Zeitstempel.

Nutzerzugriff verwalten

Verwende den Endpunkt /bugbot/user/update, um festzulegen, welche GitHub-, GitLab- oder Bitbucket-Nutzer die Bugbot-Lizenzen deines Teams nutzen können. Unternehmen verwenden diesen Endpunkt, um die Bereitstellung von Bugbot in interne Tools für Zugriffsanfragen zu integrieren.

Voraussetzungen

Aktiviere vor dem Aufruf dieses Endpunkts in deinen Bugbot-Einstellungen für das Team den Allowlist- oder Blocklist-Modus:

• **Allowlist-Modus („Nur …“) **: Nur Nutzer auf der Liste können Bugbot nutzen
• **Blocklist-Modus („Alle außer …“) **: Alle Nutzer außer denen auf der Liste können Bugbot nutzen

Wenn keiner der Modi aktiviert ist, gibt die API einen Fehler zurück.

Nutzer hinzufügen oder entfernen

curl -X POST https://api.cursor.com/bugbot/user/update \  -H "Authorization: Bearer $API_KEY" \  -H "Content-Type: application/json" \  -d '{    "username": "octocat",    "allow": true  }'

Parameter:

• username (string, erforderlich): Der GitHub-, GitLab- oder Bitbucket-Benutzername (Groß-/Kleinschreibung wird nicht berücksichtigt)
• allow (boolean, erforderlich): Gibt an, ob Zugriff gewährt oder entzogen wird

Das Verhalten von allow hängt vom aktiven Modus ab:

Antwort:

{  "outcome": "success",  "message": "Updated team-level allowlist for @octocat",  "updatedTeamSettings": true,  "updatedInstallations": 0}

Beispiel: Nutzer über ein internes Tool bereitstellen

Verbinden Sie diese API mit einem internen Portal für Zugriffsanfragen. Wenn ein Mitarbeiter Zugriff auf Bugbot anfordert, ruft das Portal die API auf, um ihn hinzuzufügen. Wenn er das Unternehmen verlässt oder den Zugriff verliert, ruft es die API auf, um ihn zu entfernen.

Zugriff gewähren:

curl -X POST https://api.cursor.com/bugbot/user/update \  -H "Authorization: Bearer $API_KEY" \  -H "Content-Type: application/json" \  -d '{"username": "employee-scm-username", "allow": true}'

Zugriff widerrufen:

curl -X POST https://api.cursor.com/bugbot/user/update \  -H "Authorization: Bearer $API_KEY" \  -H "Content-Type: application/json" \  -d '{"username": "employee-scm-username", "allow": false}'

Preise

Bugbot rechnet nutzungsbasiert ab.

Abrechnung

Fehlerbehebung

Wenn Bugbot nicht funktioniert:

1. Aktiviere den ausführlichen Modus, indem du cursor review verbose=true oder bugbot run verbose=true kommentierst. So erhältst du detaillierte Protokolle, die geladenen Bugbot-Regeln und eine Request-ID.
2. Überprüfe die Permissions, um sicherzustellen, dass Bugbot Repository-Zugriff hat
3. Überprüfe die Installation, um sicherzustellen, dass die Integration deines Repository-Providers installiert und aktiviert ist

Gib beim Melden von Issues die Request-ID aus dem ausführlichen Modus an.

FAQ