Cursor YOLO mode en 2026 : ce que sont devenus Auto-run, Auto-review et Run Everything

Le YOLO mode de Cursor a-t-il été supprimé ?

Non. Le YOLO mode de Cursor, apparu avec la version 0.44 en décembre 2024, a été renommé Auto-run en mars 2025 et survit sous la forme du mode Run Everything, dans Settings > Agents > Approvals & Execution. Depuis Cursor 3.6 (mai 2026), le mode par défaut est Auto-review, et c'est pour cela que l'ancienne case YOLO a disparu. Le parcours complet, d'après le changelog de Cursor :

Sources : le changelog de Cursor et la documentation des modes d'exécution, consultés le 18 octobre 2026.

Si vous avez suivi un tutoriel de 2025 et ne trouvez ni l'interrupteur « YOLO » ni l'interrupteur « Auto-run », voilà pourquoi. Les modes se trouvent désormais dans Settings > Agents > Approvals & Execution.

Que permettent les modes d'auto-run de Cursor ?

Cursor a aujourd'hui trois modes d'exécution, qui ont succédé au réglage Auto-run. Auto-review exécute les appels de l'allowlist et les commandes shell compatibles avec la sandbox, et un modèle classifieur juge le reste. Allowlist n'exécute que ce qui figure sur votre liste et demande pour tout le reste. Run Everything exécute chaque appel d'outil sans sandbox, sans classifieur et sans approbation. Les trois modes s'appliquent aux commandes shell, aux appels d'outils MCP et aux requêtes web.

Le tableau masque trois détails qui décident de la sûreté réelle de chaque mode.

D'abord, les appels de l'allowlist contournent la sandbox. La documentation des modes d'exécution de Cursor est explicite : les appels shell, Fetch et MCP de l'allowlist s'exécutent hors de la sandbox. Une entrée large comme npx, zsh ou même find donne à l'agent les pleins droits sur tout ce qui commence par elle. L'équipe de Cursor a elle-même pris ces trois exemples pour expliquer pourquoi elle avait construit la sandbox plutôt qu'une allowlist plus fine.

Ensuite, le classifieur est un modèle qui juge un autre modèle. En Auto-review, Cursor envoie à un classifieur tout ce qui n'est ni dans l'allowlist ni compatible avec la sandbox (Cursor cite Gemini 3.5 Flash Lite, avec Haiku en secours). Selon Cursor, il bloque environ 4 % des actions. Sa documentation ajoute deux phrases à garder en tête : Auto-review « n'est pas une frontière de sécurité » et « le classifieur peut se tromper ».

Enfin, Ask Every Time existe encore pour certains utilisateurs. Les nouveaux utilisateurs ne peuvent plus le choisir depuis la 3.5 ; l'équivalent est Allowlist avec une liste vide. Ceux qui l'avaient le conservent, et l'équipe de Cursor le recommandait encore en octobre 2026, après l'effacement d'un disque.

Comment activer le YOLO mode dans Cursor aujourd'hui ?

Pour activer le YOLO mode dans Cursor, ouvrez Settings > Agents > Approvals & Execution et choisissez Run Everything. C'est le comportement YOLO : aucune demande, aucune sandbox, aucun classifieur. Si l'option n'apparaît pas, un administrateur d'équipe l'a probablement désactivée (les administrateurs Enterprise peuvent masquer Run Everything et verrouiller le mode), ou votre version de Cursor est antérieure aux modes actuels.

Dans le Cursor CLI, --yolo (alias --force) et la commande /auto-run activent Run Everything ; depuis février 2026, --yolo approuve automatiquement « de manière cohérente pour la confiance, MCP et les approbations de commandes ». --auto-review et /auto-review sélectionnent Auto-review à la place.

Lisez les deux sections suivantes avant de l'activer : les protections qui semblent répondre aux risques de Run Everything couvrent moins que ce que leur nom laisse croire.

Que bloque réellement la sandbox de Cursor ?

