Bugbot

Bugbot passe en revue les pull requests et identifie les bugs, les problèmes de sécurité et les problèmes de qualité du code.

Configurez Bugbot dans Automatisations.

Fonctionnement

Bugbot analyse les diffs des PR et ajoute des commentaires contenant des explications et des suggestions de correction. Il s’exécute automatiquement à chaque mise à jour de PR ou manuellement sur déclenchement.

• Effectue des revues automatiques à chaque mise à jour de PR
• Déclenchement manuel en commentant cursor review ou bugbot run sur n’importe quelle PR
• Utilise les commentaires existants de la PR comme contexte : lit les commentaires associés à la PR (généraux et en ligne) pour éviter les suggestions en double et s’appuyer sur les retours précédents
• Les liens Fix in Cursor ouvrent directement les issues dans Cursor
• Les liens Fix in Web ouvrent directement les issues dans cursor.com/agents

Configuration

Connectez vos dépôts via le tableau de bord Cursor pour commencer à utiliser Bugbot.

• GitHub (y compris GitHub Enterprise Server) : voir la page d’intégration GitHub
• GitLab (y compris GitLab Self-Hosted) : voir la page d’intégration GitLab
• Bitbucket (y compris Bitbucket Data Center) : voir la page d’intégration Bitbucket

Une fois vos dépôts connectés, ouvrez Bugbot dans l’automatisation pour l’activer sur certains dépôts.

Statuts des vérifications CI

Bugbot publie un statut pour chaque exécution de revue. Sur GitHub, il apparaît sous la forme d’une vérification nommée Cursor Bugbot. Sur Bitbucket, il apparaît sous la forme d’un statut de build avec la clé cursor-bugbot. Le statut peut avoir les conclusions suivantes :

• success : Bugbot n’a trouvé aucune issue et aucun commentaire Bugbot non résolu issu d’exécutions précédentes.
• neutral : Bugbot a trouvé des issues, l’exécution a été annulée par un commit plus récent ou Bugbot a rencontré une erreur interne. C’est la conclusion par défaut lorsque Bugbot signale des résultats.
• failure : Bugbot a trouvé des issues et la vérification est configurée pour échouer en présence d’issues non résolues.

Si vous utilisez la protection des branches, exigez la vérification Bugbot ou le statut de build afin de vous assurer que Bugbot s’exécute avant la fusion. Exiger uniquement le statut ne bloque pas les fusions en cas de résultats, car ceux-ci utilisent neutral par défaut. Si le comportement d’échec en cas d’issues non résolues est disponible pour votre organisation, activez-le afin que les résultats non résolus génèrent un statut d’échec. Bugbot n’émet pas de conclusion skipped.

Lorsque Bugbot Autofix est activé, GitHub peut également afficher une vérification distincte Cursor Bugbot Autofix. Cette vérification utilise uniquement success ou neutral.

Configuration

Analyse

Ouvrez Bugbot dans l’automatisation pour consulter l’activité de revue et ses résultats.

API

Les équipes Enterprise peuvent utiliser l’API Bugbot pour déclencher des revues et récupérer les analyses de chaque revue. Créez une clé API depuis Cursor Dashboard → clé API et authentifiez-vous via l’authentification de base.

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

Déclencher et récupérer une revue

1. Appelez POST /bugbot/review avec l’URL de la pull request. Transmettez "dryRun": true pour analyser sans publier sur le SCM.
2. Enregistrez le request_id renvoyé.
3. Interrogez régulièrement GET /analytics/team/bugbot-reviews en filtrant par repo et prNumber. Utilisez dryRun=true si vous avez déclenché une revue dry-run.
4. Trouvez l’élément dont le request_id correspond à la réponse de la requête de déclenchement.

Les données d’analyse peuvent mettre un court moment à être disponibles après la mise en file d’attente d’une revue.

Revues incrémentielles

Par défaut, Bugbot passe en revue l’intégralité du diff de la pull request à chaque push. Activez Incremental Review dans l’automatisation Bugbot pour ne passer en revue que les modifications apportées depuis la précédente revue de Bugbot.

Niveaux d’effort

Les niveaux d’effort déterminent le temps que Bugbot consacre au raisonnement lors d’une revue. Des niveaux d’effort plus élevés peuvent permettre de détecter davantage de bugs, mais les revues peuvent être plus longues et consommer davantage de ressources.

Choisissez l’un des niveaux d’effort suivants :

• Par défaut : Optimise l’efficacité et la rapidité. Les revues sont moins coûteuses, mais Bugbot peut détecter moins de bugs.
• Élevé : Consacre plus de temps au raisonnement. Les revues sont plus coûteuses et plus longues, mais Bugbot peut détecter davantage de bugs.
• Personnalisé : Vous permet d’indiquer quand Bugbot doit effectuer des revues plus longues et plus approfondies. Cursor ajuste dynamiquement les niveaux d’effort en fonction de vos instructions.

Règles

Orientez les revues à l’aide de règles d’équipe, de règles du dépôt et de fichiers .cursor/BUGBOT.md du projet.

Règles d’équipe

Les administrateurs d’équipe peuvent créer des règles dans l’automatisation Bugbot qui s’appliquent à tous les dépôts de l’équipe. Ces règles sont disponibles dans chaque dépôt activé, ce qui permet d’appliquer facilement des normes à l’échelle de l’organisation.

Limites des règles

Chaque règle est tronquée à 30 000 caractères lorsqu’elle est incluse dans une revue. Le nombre total de caractères des règles incluses par Bugbot dans une revue est limité à 100 000. Si vous dépassez cette limite cumulée, certaines règles peuvent être omises. Les règles d’équipe obligatoires sont prioritaires par rapport aux règles non obligatoires.

Voir les règles utilisées lors d'une revue

Commentez bugbot run verbose=true ou cursor review verbose=true sur une pull request. Bugbot publie un tableau de toutes les règles incluses dans cette exécution et signale celles qui ont été tronquées ou omises.

Règles du dépôt

Règles du projet

Créez des fichiers .cursor/BUGBOT.md pour fournir un contexte propre au projet lors des revues. Bugbot inclut systématiquement le fichier .cursor/BUGBOT.md situé à la racine, ainsi que tous les fichiers supplémentaires trouvés en remontant l’arborescence depuis les fichiers modifiés.

project/  .cursor/BUGBOT.md          # Toujours inclus (règles valables pour tout le projet)  backend/    .cursor/BUGBOT.md        # Inclus lors de la revue des fichiers backend    api/      .cursor/BUGBOT.md      # Inclus lors de la revue des fichiers API  frontend/    .cursor/BUGBOT.md        # Inclus lors de la revue des fichiers frontend

Règles apprises

Dans les règles de dépôt Bugbot, activez l’apprentissage pour vos organisations et dépôts.

Les règles sont générées automatiquement à partir de l’activité de votre équipe sur GitHub dans ce dépôt, ou ajoutées manuellement à partir de l’historique du dépôt.

Vous pouvez également apprendre de nouvelles règles à Bugbot en ajoutant le commentaire @cursor remember [fact] sur n’importe quelle PR. Bugbot enregistre cette information comme règle apprise et l’applique aux futures revues.

Cursor active ou désactive automatiquement les règles à mesure qu’il en apprend davantage sur l’activité de votre équipe.

Règles manuelles

Dans les règles de dépôt de Bugbot, vous pouvez créer des règles manuelles pour chaque dépôt.

Analyse des règles

Les analyses d'une règle Bugbot indiquent ses performances sur de vraies PR :

Exemples