Sur macOS et Linux, la sandbox de Cursor limite les écritures des commandes shell à l'espace de travail et bloque l'accès réseau, sauf vers les domaines que vos réglages autorisent. Elle protège en écriture des fichiers comme .git/hooks et .cursor/*.json. Par défaut, elle ne limite pas les lectures, et les commandes de l'allowlist la contournent entièrement. Les shells Windows natifs n'ont pas de sandbox en octobre 2026.

La sandbox est appliquée par le système d'exploitation, pas par le modèle, et c'est pour cela qu'elle tient quand l'agent est manipulé. Sur macOS, Cursor utilise Seatbelt via sandbox-exec. Sur Linux, il utilise Landlock et seccomp, et exige un noyau 6.2 ou plus récent avec les user namespaces non privilégiés ; sur un noyau plus ancien, Cursor se replie sur une demande avant chaque commande. Sous Windows natif, l'équipe de Cursor a indiqué en juillet, puis de nouveau en octobre 2026, que les commandes de terminal ne s'exécutent pas dans une sandbox ; la voie documentée est WSL2 ou un dev container.

Ce qu'une commande en sandbox peut faire ou non, avec les réglages par défaut de Cursor :

• Écritures : dans l'espace de travail uniquement. Certains chemins restent protégés en écriture même là : .cursor/*.json, .git/hooks/, .git/config, .vscode/ et .cursorignore.
• Réseau : bloqué, puis ouvert selon votre réglage réseau. Le réglage par défaut ajoute la liste de domaines développeur de Cursor, qui inclut github.com, *.googleapis.com et registry.npmjs.org. Les adresses privées et l'endpoint de métadonnées cloud restent bloqués.
• Lectures : la frontière de lecture par défaut est le système entier, et la référence de Cursor précise que ~/.ssh y est « toujours lisible ». Ce n'est que depuis la 3.23 que vous pouvez limiter cette frontière à l'espace de travail.
• Fichiers temporaires : /tmp et les dossiers temporaires de la plateforme sont inscriptibles, sauf si vous le désactivez.

Et trois façons d'en sortir, toutes documentées :

1. L'allowlist, comme vu plus haut : les appels de l'allowlist n'entrent jamais dans la sandbox.
2. La relance. Quand une commande échoue sur une restriction de la sandbox, l'agent peut la relancer en dehors. En Auto-review, le classifieur examine cette relance ; dans les autres modes, la question vous est posée.
3. La configuration propre au dépôt. Le .cursor/sandbox.json d'un projet a priorité sur le vôtre, et "type": "insecure_none" désactive entièrement la sandbox. Les politiques d'administration d'une équipe ne peuvent pas être affaiblies par des fichiers locaux, mais un développeur seul n'a pas d'administrateur.

La sandbox a aussi connu de vraies évasions, toutes corrigées : l'écriture de hooks git pour exécuter du code hors de la sandbox (CVE-2026-26268, corrigée en 2.5), un répertoire de travail et des liens symboliques qui pointaient hors de l'espace de travail (CVE-2026-50548 et CVE-2026-50549, corrigées en 3.0), et un wrapper de virtualenv Python lancé par une extension de l'éditeur (CVE-2026-73217, corrigée en 3.1.2). Gardez Cursor à jour. Notre guide des évasions de sandbox des agents de code décrit le schéma d'un outil à l'autre.

Le mode Run Everything (YOLO) de Cursor est-il sûr ?

Pas sur une machine à laquelle vous tenez. Run Everything n'a ni sandbox ni classifieur : l'agent agit avec votre identité, vos tokens et vos fichiers, et la seule chose qui sépare une mauvaise commande de son effet est la décision du modèle de ne pas la lancer. Le forum de Cursor recense des disques entiers supprimés dans ce mode en octobre 2026. C'est raisonnable sur une machine jetable, et risqué partout ailleurs.

Le forum de Cursor montre à quoi cela ressemble. Entre mars et octobre 2026, au moins six utilisateurs Windows ont signalé avoir perdu un disque ou l'essentiel de leurs fichiers à cause d'une commande de l'agent, plusieurs d'entre eux selon le même schéma : un cmd /c "rmdir /s /q ..." dont les guillemets se sont cassés, si bien que le chemin s'est réduit à la racine du disque. L'équipe a répondu que cela correspondait à « un problème que nous suivons déjà ». Deux de ces signalements sont arrivés la même semaine d'octobre 2026 : le 13 octobre, un utilisateur a perdu un disque en Auto-review, et l'équipe a répondu qu'Auto-review « aurait dû arrêter une commande récursive de ce genre et demander d'abord » ; le 17 octobre, un utilisateur a perdu un disque de 1 To en Run Everything, mode dans lequel, selon les mots de l'équipe, « tous les appels d'outils s'exécutent automatiquement, sans approbation, sandbox ni classifieur ». En avril 2026, The Register a rapporté qu'un agent Cursor avait supprimé la base de données de production d'une start-up, et ses sauvegardes, en appelant l'API d'un hébergeur avec un token trouvé dans un fichier sans rapport. L'article ne précise pas quel mode d'exécution était actif.

Deux protections dont on attendrait qu'elles aident, et qui n'ont pas aidé :

• File-Deletion Protection couvre l'outil de suppression de fichiers propre à l'agent. L'équipe a confirmé en octobre 2026 qu'elle ne s'applique pas « aux commandes de terminal comme rd ou rmdir ». De plus, les suppressions faites depuis le terminal ne sont « PAS couvertes par les checkpoints de Cursor ni par l'historique local » : aucun retour en arrière possible.
• External-File Protection empêche l'agent de créer ou de modifier des fichiers hors de l'espace de travail via ses outils de fichiers. Elle « ne bloque pas la lecture des fichiers hors de l'espace de travail », et elle ne régit pas ce que fait une commande de terminal.

Cursor durcit peu à peu ces protections : depuis août 2026, Auto-review bloque les suppressions récursives et forcées au lieu de les exécuter automatiquement, et le CLI du 8 octobre 2026 demande avant les suppressions « dont la cible pourrait se résoudre autrement qu'elle n'est écrite ». Le signalement du 13 octobre montre pourquoi la documentation ne la présente pas comme une garantie.

Nos propres données sur les agents laissés sans garde-fou vont dans le même sens. Dans notre étude précédente, où des agents construisaient une plateforme sur une base de données applicative vivante, deux configurations sans garde-fou ont exécuté DROP SCHEMA sur cette base dix-huit fois au total.

6+

disques ou dossiers Windows effacés par un agent Cursor, signalés sur son forum de mars à octobre 2026

4 %

part des actions que le classifieur d'Auto-review bloque, selon Cursor

18

exécutions de DROP SCHEMA contre une base vivante par des agents sans garde-fou, dans notre étude précédente

Pourquoi l'allowlist n'est-elle pas une frontière de sécurité ?

L'allowlist compare le texte d'une commande, et une même commande peut s'écrire de bien des façons. La documentation de Cursor le dit sans détour : « L'allowlist fonctionne au mieux, ce n'est pas une frontière de sécurité. Des agents déterminés ou une prompt injection peuvent la contourner. » Voici comment fonctionne la correspondance aujourd'hui :

• Les entrées sont des préfixes, sensibles à la casse : git correspond à git status mais pas à gitk. npm:install* sépare la commande d'un motif d'argument. Il n'y a pas d'expression régulière.
• Une chaîne est vérifiée commande par commande : cd api && npm test | tail -20 ne s'exécute seule que si cd, npm et tail figurent chacun sur la liste.
• Les commandes de l'allowlist s'exécutent hors de la sandbox : une seule entrée large annule donc la sandbox pour tout ce qu'elle préfixe.

L'historique des contournements est long et public. À l'époque du YOLO mode, des commandes chaînées passaient à travers les deux listes, ce qui explique que Cursor ait abandonné la denylist en 1.3. Depuis, Cursor a publié des avis de sécurité pour un contournement de l'allowlist par backticks et $(...) (CVE-2025-54131), pour des commandes intégrées du shell qui s'exécutaient sans figurer sur la liste (CVE-2026-22708), et pour une exécution de commandes sous « Use AllowList » via une prompt injection venue d'un site web (CVE-2026-31854). En août 2026, un utilisateur a montré deux formes PowerShell qui exécutaient automatiquement des commandes arbitraires derrière une entrée de l'allowlist ; l'équipe les a transmises aux développeurs, puis a indiqué fin septembre que les blocs de script demandent désormais toujours une approbation.

Pourquoi l'auto-run ou l'allowlist de Cursor ne marche pas ?

Si Cursor continue de demander une approbation ou semble ignorer votre allowlist, la cause est en général l'une de celles-ci :

• Une terminalAllowlist non vide dans ~/.cursor/permissions.json verrouille le mode sur Allowlist et rend Auto-review indisponible (équipe de Cursor, août 2026).
• Une commande chaînée ne s'exécute sans demande que si chacune de ses commandes figure sur la liste.
• Sur Linux, la sandbox exige un noyau 6.2 ou plus récent avec les user namespaces non privilégiés. Sans eux, Cursor demande avant chaque commande.
• Un administrateur d'équipe a verrouillé le mode d'exécution ou masqué Run Everything.
• Dans l'ancien mode Run in Sandbox, l'allowlist n'était pas appliquée du tout, parce que, selon l'équipe, « la sandbox est censée remplacer l'allowlist ».

Le .cursorignore protège-t-il vos fichiers .env dans Cursor ?

En partie seulement : une commande de terminal exécutée hors de la sandbox peut toujours faire cat .env. .cursorignore masque des fichiers aux outils de fichiers de l'agent, à Tab et aux mentions @, et la liste d'exclusion par défaut de Cursor inclut déjà .env*. Mais la documentation est claire sur le reste : « Les outils de terminal et de serveur MCP utilisés par l'agent ne peuvent pas bloquer l'accès au code régi par .cursorignore. » Dans la sandbox, les fichiers listés dans .cursorignore sont illisibles : ajoutez donc .env* vous-même plutôt que de compter sur la liste par défaut. Hors de la sandbox, c'est-à-dire en Run Everything, pour les commandes de l'allowlist, pour les sorties approuvées et sous Windows natif, cat .env fonctionne.

Si un fichier ne doit jamais atteindre le modèle, gardez-le hors de l'espace de travail ou bloquez la lecture elle-même : c'est ce que font les deux sections suivantes. Pour la même question dans Claude Code, voyez ce que Claude Code envoie à Anthropic.

Quel mode d'exécution choisir dans Cursor ?

Sur un poste de développeur aujourd'hui, voici la configuration que nous utiliserions :

1. macOS ou Linux : Auto-review avec la sandbox activée. Limitez l'allowlist aux commandes en lecture seule (git status, git diff, ls) et définissez-la dans l'interface des réglages plutôt que dans permissions.json si vous voulez qu'Auto-review reste disponible.
2. Fermez les lectures et le réseau dans ~/.cursor/sandbox.json (la frontière de lecture exige Cursor 3.23 ou plus récent), et ne choisissez le réglage réseau qui s'appuie uniquement sur sandbox.json que si vous ne voulez pas des domaines par défaut de Cursor :

{
  "readBoundary": "workspace",
  "networkPolicy": {
    "default": "deny",
    "allow": ["registry.npmjs.org", "pypi.org", "files.pythonhosted.org"]
  }
}

Si une chaîne d'outils a besoin d'un fichier hors du projet, ajoutez-le à additionalReadPaths plutôt que de rouvrir tout le système. 3. Windows natif : Allowlist avec une liste vide, ou déplacez le projet dans WSL2 ou dans un dev container, là où la sandbox existe. 4. Équipes : imposez-le de façon centralisée. Le guide de durcissement de Cursor recommande de régler le mode d'exécution de l'organisation « sur Auto-review (pas Run Everything) » avec la sandbox activée, et de distribuer les hooks depuis le dashboard. Notez que dans les groupes d'une organisation, c'est le réglage de sandbox le plus permissif qui l'emporte. 5. Run Everything uniquement là où la machine est jetable :

Conteneur ou VM neuf, clone jetableAucun token durable ni identifiant cloud à l'intérieurSortie réseau limitée aux registres nécessairesAlors, et seulement alors, Run Everything

Les Cloud Agents de Cursor suivent déjà ce modèle : chacun tourne dans sa propre microVM et ne demande jamais d'approbation, avec un accès internet activé par défaut tant que vous ne le restreignez pas.

Les hooks de Cursor fonctionnent-ils encore en mode Run Everything ?

Oui, et c'est ce qui en fait le seul contrôle qui survit à tous les modes d'exécution. Un hook est un script que Cursor appelle avant une action ; il peut répondre deny, et l'action ne s'exécute pas. Interrogée le 17 octobre 2026 sur la façon de protéger une configuration Run Everything contre les suppressions récursives, l'équipe de Cursor a répondu : « La principale protection, dans ce cas, c'est le hook. »

Voici un hook minimal au niveau utilisateur, qui refuse les suppressions récursives dans tous les shells qu'utilise Cursor. Dans ~/.cursor/hooks.json :

{
  "version": 1,
  "hooks": {
    "beforeShellExecution": [
      { "command": "node ./hooks/block-recursive-delete.mjs", "timeout": 5, "failClosed": true }
    ]
  }
}

Et ~/.cursor/hooks/block-recursive-delete.mjs (les chemins des hooks utilisateur se résolvent depuis ~/.cursor/) :

let raw = "";
for await (const chunk of process.stdin) raw += chunk;
const { command = "" } = JSON.parse(raw || "{}");

const RECURSIVE_DELETE = [
  /\brm\s+(-[a-zA-Z]*[rR][a-zA-Z]*|--recursive)\b/, // rm -rf, rm -r, rm --recursive
  /\b(rmdir|rd)\s+\/s\b/i,                         // cmd: rmdir /s, rd /s
  /\bdel\s+(\/\w\s+)*\/s\b/i,                      // cmd: del /s
  /\bRemove-Item\b[^|;&]*-Recurse\b/i,             // PowerShell
];

if (RECURSIVE_DELETE.some((re) => re.test(command))) {
  console.log(JSON.stringify({
    permission: "deny",
    user_message: `Blocked a recursive delete: ${command}`,
    agent_message: "Recursive deletes are blocked on this machine. Delete files by explicit path, or ask the user to run the command.",
  }));
} else {
  console.log(JSON.stringify({ permission: "allow" }));
}

Trois limites à connaître avant de vous y fier, toutes rapportées par l'équipe de Cursor :

• Seul deny est appliqué. En mars 2026, l'équipe a écrit que « les hooks n'appliquent que la permission deny. Allow et ask sont en pratique ignorés. » C'est pour cela que le script répond allow pour tout le reste : il laisse la décision à votre mode d'exécution. Ne comptez pas sur ask pour faire réapparaître une demande.
• Une race condition connue peut faire sauter un deny. En juillet 2026, l'équipe a confirmé qu'un hook preToolUse qui renvoie deny peut perdre une course, et que la commande s'exécute alors, en ajoutant : « s'il vous plaît, ne comptez pas sur un hook deny seul comme blocage absolu. » Le problème était toujours ouvert en septembre.
• Les hooks ne voient pas le mode d'exécution. Le script ne peut pas se durcir uniquement en Run Everything.

Et une limite de la méthode elle-même : un motif est une alarme, pas une frontière. Il attrape les formes que vous avez écrites, rate une suppression cachée dans un fichier de script ou écrite autrement, et se déclenche aussi sur des commandes inoffensives. Nous l'avons testé sur un jeu de commandes d'exemple : il a refusé rm -rf node_modules et git rm -r --cached en même temps que les vrais effacements. Gardez la sandbox en dessous.

La brèche qu'aucun mode d'exécution ne ferme

Chaque réglage de ce guide gouverne ce que Cursor a le droit d'exécuter. Aucun ne gouverne ce que Cursor écrit, et l'essentiel du risque du code écrit par une IA se trouve dans le diff, pas dans le terminal. Auto-review laissera volontiers l'agent enregistrer un endpoint sans contrôle d'autorisation, un gestionnaire de remboursement sans plafond ou une requête construite par concaténation de chaînes, parce qu'aucun de ces éléments n'est une commande. Ce sont des failles de logique métier, et un réglage du terminal ne les voit pas. Les agents commencent aussi chaque session sans les règles de votre équipe, à moins que quelque chose ne les leur présente au moment où ils écrivent.

C'est la couche que VibeDefend ajoute dans Cursor. Une seule commande l'installe sur la machine : elle sert vos règles métier et de sécurité à l'agent pendant qu'il écrit, vérifie le diff avant le commit, et fait tourner ses gardes sous forme de hook Cursor avant chaque appel d'outil, quel que soit le mode d'exécution. Par défaut, ils refusent la lecture des fichiers .env, des clés SSH et des identifiants cloud, rm -rf sur une racine ou un répertoire personnel, les force-push, les instructions DROP et les téléchargements redirigés vers un shell. Ce garde est le même genre d'alarme que le hook ci-dessus, maintenu pour vous, avec les mêmes limites : dans notre étude contrôlée du 24 août 2026, il a vérifié 1 769 commandes shell et en a refusé dix-sept, soit une prise réelle, trois applications correctes de la politique et treize faux positifs. Sur le code lui-même, la configuration équipée de la couche a implémenté à l'identique 57 détails de règle notés sur 64 (89 %), contre 7 sur 55 (13 %) avec un fichier de règles tenu à la main et 8 sur 65 (12 %) sans rien.

Si vous lancez Cursor en Run Everything délibérément, dans un conteneur, avec un garde dans le hook, vous avez une configuration défendable. Si vous le lancez ainsi sur votre portable parce que les demandes vous agaçaient, lisez notre guide de sécurité Cursor, comparez avec ce que retire le --yolo de Codex et le --dangerously-skip-permissions de Claude Code, puis parlons-en.

Questions fréquentes

Le YOLO mode a-t-il disparu de Cursor ?

Non. Le YOLO mode a été renommé Auto-run en mars 2025. Son comportement « tout exécuter sans demander » correspond aujourd'hui au mode Run Everything, dans Settings > Agents > Approvals & Execution. Depuis Cursor 3.6, le mode par défaut est Auto-review.

Comment activer le YOLO mode sur Cursor ?

Ouvrez Settings > Agents > Approvals & Execution et choisissez Run Everything. Dans le Cursor CLI, utilisez --yolo (alias --force) ou /auto-run. Si l'option n'apparaît pas, un administrateur d'équipe l'a probablement désactivée, ou votre version de Cursor est antérieure aux modes actuels.

Auto-review dans Cursor, c'est quoi ?

Auto-review est le mode d'exécution par défaut de Cursor depuis la version 3.6 (29 mai 2026). Les appels de l'allowlist s'exécutent immédiatement, les commandes shell compatibles avec la sandbox s'exécutent dans la sandbox, et un modèle classifieur autorise le reste, le réoriente ou vous le soumet. Il couvre les appels shell, MCP et Fetch. La documentation de Cursor précise que ce n'est pas une frontière de sécurité.

Auto-review ou Run Everything : quelle différence ?

Auto-review exécute les appels de l'allowlist, lance les commandes shell dans la sandbox quand c'est possible, et envoie tout le reste à un modèle classifieur qui peut l'autoriser, proposer une autre approche ou vous demander. Run Everything exécute chaque appel d'outil sans sandbox ni classifieur.

Peut-on utiliser Run Everything sans risque ?

Seulement sur une machine jetable : un conteneur ou une VM neuf, sans identifiants durables et avec un réseau limité. Sur un poste de travail, ce mode laisse l'agent agir avec votre identité, et le forum de Cursor recense des disques entiers supprimés dans ce mode en octobre 2026.

Que bloque la sandbox de Cursor ?

Sur macOS et Linux, elle limite les écritures des commandes shell à l'espace de travail, bloque le réseau sauf vers les domaines que vos réglages autorisent, et protège des fichiers comme .cursor/*.json et .git/hooks. Par défaut, elle ne restreint pas les lectures hors de l'espace de travail ; Cursor 3.23 a ajouté une frontière de lecture Workspace. Les shells Windows natifs n'ont pas de sandbox en octobre 2026.

Allowlist ignorée ou auto-run qui ne marche pas dans Cursor : pourquoi ?

Les causes fréquentes : une terminalAllowlist non vide dans ~/.cursor/permissions.json verrouille le mode sur Allowlist et désactive Auto-review ; une commande chaînée ne s'exécute automatiquement que si chacune de ses commandes est dans l'allowlist ; sur Linux, un noyau antérieur à 6.2 ou sans user namespaces non privilégiés oblige Cursor à demander avant chaque commande ; et dans l'ancien mode Run in Sandbox, l'allowlist n'était pas appliquée du tout.

L'auto-run s'applique-t-il aussi aux outils MCP ?

Oui. Les appels d'outils MCP suivent les mêmes modes d'exécution que les commandes de terminal. En Auto-review, les outils MCP de l'allowlist (entrées server:tool, jokers acceptés) s'exécutent immédiatement et le reste passe par le classifieur. En Run Everything, ils s'exécutent tous.

Cursor peut-il lire mon .env malgré le .cursorignore ?

Oui, depuis le terminal. .cursorignore masque des fichiers aux outils de fichiers de l'agent et aux mentions, et .env* figure dans la liste d'exclusion par défaut de Cursor, mais la documentation de Cursor indique que les outils de terminal et MCP ne peuvent pas bloquer l'accès aux fichiers exclus. Une commande en sandbox ne peut pas lire les fichiers listés dans .cursorignore ; une commande de l'allowlist, le mode Run Everything ou un shell Windows natif le peuvent.