Si un fichier modifié contient le motif de chaîne /\beval\s*\(|\bexec\s*\(/i, alors :- Ajoutez un Bug bloquant intitulé "Exécution dynamique dangereuse" avec la description :  "Une utilisation de eval/exec a été détectée. Remplacez-la par des alternatives sûres ou justifiez-la par un commentaire détaillé et des tests."- Assignez le Bug à l’auteur de la PR.- Appliquez le label "security".

Si la PR modifie des fichiers de dépendances (package.json, pnpm-lock.yaml, yarn.lock, requirements.txt, go.mod, Cargo.toml), alors :- Exécutez l’analyse de licences intégrée.- Si une dépendance nouvelle ou mise à niveau possède une licence parmi {GPL-2.0, GPL-3.0, AGPL-3.0}, alors :  - Ajoutez un Bug bloquant intitulé "Licence non autorisée détectée"  - Incluez les noms, versions et licences des packages concernés dans la description du Bug  - Appliquez les labels "compliance" et "security"

Pour les fichiers correspondant à **/*.{js,jsx,ts,tsx} dans les projets React :Si un fichier modifié contient /componentWillMount\s*\(/, alors :- Ajoutez un Bug bloquant intitulé "Méthode de cycle de vie React dépréciée"- Description : "Remplacez componentWillMount par constructor ou useEffect. Voir la documentation React."- Proposez un extrait d’Autofix qui migre les effets de bord vers useEffect.

Si la PR modifie des fichiers dans {server/**, api/**, backend/**} et qu’il n’y a aucune modification dans {**/*.test.*, **/__tests__/**, tests/**}, alors :- Ajoutez un Bug bloquant intitulé "Tests manquants pour les modifications du backend"- Description : "Cette PR modifie du code backend, mais n’inclut aucun test associé. Veuillez ajouter ou mettre à jour des tests."- Appliquez le label "quality"

Si un fichier modifié contient /(?:^|\s)(TODO|FIXME)(?:\s*:|\s+)/, alors :- Ajoutez un Bug non bloquant intitulé "Commentaire TODO/FIXME détecté"- Description : "Remplacez TODO/FIXME par une référence à une issue suivie, par ex., `TODO(#1234): ...`, ou supprimez-le."- Si le TODO fait déjà référence à une issue correspondant au motif /#\d+|[A-Z]+-\d+/, marquez automatiquement le Bug comme résolu.

Exécuter dans votre agent

Utilisez les compétences /review-bugbot ou /review pour lancer Bugbot depuis votre agent avant de pousser le code.

Diff passé en revue : Par défaut, /review-bugbot passe en revue les modifications de votre branche : toutes les modifications par rapport à la branche de base, qu’elles soient validées ou non. Demandez-lui de passer en revue uniquement vos modifications non validées pour obtenir des retours plus ciblés.

Branche de comparaison : /review-bugbot compare votre branche à votre branche de base par défaut. Si votre branche de base n’est pas celle par défaut (par exemple main), indiquez à l’agent la branche à utiliser pour la comparaison ou laissez-le la déduire du contexte.

Synchronisation avec votre pull request

Les revues /review-bugbot restent synchronisées avec Bugbot sur votre SCM connecté (GitHub, GitLab ou Bitbucket).

En interne, /review-bugbot enregistre l’ID de patch du diff passé en revue. Lorsque Bugbot sur votre SCM détecte un diff avec le même ID de patch, il ignore la revue et ajoute un commentaire indiquant qu’il a déjà passé ce diff en revue.

Cas d’utilisation courant : exécutez /review-bugbot, puis ouvrez une pull request contenant le même diff. Bugbot reconnaît alors la revue et ignore la revue de PR distante.

Correction automatique

Bugbot Autofix lance automatiquement un agent cloud pour corriger les bugs détectés lors des revues de PR.

Fonctionnement

Lorsque Bugbot détecte des bugs lors d'une review de PR, il peut automatiquement :

1. Lancer un agent cloud pour analyser et corriger les issues signalées
2. Pousser les correctifs vers la branche existante ou une nouvelle branche (selon vos paramètres)
3. Publier un commentaire sur la PR d'origine avec les résultats

Configuration

Configurez le comportement d’Autofix dans l’automatisation Bugbot.

Prérequis

Autofix nécessite :

• L’activation de la tarification à la demande
• L’activation du stockage (sauf en mode de confidentialité ancien)

Facturation

Autofix utilise des crédits d’agent cloud et vous est facturé aux tarifs de votre forfait. La facturation de l’agent cloud est régie par votre forfait tarifaire.

Prise en charge de MCP

Bugbot s’intègre à vos serveurs MCP, afin que vos outils d’IA puissent interagir directement avec lui. Utilisez le serveur MCP pour fournir des outils supplémentaires et guider le processus de revue de Bugbot.

Pour commencer :

1. Consultez la documentation MCP pour obtenir les instructions de configuration du serveur MCP.
2. Ajoutez les outils à Bugbot dans l’automatisation.

API d'administration de la configuration

Les administrateurs d'équipe peuvent utiliser l'API d'administration de Bugbot pour gérer les dépôts et contrôler quels utilisateurs peuvent utiliser Bugbot. Utilisez-la pour automatiser la gestion des dépôts, activer Bugbot dans plusieurs dépôts ou intégrer le provisionnement des utilisateurs aux outils internes.

Authentification

Tous les endpoints nécessitent une clé API d’administration de l’équipe, transmise sous forme de token Bearer :

Authorization: Bearer $API_KEY

Pour créer une clé API :

1. Accédez aux clés API dans le tableau de bord Cursor
2. Cliquez sur Nouvelle clé API
3. Enregistrez la clé API

Tous les endpoints sont limités à 60 requêtes par minute et par équipe.

Activer ou désactiver des dépôts

Utilisez l’endpoint /bugbot/repo/update pour activer ou désactiver Bugbot pour un dépôt :

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

Paramètres :

• repoUrl (string, required) : URL complète du dépôt
• enabled (boolean, required) : true pour activer Bugbot, false pour le désactiver
• manualTriggerOnly (boolean, optional) : Lorsque cette valeur est définie sur true, Bugbot ne s’exécute pas automatiquement lors des mises à jour de la PR de ce dépôt. Les déclenchements manuels, par exemple en ajoutant le commentaire cursor review ou bugbot run, fonctionnent toujours.

Lister les dépôts

Utilisez l’endpoint /bugbot/repos pour obtenir la liste de tous les dépôts et leurs paramètres Bugbot pour votre équipe :

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

La réponse inclut, pour chaque dépôt, son statut d’activation, son paramètre « manuel uniquement » et ses horodatages.

Gestion des accès utilisateurs

Utilisez l’endpoint /bugbot/user/update pour définir quels utilisateurs GitHub, GitLab ou Bitbucket peuvent utiliser les licences Bugbot de votre équipe. Les entreprises l’utilisent pour intégrer le provisionnement de Bugbot à leurs outils internes de demande d’accès.

Prérequis

Avant d’appeler cet endpoint, activez le mode liste d’autorisation ou liste de blocage dans les paramètres Bugbot de votre équipe :

• Mode liste d’autorisation (« Seulement... ») : seuls les utilisateurs figurant sur la liste peuvent utiliser Bugbot
• Mode liste de blocage (« Tout le monde sauf... ») : tous les utilisateurs peuvent utiliser Bugbot, sauf ceux figurant sur la liste

Si aucun de ces deux modes n’est activé, l’API renvoie une erreur.

Ajouter ou supprimer un utilisateur

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

Paramètres :

• username (string, obligatoire) : le nom d’utilisateur GitHub, GitLab ou Bitbucket (insensible à la casse)
• allow (boolean, obligatoire) : indique s’il faut accorder ou révoquer l’accès

Le comportement de allow dépend du mode actif :

Réponse :

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

Exemple : provisionnement des utilisateurs via un outil interne

Connectez cette API à un portail interne de demande d’accès. Lorsqu’un employé demande l’accès à Bugbot, le portail appelle l’API pour lui accorder l’accès. Lorsqu’il quitte l’entreprise ou perd ses droits d’accès, le portail appelle l’API pour les lui retirer.

Accorder l’accès :

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

Révoquer l’accès :

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

Tarification

Bugbot utilise la facturation à l’usage.

Facturation

Dépannage

Si Bugbot ne fonctionne pas :

1. Activez le mode verbeux en ajoutant le commentaire cursor review verbose=true ou bugbot run verbose=true pour obtenir des logs détaillés, la liste des règles Bugbot chargées et un ID de requête
2. Vérifiez les autorisations pour vous assurer que Bugbot a accès au dépôt
3. Vérifiez l’installation pour confirmer que l’intégration de votre fournisseur de dépôt est installée et activée

Incluez l’ID de requête du mode verbeux lorsque vous signalez des issues.

FAQ