Tous les modes ne sont pas dans le cycle par défaut :

• auto : apparaît quand le mode auto est disponible ; basculer vers celui-ci change les modes de permission sans invite de confirmation
• bypassPermissions : apparaît après que vous ayez démarré avec --permission-mode bypassPermissions, --dangerously-skip-permissions, --allow-dangerously-skip-permissions, ou permissions.defaultMode: "bypassPermissions" dans les paramètres utilisateur, --settings, ou gérés. La variante --allow- ajoute le mode de permission au cycle sans l'activer
• dontAsk : n'apparaît jamais dans le cycle ; définissez-le avec --permission-mode dontAsk

Les modes optionnels activés s'insèrent après plan, avec bypassPermissions en premier et auto en dernier. Si vous avez les deux activés, vous parcourrez bypassPermissions en allant vers auto.

À partir d'une invite de permission Bash : en modes de permission Manuel et acceptEdits, quand le mode auto est disponible, Claude Code ajoute Oui, et basculer vers le mode auto à l'invite de permission d'une commande Bash. Sélectionnez-le pour approuver la commande et basculer la session vers le mode auto. Les invites de l'outil PowerShell n'offrent pas l'option. Nécessite Claude Code v2.1.247 ou version ultérieure.

Claude Code n'ajoute pas l'option aux invites forcées par l'une de vos règles ask ou par un hook, car le mode auto vous montre toujours ces invites, donc basculer ne les supprimerait pas.

Au démarrage : passez le mode de permission en tant que drapeau.

claude --permission-mode plan

Comme valeur par défaut : définissez permissions.defaultMode à la portée que vous souhaitez, comme décrit dans Démarrer dans un mode de permission différent.

Le même drapeau --permission-mode fonctionne avec -p pour les exécutions non-interactives.

VS Code

En cours de session : cliquez sur l'indicateur de mode en bas de la zone de saisie. Il utilise ces étiquettes pour les modes sur cette page :

Comme valeur par défaut : pour épingler le mode de permission dans lequel les conversations démarrent, définissez claudeCode.initialPermissionMode dans vos paramètres utilisateur VS Code sur default, manual, acceptEdits, plan, ou bypassPermissions. Le paramètre n'accepte pas auto ; pour démarrer en Auto, laissez-le non défini et choisissez Auto à partir de l'indicateur de mode une fois, comme l'élément 2 ci-dessous le décrit. L'extension démarre chaque nouvelle conversation dans le premier de ces éléments qui s'applique :

1. claudeCode.initialPermissionMode
2. Le mode que vous avez choisi en dernier à partir de l'indicateur de mode, s'il s'agissait de Manuel, Éditer automatiquement, ou Auto. Choisir Plan ou Bypass permissions s'applique à cette conversation uniquement
3. permissions.defaultMode à partir des paramètres gérés ou ~/.claude/settings.json
4. La valeur par défaut intégrée pour votre plan, fournisseur et paramètres d'organisation

L'extension ne lit jamais le .claude/settings.json ou .claude/settings.local.json d'un projet pour le mode de permission de démarrage. Quand claudeCode.claudeProcessWrapper est défini, les éléments 3 et 4 ne s'appliquent pas : ces conversations démarrent en Manuel sauf si l'élément 1 ou l'élément 2 définit un mode de permission.

Avant v2.1.283, l'élément 3 s'appliquait uniquement sur les plans Pro, Max et Team dans les sessions qui récupèrent les drapeaux de fonctionnalité.

Auto apparaît dans l'indicateur de mode quand le mode auto est disponible.

Bypass permissions nécessite le bouton bascule Allow dangerously skip permissions dans les paramètres de l'extension. Sans lui, le mode de permission n'apparaît pas dans l'indicateur, et une valeur bypassPermissions de l'élément 1 ou l'élément 3 démarre la conversation en Manuel à la place. Auto de n'importe quel élément démarre également la conversation en Manuel quand le mode auto n'est pas disponible.

Voir le guide VS Code pour les détails spécifiques à l'extension.

JetBrains

Le plugin JetBrains exécute Claude Code dans le terminal de l'IDE, donc basculer les modes de permission fonctionne de la même manière que dans la CLI : appuyez sur Shift+Tab pour parcourir, ou passez --permission-mode lors du lancement.

Desktop

En cours de session : dans l'onglet Code, utilisez le sélecteur de mode dans la rangée sous la zone de saisie. Tous les modes n'apparaissent pas dans le sélecteur :

• Auto : apparaît quand le mode auto est disponible
• Bypass permissions : nécessite le bouton bascule Allow bypass permissions mode dans les paramètres Desktop sur les plans Pro et Max ; sur les plans Team et Enterprise, la politique organisationnelle le contrôle à la place

Cowork n'utilise pas ces modes. Il dispose de ses propres modes de permission, activés séparément, et n'affiche aucun sélecteur de mode du tout jusqu'à ce qu'un mode autre que celui par défaut soit activé pour votre compte. Voir la documentation Cowork.

Pour les détails spécifiques au bureau, voir Choisir un mode de permission dans le guide Desktop.

Comme valeur par défaut : définissez defaultMode dans les paramètres. L'application de bureau lit les mêmes fichiers de paramètres que la CLI et applique le mode de permission aux nouvelles sessions locales.

Un mode que vous choisissez dans le sélecteur de mode est mémorisé par dossier et prend précédence sur defaultMode pour ce dossier. Plan est l'exception : le choisir s'applique à la session actuelle uniquement.

Pour savoir où placer defaultMode dans un fichier de paramètres, voir l'exemple sous Démarrer dans un mode de permission différent.

Web and mobile

Sur claude.ai/code, utilisez la liste déroulante de mode dans la rangée sous la zone de saisie. Dans l'application mobile, appuyez sur le bouton + dans la zone de saisie, puis sur Permission. Les sessions cloud et les sessions Remote Control proposent des modes de permission différents :

• Sessions cloud : Accept edits, Plan et Auto. Accept edits correspond au mode default : les sessions cloud pré-approuvent les modifications de fichiers quel que soit le mode, donc la liste déroulante affiche Accept edits au lieu de Manual. Les sessions cloud honorent toujours defaultMode: "acceptEdits" à partir des paramètres. Le mode Auto n'apparaît que quand votre organisation le permet et que le modèle sélectionné le supporte. Bypass permissions n'est pas disponible.
• Sessions Remote Control sur votre machine locale : Manual, Accept edits, Plan et Auto pour une session que vous avez démarrée vous-même, et vous ne pouvez pas sélectionner Bypass permissions à partir de l'application. Pour utiliser Auto, la session doit satisfaire les conditions de disponibilité du mode auto. Pour un fil de projet s'exécutant sur votre ordinateur, voir Exécuter un fil sur votre propre ordinateur.
  • Sauf pour Bypass permissions, la liste déroulante affiche le mode de permission dans lequel se trouve la session locale, y compris un mode défini à partir du terminal. Elle se met à jour quand le mode de permission change dans l'application ou dans le terminal.
  • Les sessions hébergées par l'application de bureau ou l'extension VS Code signalent les changements de mode de permission à claude.ai au fur et à mesure qu'ils se produisent, de la même manière que les sessions hébergées dans un terminal.

Pour Remote Control, la machine locale exécutant la session doit être connectée avec votre compte claude.ai ; les clés API ne sont pas supportées. Vous pouvez également définir le mode de permission de démarrage lors du lancement de cette session locale :

claude remote-control --permission-mode acceptEdits

Auto-approuver les modifications de fichiers avec le mode acceptEdits

Le mode acceptEdits permet à Claude de créer et modifier des fichiers dans votre répertoire de travail sans inviter. La barre d'état affiche ⏵⏵ accept edits on tandis que ce mode est actif.

En plus des modifications de fichiers, le mode acceptEdits auto-approuve les commandes Bash courantes du système de fichiers : mkdir, touch, rm, rmdir, mv, cp, et sed. À l'exception de touch, ces commandes sont également auto-approuvées quand elles sont préfixées par des variables d'environnement sûres telles que LANG=C ou NO_COLOR=1, ou des wrappers de processus tels que timeout, nice, ou nohup. Comme pour les modifications de fichiers, l'auto-approbation s'applique uniquement aux chemins à l'intérieur de votre répertoire de travail ou additionalDirectories.

Les éléments suivants invitent toujours :

• Les chemins en dehors de cette portée
• Les écritures vers les chemins protégés
• Les suppressions de chemins critiques reconnues par rm et rmdir
• touch avec autre chose que de simples chemins de fichiers, par exemple une option, un glob ou un préfixe tel que timeout 5 ou LANG=C
• Toutes les autres commandes Bash sauf l'ensemble intégré en lecture seule

Chaque chemin passe également par la vérification des liens symboliques, donc une écriture qui se résout en dehors de cette portée n'est pas auto-approuvée non plus.

Quand l'outil PowerShell est activé, le mode acceptEdits auto-approuve également Set-Content, Add-Content, Clear-Content, et Remove-Item sur les chemins dans la portée, ainsi que leurs alias courants. Les mêmes règles de portée et de chemin protégé s'appliquent, et Remove-Item obtient sa propre vérification. Un argument positionnel qui contient un caractère de guillemet, comme l'apostrophe dans Set-Content .\notes.txt "It's done", invite toujours même sur les chemins dans la portée, car Claude Code ne peut pas valider statiquement un argument dont les lectures entre guillemets et sans guillemets diffèrent. Passez le contenu via un paramètre nommé tel que -Value pour éviter l'invite.

Utilisez acceptEdits quand vous souhaitez examiner les modifications dans votre éditeur ou via git diff après coup plutôt que d'approuver chaque modification en ligne.

Appuyez sur Shift+Tab une fois à partir du mode Manuel pour y accéder, ou démarrez directement avec celui-ci :

claude --permission-mode acceptEdits

Analyser avant de modifier avec le mode plan

Le mode plan demande à Claude de faire des recherches et de proposer des modifications sans les appliquer. Claude lit des fichiers, exécute des commandes shell pour explorer et rédige un plan, mais ne modifie pas votre code source. Sauf dans les sessions de terminal interactives où le contournement des permissions est disponible, les modifications restent bloquées jusqu'à ce que vous approuviez le plan.

Ce qui arrive à une commande shell pendant la planification dépend de la session, et le premier des cas suivants qui correspond s'applique :

• Sessions de terminal interactives avec le contournement des permissions disponible : ni le classifieur ni une demande de permission ne s'appliquent aux commandes de planification. Ignorer toutes les vérifications avec le mode bypassPermissions décrit les quelques éléments qui déclenchent encore une demande dans ce cas.
• Mode auto disponible et paramètre useAutoModeDuringPlan activé, ce qui est le cas par défaut : le classifieur examine les commandes shell autres que les suppressions de chemins critiques au lieu de vous demander. Les commandes approuvées s'exécutent et celles qui sont rejetées sont bloquées.
• Mode auto non disponible, ou useAutoModeDuringPlan désactivé : les commandes en dehors de l'ensemble intégré de commandes en lecture seule demandent une approbation, y compris lorsque le mode d'autorisation automatique du sandbox est activé.

Passez en mode plan en appuyant sur Shift+Tab ou en préfixant un prompt unique avec /plan. Vous pouvez également démarrer en mode plan depuis la CLI :

claude --permission-mode plan

Appuyez de nouveau sur Shift+Tab pour quitter le mode plan sans approuver de plan.

Examiner et approuver un plan

Lorsque le plan est prêt, Claude le présente et vous demande comment procéder. À partir de cette demande, vous pouvez choisir :

• Yes, and use auto mode : approuver et démarrer en mode auto. Si le mode auto n'est pas disponible pour votre session, par exemple parce que votre organisation l'a désactivé, cette option s'affiche sous la forme Yes, auto-accept edits. Si vous avez démarré la session avec le contournement des permissions activé, l'option s'affiche plutôt sous la forme Yes, and switch to BYPASS PERMISSIONS (no further prompts) for this session.
• Yes, manually approve edits : approuver et examiner chaque modification individuellement.
• No, keep planning : rester en mode plan et indiquer à Claude ce qu'il faut changer.

Approuver un plan fait quitter le mode plan et bascule la session vers le mode de permission décrit par chaque option d'approbation, de sorte que Claude commence à modifier. Pour planifier à nouveau, revenez au mode plan avec Shift+Tab, ou préfixez votre prochain prompt avec /plan.

Appuyez sur Ctrl+G pour ouvrir le plan proposé dans votre éditeur de texte par défaut et le modifier directement avant que Claude ne poursuive. Lorsque showClearContextOnPlanAccept est activé, la liste comporte une première option supplémentaire qui approuve le plan et efface le contexte de planification.

Accepter un plan donne également à la session un titre généré à partir du plan, sauf si vous avez déjà nommé la session.

Définir le mode plan par défaut

Pour faire du mode plan le mode par défaut des sessions de terminal d'un projet, définissez defaultMode sur plan dans .claude/settings.json, en le plaçant comme le montre l'exemple sous Démarrer dans un autre mode de permission. Les conversations démarrées par l'extension VS Code ne lisent pas les paramètres du projet pour le mode de permission de départ. Dans ce cas, définissez plutôt claudeCode.initialPermissionMode sur plan dans vos paramètres utilisateur VS Code.

Éliminer les demandes de permission avec le mode auto

Le mode auto permet à Claude d'exécuter sans demandes de permission répétitives. Un modèle classificateur distinct examine les actions avant leur exécution, bloquant tout ce qui dépasse votre demande, cible une infrastructure non reconnue, ou semble provenir de contenu hostile que Claude a lu. Les règles ask explicites forcent toujours une demande de permission.

Avec Claude Code v2.1.283 ou ultérieur, le mode auto est le mode de permission intégré de démarrage pour les sessions de terminal interactif et VS Code sur tous les plans et fournisseurs. Sur les versions antérieures, c'est le mode de permission intégré de démarrage uniquement sur les plans Pro, Max et Team.

Le classificateur examine également chaque message que Claude envoie à un autre agent avec SendMessage, qu'il s'agisse de texte brut ou d'un message d'équipe d'agents structuré, avant que Claude Code le livre, à la fois en mode auto et en mode plan tandis que le classificateur examine les commandes ; l'examen d'envoi nécessite Claude Code v2.1.222 ou ultérieur.

Par défaut, le classificateur n'examine pas les suppressions rm et rmdir reconnues ciblant un chemin critique, comme rm -rf / ou rm -rf ~. Chemins critiques couvre ce qui leur arrive dans chaque mode de permission.

Le mode auto encourage également Claude à continuer à travailler sans s'arrêter pour des questions de clarification, bien que Claude demande toujours quand votre prompt ou un skill s'y fient explicitement. Pour un comportement plus autonome dans un mode qui vous demande toujours la permission, définissez plutôt le style de sortie proactif.

[!WARNING]

Le mode auto réduit les demandes de permission mais ne garantit pas la sécurité. Utilisez-le pour les tâches où vous faites confiance à la direction générale, pas comme remplacement pour l'examen des opérations sensibles.

Le mode auto n'est disponible que lorsque votre compte répond à tous ces critères :

• Plan : Tous les plans.
• Organisation : sur Team et Enterprise, le mode auto est disponible par défaut. Les administrateurs peuvent le désactiver pour l'organisation en définissant permissions.disableAutoMode sur "disable" dans les paramètres gérés.
• Modèle : sur l'API Anthropic et Claude Platform sur AWS, Claude Opus 4.6 ou ultérieur, Sonnet 4.6 ou ultérieur, Haiku 5.5, ou un modèle Fable. Sur Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry et les sessions de passerelle d'applications Claude connectées, uniquement Claude Sonnet 5 ou ultérieur, Opus 4.7 ou ultérieur, Haiku 5.5, et les modèles Fable. Les modèles plus anciens, y compris Sonnet 4.5, Opus 4.5, Haiku 4.5 et les modèles claude-3, ne sont pris en charge sur aucun fournisseur.
• Fournisseur : disponible par défaut sur l'API Anthropic, Claude Platform sur AWS, Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry et les sessions de passerelle d'applications Claude connectées.

Si Claude Code signale que le mode auto n'est pas disponible, vérifiez d'abord ces exigences et si un fichier de paramètres définit disableAutoMode. Anthropic peut également avoir désactivé le mode auto côté serveur, ou le serveur peut avoir rejeté le mode auto pour votre compte. Une session qui a reçu l'une ou l'autre réponse garde le mode auto désactivé jusqu'à la fin de la session, alors démarrez une nouvelle session plus tard.

Un message distinct qui nomme un modèle et dit que le mode auto « ne peut pas déterminer la sécurité » d'une action signifie qu'une requête de classificateur a échoué. Cet échec est généralement transitoire, mais sur Amazon Bedrock, il peut se répéter jusqu'à ce que votre compte puisse invoquer le modèle nommé. Consultez la référence d'erreur pour les causes et ce qu'il faut faire.

Si vous définissez defaultMode: "auto" dans les paramètres et qu'une session de terminal démarre en mode Manual sans erreur, le paramètre est probablement dans .claude/settings.json ou .claude/settings.local.json. auto ne prend pas effet à partir de ces fichiers. Déplacez-le vers ~/.claude/settings.json. Pour une conversation que l'extension VS Code a démarrée, vérifiez plutôt la liste propre de l'extension dans Basculer les modes de permission.

Mode auto sur Bedrock, Agent Platform ou Foundry

Sur Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry et les sessions de passerelle d'applications Claude connectées, le mode auto est disponible par défaut. Si vous n'y définissez pas de mode de permission, les sessions interactives démarrent en mode auto, et les exécutions claude -p ou Agent SDK démarrent en mode Manual, dont la valeur de configuration est default :

• Sessions de terminal interactif et VS Code : pour les démarrer dans un mode de permission autre qu'auto, définissez permissions.defaultMode comme le décrit Démarrer dans un mode de permission différent, ou choisissez-en un dans l'indicateur de mode de l'extension VS Code. Dans quel mode une session démarre répertorie les versions de Claude Code qui les démarrent en mode auto.
• Exécutions claude -p et Agent SDK : pour en démarrer une en mode auto, passez --permission-mode auto à claude -p, ou passez permissionMode: "auto" en TypeScript ou permission_mode="auto" en Python. Si vous ne passez aucun mode de permission, consultez Appels d'outils refusés dans les exécutions claude -p et Agent SDK, qui couvre également les versions antérieures de Claude Code.

Seuls Claude Sonnet 5 ou ultérieur, Opus 4.7 ou ultérieur, Haiku 5.5 et les modèles Fable sont pris en charge sur ces fournisseurs. Sur tout autre modèle, la session démarre en Manual à la place. Le mode auto avec Haiku 5.5 sur ces fournisseurs nécessite Claude Code v2.1.293 ou ultérieur.

Pour empêcher les développeurs d'utiliser le mode auto, définissez disableAutoMode sur "disable" dans les paramètres gérés. Cela supprime auto du cycle Shift+Tab, et une session démarrée avec --permission-mode auto démarre en Manual à la place. Une session déjà en cours d'exécution en mode auto le quitte quand le paramètre l'atteint à partir d'une source déployée par l'administrateur, et affiche auto mode disabled by settings. Avant v2.1.251, une session en cours d'exécution gardait le mode auto jusqu'à la fin.

Examen du classificateur côté serveur

En mode auto, Claude Code peut demander au serveur de vérifier les actions que l'ordre de décision envoie pour examen, dans le cadre des requêtes de modèle de la session, à la place d'envoyer ses propres requêtes de classificateur. Ces sessions le demandent :

• Une connexion directe à l'API Anthropic : dans les sessions de terminal interactif et dans les sessions -p, Agent SDK, extension VS Code et application de bureau, quel que soit votre plan ou type de compte, au fur et à mesure qu'Anthropic le déploie. Dans les sessions de terminal interactif, cela nécessite Claude Code v2.1.271 ou ultérieur sur les plans Pro, Max et Team, et v2.1.278 ou ultérieur sur les plans Enterprise et les comptes Claude API. Dans les sessions -p, Agent SDK, extension VS Code et application de bureau, cela nécessite Claude Code v2.1.281 ou ultérieur. À partir de v2.1.282, une session qui ne récupère pas les feature flags, par exemple parce que vous avez désactivé la télémétrie, demande au serveur par défaut dans n'importe quel type de session.
• Un fournisseur cloud, une passerelle LLM ou un proxy : sur Claude Platform sur AWS, Amazon Bedrock, Google Cloud's Agent Platform et Microsoft Foundry, et chaque fois que vous pointez ANTHROPIC_BASE_URL vers une passerelle LLM ou un proxy, quel que soit votre plan. Demander par défaut nécessite Claude Code v2.1.278 ou ultérieur.
• Une session de passerelle d'applications Claude connectée : nécessite Claude Code v2.1.280 ou ultérieur
• Une session cloud dans un environnement hébergé par Anthropic : quel que soit votre plan, lorsque vous la démarrez depuis le web, l'application mobile ou l'application de bureau avec Cloud sélectionné. Les sessions démarrées par une tâche planifiée cloud interrogent le serveur au fur et à mesure qu'Anthropic le déploie.

Là où le serveur examine les actions, ses verdicts en décident. Deux autres résultats sont possibles :

• Le serveur n'examine pas la session : une réponse se termine sans résultats d'examen, ou le serveur répond qu'il n'examine pas cette session. Les causes les plus courantes sont une passerelle LLM ou un proxy qui abandonne la requête d'examen ou les résultats, et une plateforme, une région ou des identifiants qui n'ont pas encore de vérifications côté serveur. Claude Code se rabat sur ses propres requêtes de classificateur. Une fois que cette solution de repli est maintenue pour le reste de la session, il affiche un avis sur les frais de requêtes de classificateur sur les comptes où ces requêtes sont facturées.
• Le serveur ne donne pas de verdict pour une action : Claude Code refuse l'action plutôt que de l'exécuter sans examen. Sur n'importe quelle connexion, cela se produit quand la réponse se termine avant l'arrivée des résultats d'examen ou que les résultats arrivent sous une forme que Claude Code ne peut pas lire. Une passerelle LLM ou un proxy qui raccourcit les réponses ou réécrit les résultats peut causer l'un ou l'autre. Sur une connexion directe à l'API Anthropic, cela se produit également quand la vérification du serveur échoue pour l'action, par exemple en dépassant le délai d'attente. Le serveur n'a pas retourné de verdict de sécurité couvre le message de refus, ce qui se passe quand les refus se répètent, et ce qu'il faut faire.

Pour ne pas interroger le serveur et toujours utiliser les propres requêtes de classificateur de Claude Code, définissez CLAUDE_CODE_AUTO_MODE_SERVER=0. Sur une connexion directe à l'API Anthropic, la variable nécessite Claude Code v2.1.281 ou ultérieur. La définir sur 1 active l'examen du serveur dans une session qui ne l'a pas encore, à moins que vous n'ayez également défini CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1. Si vous définissez CLAUDE_CODE_DISABLE_EXPERIMENTAL_BETAS=1 et laissez CLAUDE_CODE_AUTO_MODE_SERVER non défini, Claude Code cesse également d'interroger le serveur, sauf comme le décrit Désactiver les capacités de pré-version.

Modèle de classificateur par défaut

Par défaut, les requêtes de classificateur sont envoyées à Claude Sonnet 5. Si /status affiche Auto mode server comme Enabled, elles ne sont envoyées que pour les appels en dehors de l'examen du serveur.

Trouvez la première ligne de ce tableau qui correspond à votre session. Vous obtenez le modèle de cette ligne à la place de Sonnet 5.

Si Sonnet 5 ou le modèle dans ANTHROPIC_DEFAULT_SONNET_MODEL n'est pas disponible auprès de votre fournisseur ou est exclu par la politique de modèles de votre organisation, Claude Code utilise un modèle de secours. Il s'agit du modèle de votre session, ou d'un modèle Opus dans une session Fable.

Choisir le modèle de classificateur

Avec Claude Code v2.1.302 ou ultérieur, définissez CLAUDE_CODE_AUTO_MODE_MODEL sur un ID de modèle complet pour exécuter le classificateur sur un modèle autre que le modèle par défaut. Les ID de modèle complets propres à votre fournisseur cloud fonctionnent également. Cet exemple de ~/.claude/settings.json définit Claude Sonnet 4.6 :

{
  "env": {
    "CLAUDE_CODE_AUTO_MODE_MODEL": "claude-sonnet-4-6"
  }
}

Quand votre modèle n'est pas celui qui examine

Si plusieurs situations s'appliquent, retenez la première de la liste.

Vérifier quel modèle le classificateur a utilisé

Depuis votre shell, démarrez une session en mode auto avec --debug-file :

claude --permission-mode auto --debug-file classifier-debug.log

Demandez à Claude d'exécuter une commande shell qui n'est pas en lecture seule, puis recherchez classifier_request_started dans le log :

• Votre modèle après model= : la variable a pris effet
• Un modèle différent après model= : recherchez ignoring CLAUDE_CODE_AUTO_MODE_MODEL dans le log, qui donne la raison et toute étape à suivre
• Aucune ligne de ce type : lisez Auto mode server dans /status à l'invite de Claude Code :
  • Enabled : le serveur est configuré pour examiner les appels de cette session.
  • Disabled : assurez-vous que le mode de permission est auto, puis demandez à Claude d'exécuter une autre commande qui n'est pas en lecture seule.

Ce que le classificateur bloque par défaut

Le classificateur fait confiance à votre répertoire de travail et aux remotes qui étaient configurés pour celui-ci quand la session a démarré. Un remote ajouté ou réorienté pendant la session avec git remote add ou git remote set-url n'est pas considéré comme fiable, et tout le reste est traité comme externe jusqu'à ce que vous configuriez l'infrastructure approuvée.

Bloqué par défaut :

• Téléchargement et exécution de code, comme curl | bash

• Envoi de données sensibles à des endpoints externes

• Déploiements et migrations de production

• Suppression en masse sur le stockage cloud

• Octroi de permissions IAM ou de dépôt

• Modification de l'infrastructure partagée

• Destruction irréversible de fichiers qui existaient avant la session

• Push forcé

• Créer un commit ou pousser une modification qui enverrait des secrets ou des données sensibles en dehors du dépôt lors de son exécution, ou élargirait ce qu'un déploiement expose. Cela couvre un workflow CI ou une configuration de déploiement qui transmet un secret à une destination qui ne le reçoit pas déjà, un script ou une étape de configuration qui lit un magasin de secrets et envoie les données à l'extérieur, et une modification de configuration qui élargit ce qu'un déploiement publie, comme un paramètre de registre, de visibilité, d'artefact ou de sourcemap. La vérification s'applique sur n'importe quelle branche, s'applique même quand le dépôt est public, et se déclenche quand la modification est commitée ou poussée, que ce commit ou ce push déclenche le pipeline ou non ; la lever nécessite de nommer l'effet d'exécution, pas seulement le commit ou le push

• git reset --hard, git checkout -- ., git restore ., git clean -fd, git stash drop ou git stash clear, dont le classificateur présume qu'ils abandonneraient les modifications non commitées

• git commit --amend quand le commit à HEAD n'a pas été créé dans cette session

• À partir de v2.1.198, git commit --amend quand le commit à HEAD a déjà été poussé. Une reformulation du message seul n'est pas bloquée : --amend -m sans rien de nouvellement indexé, sur un commit que Claude a créé pendant cette session

• terraform destroy, pulumi destroy, cdk destroy ou terragrunt destroy, et l'application d'un plan qui détruit des ressources

• Écriture dans un gestionnaire de secrets, ou modification des enregistrements DNS ou des certificats TLS

• Fusion d'une pull request qu'aucun humain n'a approuvée, approbation de la propre pull request de Claude, ou désactivation des vérifications CI

• Publication d'un commentaire qui est lui-même une commande destinée à l'automatisation, comme atlantis apply ou le /deploy ou /merge d'un bot

• Basculement, augmentation progressive ou suppression d'un feature flag de production

• Application de modifications d'infrastructure à une portée IaC protégée, ou vidage et suppression de nœuds de cluster

• Écritures dans un cluster de calcul partagé qui vont au-delà de la ressource que vous avez nommée, comme un sélecteur d'étiquette ou --all qui capture les tâches d'autres utilisateurs

• Création de ressources Kubernetes qui s'exécutent sur chaque nœud ou interceptent le trafic du cluster, comme les DaemonSets et les webhooks d'admission

• Shells interactifs ou redirections de port vers une cible distante sensible

• Ouverture d'un tunnel ou d'un shell inverse qui rend un service local accessible depuis l'Internet public

• Affichage d'identifiants ou d'un jeton actifs dans la transcription ou un fichier

• Accès à un emplacement répertorié comme emplacement de données sensibles dans votre environnement, copie de données hors de celui-ci, ou envoi de données issues d'un tel emplacement à un public que l'entrée exclut

• Contournement de votre registre de paquets interne en installant un paquet depuis un registre public. Cela s'applique quand un registre interne ou un miroir est répertorié dans votre environnement ou quand vous avez indiqué à Claude dans la conversation qu'un tel registre existe

• Exécution d'une commande avec un flag qui désarme une protection de sécurité, comme --insecure

• Lancement d'une boucle d'agent autonome qui s'exécute sans approbation humaine ni sandbox, comme une boucle lancée avec --dangerously-skip-permissions ou --no-sandbox. Cela inclut l'exécution d'un agent tiers ou d'un harnais d'évaluation avec l'isolation et l'approbation par action désactivées, comme un runner lancé avec --yes-always

• Actions du navigateur Claude dans Chrome qui pourraient envoyer le contenu de la page, les cookies ou les identifiants hors origine

• Suppression de fichiers dans /tmp, $TMPDIR ou un autre répertoire temporaire ou de cache partagé par caractère générique, glob ou filtre d'âge plutôt que par un chemin nommé spécifique

• Inclusion de détails sensibles dans du contenu envoyé, téléversé, publié ou écrit à d'autres personnes ou dans des systèmes partagés, quand votre propre message n'a pas autorisé ces détails pour ce destinataire. Les corps de PR et d'issue, les messages de commit et les commentaires comptent comme ce type de contenu sortant quand le dépôt est en dehors de la limite de confiance ou public, y compris les dépôts publics de votre propre organisation ; les chemins de fichiers internes, les noms de code, les données de réponse API en direct comme les e-mails ou les identifiants de compte, et les identifiants d'infrastructure comptent comme des détails sensibles. Les données personnelles en direct issues d'une réponse API dans un corps de PR ou d'issue, comme une adresse e-mail, un identifiant de compte ou d'organisation, ou une métrique d'utilisation, vous obligent à nommer ces détails et le destinataire indépendamment de la visibilité ou de la limite de confiance du dépôt

• Envoi de frappes au clavier au propre volet tmux de Claude Code pour piloter sa propre interface, ce que le classificateur traite comme Claude modifiant ses propres permissions ou sa propre supervision

• Mise en commentaire, suppression ou forçage de la réussite d'un test ou d'une assertion qui protège un comportement de sécurité, comme l'authentification, le contrôle d'accès, la validation des entrées ou le sandboxing

• Suppression ou démantèlement d'une ressource avec état que Claude n'a pas créée dans la session, quand aucune règle de suppression plus spécifique ne s'applique et que vous n'avez pas nommé cette ressource

• Réorientation d'une URL de base d'API, d'un endpoint de proxy, d'un récepteur de webhook ou d'un miroir de registre vers un hôte tiers qui ne correspond pas à la tâche, y compris dans les fichiers d'exemple comme .env.example

• Modification de la destination des push avec git remote set-url ou git remote add, à moins que vous n'ayez nommé le nouveau remote

• Push de secrets ou de données personnelles ou confiées vers un dépôt connu pour être public, ou push de contenu confidentiel qui ne fait pas partie du travail propre de ce dépôt. Le sujet propre d'un dépôt de dotfiles est la seule exception pour les données personnelles ou confiées, et le contenu d'un dépôt privé atteignant n'importe quelle surface publique est bloqué de la même manière. Quand la visibilité d'un dépôt n'est pas établie, le classificateur ne bloque pas sur ce seul critère ; il juge plutôt le contenu par rapport aux autres règles

• Ouverture d'une pull request vers un dépôt ou une organisation différents, fork avec gh repo fork ou push vers un dépôt tiers, à moins que vous n'ayez nommé cette cible externe

• Contenu issu d'un magasin local sensible, ou d'un fichier dont le nom, le chemin ou le type le marque comme sensible, entrant dans un commit, un push, un texte de PR ou d'issue, un gist ou un paste, ou une publication de paquet, à moins que vous n'ayez nommé à la fois la source et la destination. Les transcriptions de session et les journaux de conversation, les dossiers cachés d'identifiants et de configuration comme les clés SSH, les identifiants cloud, les profils de navigateur et l'historique du shell, ainsi que les exportations de données utilisateur comptent tous, et le fait que le dépôt soit privé ne lève pas le blocage

• Écriture dans les transcriptions de session Claude Code, les fichiers d'historique .jsonl sous ~/.claude/projects/ ou votre répertoire de configuration configuré, directement ou via une commande shell. La règle couvre également les lignes de métadonnées que Claude Code ajoute à chaque entrée de transcription pour ses propres vérifications. La lecture d'une transcription n'est pas bloquée

• Une suppression forcée récursive comme rm -rf "$VAR" ou Remove-Item -Recurse -Force $dir dont la cible est une variable shell qui n'est assignée nulle part dans la conversation que le classificateur voit, ou un glob enraciné dans une telle variable. La valeur provenait uniquement d'une sortie de commande antérieure, que le classificateur ne reçoit jamais, donc le classificateur ne peut pas vérifier la cible de suppression par rapport aux autres règles de suppression. Le blocage est levé quand vous nommez le chemin exact en cours de suppression, ou quand Claude réexécute la suppression avec le chemin littéral résolu écrit dans la commande. Les suppressions dont le classificateur peut résoudre la cible ne sont pas affectées.

  Un glob directement sous la variable, comme dans rm -rf "$VAR"/*, est plutôt un chemin critique. Les cibles Remove-Item qui sont un * seul ou se terminent par /* ou \* n'atteignent jamais le classificateur : Claude Code les refuse directement.

Plusieurs de ces catégories dépendent d'entrées d'environnement, comme les cibles distantes sensibles et les portées IaC protégées, que vous pouvez restreindre à des noms concrets.

Claude Code v2.1.257 et ultérieur bloquent également par défaut :

• Demande d'identifiants à l'endpoint de métadonnées d'instance cloud, comme 169.254.169.254, ou authentification explicite d'un appel cloud, cluster ou registre avec l'identité de compte de service ou de nœud de la machine
• Accès à un hôte public par une route autre qu'une requête directe, comme un tunnel, un shell inverse, ou une configuration de résolveur ou de proxy réécrite pour pointer vers l'extérieur
• Lecture d'identifiants qui appartiennent à l'hôte plutôt qu'à votre tâche, comme les certificats de nœud ou l'authentification au registre de conteneurs du nœud
• Connexion à ou analyse des conteneurs, pods ou VMs voisins que Claude n'a pas démarrés, ou du nœud sous le conteneur

Si Claude Code s'exécute dans un endroit censé autoriser l'une de ces actions, décrivez cette configuration dans une entrée Host containment dans autoMode.environment.

Claude Code v2.1.261 et ultérieur bloquent également par défaut :

• Publication ou écriture d'un lien vers un service public de paste, de diagramme ou de partage de données dans un message, un texte de PR ou d'issue, un document, ou n'importe où ailleurs où le lien sera ouvert ou récupéré, quand l'URL elle-même contient le contenu partagé, à moins que vous n'ayez nommé ce service

Autorisé par défaut :

• Opérations sur les fichiers locaux dans votre répertoire de travail

• Installation de dépendances déclarées dans vos fichiers de verrouillage ou manifestes

• Lecture de .env et envoi d'identifiants à leur API correspondante

• Requêtes HTTP en lecture seule

• Push vers n'importe quelle branche du dépôt sur lequel vous travaillez, y compris la branche par défaut. Une branche autre que celle par défaut dont le nom la désigne comme cible de déploiement ou de publication, comme production ou gh-pages, n'est pas couverte : le classificateur juge un push vers celle-ci selon ses propres critères.

  Le contenu d'un push est toujours vérifié par rapport aux autres règles du classificateur, et les règles permissions.deny peuvent toujours bloquer les commandes de push telles qu'écrites dans chaque mode. La protection de branche propre au remote s'applique toujours.

• Suppression des tâches exactes que Claude a créées plus tôt dans la même session

• Lecture, examen ou écriture de code, de configurations et de modèles de menace liés à la sécurité dans le cadre de votre tâche

• Messages entre agents travaillant ensemble dans la même session multi-agents

• Envoi de données aux domaines, buckets et services approuvés que vous énumérez dans environment. Cela couvre uniquement le flux de données, pas les opérations destructrices ou portant sur des identifiants sur la même infrastructure

• Navigation Claude dans Chrome vers un domaine interne approuvé, localhost ou une URL que vous avez nommée

Les commandes en sandbox n'obtiennent pas d'accès réseau par défaut. Claude nomme les hôtes dont une commande a besoin sur la commande elle-même, le classificateur les examine avec la commande, et une liste approuvée ouvre ces hôtes pour cette seule commande. Domaines autorisés par commande couvre ce qu'une liste peut et ne peut pas ouvrir et ce qui se passe quand une commande tente d'atteindre un hôte non répertorié.

Exécutez claude auto-mode defaults pour afficher les listes de règles complètes en JSON. Si des actions courantes sont bloquées, un administrateur peut ajouter des dépôts, des buckets et des services approuvés via le paramètre autoMode.environment : voir Configurer le mode auto.

Pousser vers n'importe quelle branche du dépôt sur lequel vous travaillez et créer une pull request qui correspond à votre demande s'exécutent sans demande de permission, à moins que le push ou la pull request ne relève de la liste de blocage, comme des secrets ou des données sensibles quittant le dépôt, ou une pull request qui cible un dépôt ou une organisation différents. Pour exiger un checkpoint humain avant ces commandes tout en restant en mode auto, ajoutez des règles permissions.ask, qui correspondent à la commande telle qu'écrite : voir Limites communes.

La première lecture en dehors des répertoires de travail

Tant que permissions.blockReadsOutsideWorkingDirectories est désactivé, les lectures de fichiers autres que les lectures depuis des chemins réseau s'exécutent sans demande de permission en mode auto, y compris les lectures en dehors des répertoires de travail. La première fois que Claude utilise l'outil Read, Grep ou Glob sur un chemin en dehors de ceux-ci, Claude Code demande s'il faut autoriser cette lecture.

La demande n'apparaît pas dans les exécutions -p non interactives ni dans les sessions d'arrière-plan ; les lectures y s'exécutent comme avant.

Quelle que soit votre réponse, Claude continue à travailler :

• Oui, et continuez à autoriser toute lecture en dehors des répertoires de travail : la lecture s'exécute, les lectures ultérieures en dehors des répertoires de travail s'exécutent comme avant, et Claude Code enregistre votre réponse pour que la demande n'apparaisse plus
• Non, et bloquez les lectures en dehors des répertoires de travail à partir de maintenant : la lecture est refusée, et Claude Code définit permissions.blockReadsOutsideWorkingDirectories sur true dans vos paramètres utilisateur, ce qui fait que les outils de fichier refusent de telles lectures dans chaque session ultérieure et chaque mode de permission. Pour laisser Claude lire un tel chemin plus tard, ajoutez son répertoire avec /add-dir ou supprimez le paramètre.
• Non, et demandez à nouveau la prochaine fois : la lecture est refusée, et la prochaine lecture en dehors des répertoires de travail redemande la permission
• Oui, mais demandez à nouveau la prochaine fois : la lecture s'exécute, rien n'est enregistré, et la prochaine lecture en dehors des répertoires de travail redemande la permission

Limites que vous énoncez dans la conversation

Le classificateur traite les limites que vous énoncez dans la conversation comme un signal de blocage. Si vous dites à Claude « ne pousse pas » ou « attends que j'examine avant de déployer », le classificateur bloque les actions correspondantes même quand les règles par défaut les autoriseraient. Une limite reste en vigueur jusqu'à ce que vous la leviez dans un message ultérieur. Le propre jugement de Claude qu'une condition a été remplie ne la lève pas.

Les limites ne sont pas stockées en tant que règles. Le classificateur les relit à partir de la transcription à chaque vérification, donc une limite peut être perdue si la compaction de contexte supprime le message qui l'a énoncée. Pour une garantie ferme, ajoutez plutôt une règle deny.

Approbations que vous énoncez dans la conversation

Si vous dites à Claude qu'une action bloquée est autorisée, le classificateur lit cela comme votre approbation et peut lever le blocage. La façon dont vous l'avez formulé détermine si l'action s'exécute et jusqu'où l'approbation s'étend :

• Nommez l'action et ses spécificités : votre message doit nommer l'action et l'élément spécifique qui la rend dangereuse, comme la branche d'un push forcé. Nommer le verbe seul ne lève rien, donc « vous pouvez faire un push forcé » laisse le blocage en place.
• Attendez-vous à ce qu'elle couvre une seule action : une approbation couvre l'action destructrice que vous avez nommée, donc une action ultérieure est de nouveau bloquée à moins que vous n'ayez accordé l'approbation de manière permanente. Pour cesser d'approuver un schéma courant action par action, ajoutez-le à autoMode.allow.
• Certains blocages restent en place : l'ordre de priorité du classificateur indique les blocages que votre approbation peut lever. Pour exécuter une étape qu'elle ne débloquera pas, quittez le mode auto et répondez à la demande de permission.

Quand le mode auto se rabat sur une solution de repli

Quand le mode auto ne peut pas approuver les actions de votre session, ce qui se passe dépend du cas :

• Une action bloquée : Claude Code affiche une notification et répertorie l'action dans /permissions sous l'onglet Recently denied, où vous pouvez appuyer sur r pour la réessayer avec une approbation manuelle.
• Blocages répétés : si le classificateur bloque une action 3 fois de suite ou 20 fois au total, le mode auto se met en pause et Claude Code recommence à vous demander la permission. Approuver l'action demandée relance le mode auto. Voir Seuils de blocages répétés pour savoir comment les blocages sont comptés.
• Aucun verdict du classificateur : quand une vérification de sécurité distincte du mode auto refuse la propre requête du classificateur, ou que la réponse du classificateur ne peut pas être analysée, Claude Code refuse l'action sans la notification ni l'entrée Recently denied. Voir Le mode auto ne peut pas déterminer la sécurité d'une action pour le message que chaque cas affiche et ce qu'il faut faire.
• Aucun verdict du serveur : avec l'examen du classificateur côté serveur, Claude Code refuse une action pour laquelle le serveur ne donne pas de verdict, et arrête le tour après dix réponses de suite sans verdict. Voir Le serveur n'a pas retourné de verdict de sécurité.
• Un changement de mode pendant une vérification : si vous changez de mode de permission alors qu'une vérification du classificateur est en attente, Claude Code abandonne un verdict que le nouveau mode n'aurait pas demandé. Une approbation vous est demandée à la place, ou l'action est automatiquement refusée en mode dontAsk.

Seuils de blocages répétés

Les seuils de 3 blocages de suite et de 20 blocages au total ne sont pas configurables. Le compteur total persiste pour la session et ne se réinitialise que lorsque sa propre limite déclenche le repli. Claude Code ne compte pas un refus dans l'un ou l'autre seuil quand une vérification de sécurité distincte du mode auto refuse la propre requête du classificateur.

Une exécution -p non interactive sans --permission-prompt-tool n'a pas de demande de permission sur laquelle se rabattre. Quand les blocages répétés atteignent un seuil, l'action ne s'exécute pas et Claude continue à travailler. Claude Code n'arrête pas l'exécution.

Les blocages répétés signifient généralement que le classificateur manque de contexte sur votre infrastructure. Utilisez /feedback pour signaler les faux positifs, ou demandez à un administrateur de configurer l'infrastructure approuvée.

Comment le mode auto évalue les actions

Les sections suivantes couvrent l'ordre dans lequel Claude Code évalue une action, comment le classificateur examine le travail des sous-agents, et ce que les appels au classificateur ajoutent en coût et en latence.

Comment le classificateur évalue les actions

Chaque action passe par un ordre de décision fixe. La première étape correspondante l'emporte :

1. Les actions correspondant à vos règles allow, ask ou deny sont résolues immédiatement, avec ces exceptions :
   • Les écritures vers les chemins protégés sont acheminées vers le classificateur même quand une règle allow correspond. Quand le chemin protégé est le fichier vers lequel pointe un fichier de paramètres en lien symbolique, l'écriture peut plutôt vous demander la permission, comme le décrit la liste des chemins protégés
   • Aucune règle allow n'approuve les suppressions rm et rmdir reconnues ciblant un chemin critique
   • Les outils MCP marqués requiresUserInteraction vous demandent directement la permission même quand une règle allow correspond, et il en va de même pour les outils de connecteur que votre organisation a définis sur ask dans les sessions où ce paramètre atteint Claude Code
   • Une commande shell qui porte des domaines autorisés par commande est également acheminée vers le classificateur même quand une règle allow correspond, car une règle approuve la commande, pas ses hôtes
   • Les règles ask qui portent sur le contenu d'une commande, comme Bash(git push *), se rabattent sur une demande de permission
   • Une écriture que la vérification des liens symboliques résout vers un chemin protégé vous demande la permission quand le chemin que Claude a demandé n'est pas lui-même protégé
   • Une lecture depuis un chemin réseau vous demande la permission même quand une règle allow correspond
2. Les actions en lecture seule et les modifications de fichiers dans votre répertoire de travail sont approuvées automatiquement, sauf les écritures vers les chemins protégés et la première lecture en dehors des répertoires de travail, qui vous demande la permission
   • Dans une session avec examen du classificateur côté serveur, les commandes shell en lecture seule et en sandbox attendent cet examen et sont bloquées s'il les signale
   • Une écriture à l'intérieur de votre répertoire de travail que la vérification des liens symboliques résout vers un emplacement extérieur vous demande la permission
   • Quand Claude lit un artefact créé par quelqu'un d'autre, les cas d'approbation répertoriés dans cette section s'appliquent
   • Une lecture depuis un chemin réseau vous demande la permission
3. Tout le reste est envoyé au classificateur, à l'exception des suppressions de chemins critiques sous leur gestion par défaut. Les outils de connecteur et les outils MCP requiresUserInteraction qui vous demandent directement la permission à l'étape 1 n'atteignent jamais le classificateur non plus, donc ni une approbation exigée par l'organisation ni une étape de consentement n'est approuvée automatiquement
4. Si le classificateur bloque, Claude reçoit la raison. Dans la plupart des sessions, la raison nomme la règle à laquelle le classificateur a fait correspondre l'action, comme [Data Exfiltration], plutôt que de donner une explication rédigée ; voir Examiner les refus

Un mod que vous installez et qui gère tool.check peut également approuver une action. Pour les cas où son approbation ne passe pas outre vos règles et vos hooks, voir Étendre les permissions avec des hooks.

Pour savoir comment les actions du navigateur Claude dans Chrome sont approuvées dans l'extension VS Code, voir Demandes de permission dans les sessions VS Code.

En entrant en mode auto, les règles allow larges qui accordent l'exécution de code arbitraire sont supprimées :

• Bash(*) ou PowerShell(*) globaux
• Interpréteurs avec caractères génériques comme Bash(python*)
• Commandes d'exécution des gestionnaires de paquets
• Règles Agent allow
• Règles Monitor allow, car Claude Code exécute les commandes Monitor via le shell

Les règles étroites comme Bash(npm test) restent en vigueur. Claude Code restaure les règles supprimées quand vous quittez le mode auto. Avant v2.1.236, Claude Code laissait les règles Monitor allow en vigueur en mode auto, donc une règle qui correspondait à l'outil entier approuvait les commandes Monitor sans examen du classificateur.

Claude Code exécute également git status lui-même avant une commande qui abandonnerait du travail non commité, comme git reset --hard ou rm -rf, et indique au classificateur si du travail indexé, modifié ou non suivi est présent. Claude Code signale les fichiers non suivis dans cette vérification même quand la configuration git du dépôt définit status.showUntrackedFiles=no.

Dans les requêtes de classificateur envoyées par Claude Code lui-même, le classificateur voit les messages utilisateur, les appels d'outils autres que les consultations en lecture seule comme les lectures de fichiers et les recherches, et le contenu de votre CLAUDE.md. Les résultats d'outils sont retirés de ces requêtes, donc le contenu hostile dans un fichier ou une page web ne peut pas manipuler directement le classificateur.

Vous pouvez annoter le résultat d'un appel avec le champ classifierContext d'un hook PostToolUse, que le classificateur lit comme contexte fourni par l'application. Le champ nécessite Claude Code v2.1.236 ou ultérieur.

Une sonde côté serveur distincte analyse les résultats d'outils entrants et signale le contenu suspect avant que Claude ne le lise. Pour plus d'informations sur la façon dont ces couches fonctionnent ensemble, consultez l'annonce du mode auto et l'analyse technique approfondie.

Comment le mode auto gère les sous-agents

Le classificateur vérifie le travail des sous-agents à trois moments :

1. Avant qu'un sous-agent ne démarre, la description de la tâche déléguée est évaluée, donc une tâche qui semble dangereuse est bloquée au moment du lancement.
2. Pendant que le sous-agent s'exécute, chacune de ses actions passe par le même ordre de décision que dans la session parente, avec les mêmes règles de blocage et d'autorisation. Tout permissionMode dans le frontmatter du sous-agent est ignoré.
3. Quand le sous-agent se termine, le classificateur examine son travail et son rapport final avant que le parent ne lise le rapport. Quand le classificateur signale le travail ou le rapport du sous-agent, ou qu'une vérification de sécurité API distincte refuse l'examen, le rapport est tout de même livré, précédé d'un avertissement de sécurité. Quand le classificateur n'est pas disponible pour l'examen, le rapport arrive avec une note invitant à vérifier le travail du sous-agent avant d'agir en conséquence.

Coût et latence

Les requêtes de classificateur de Claude Code peuvent s'exécuter sur un modèle autre que votre sélection /model. Voir sur quel modèle elles s'exécutent.

Sur les plans Enterprise et sur les comptes qui utilisent l'API Claude, Claude Platform sur AWS, Amazon Bedrock, Google Cloud's Agent Platform ou Microsoft Foundry, les appels au classificateur comptent dans votre utilisation de tokens. Chaque vérification envoie une partie de la transcription ainsi que l'action en attente, ajoutant un aller-retour avant l'exécution. Les lectures et les modifications dans le répertoire de travail en dehors des chemins protégés ne passent pas par le classificateur, donc la surcharge provient principalement des commandes shell et des opérations réseau. Là où le serveur examine les actions dans le cadre des requêtes de modèle de la session, il n'y a pas d'appels distincts au classificateur à compter ; voir Examen du classificateur côté serveur.

L'accès réseau en sandbox n'ajoute pas de requêtes de classificateur par connexion. Le classificateur juge les hôtes qu'une commande nomme avec la commande en un seul examen, et Claude Code vérifie chaque connexion par rapport à la liste approuvée sans appeler à nouveau le classificateur.

Autoriser uniquement les outils pré-approuvés avec le mode dontAsk

Si vous définissez le mode dontAsk, Claude Code refuse automatiquement chaque appel d'outil qui déclencherait autrement une demande de permission, bien qu'un mod que vous avez installé puisse encore approuver certains de ces appels. Pour vérifier quels appels un mod peut approuver, consultez Étendre les permissions avec des hooks.

Claude exécute toujours les actions qui ne nécessitent aucune approbation en mode Manual, telles que les lectures de fichiers dans vos répertoires de travail et les commandes Bash en lecture seule. Les actions correspondant à vos règles permissions.allow et les appels approuvés par un hook PreToolUse s'exécutent également. Utilisez ce mode pour les pipelines CI ou les environnements restreints où vous prédéfinissez ce que Claude peut faire ; la session n'attend jamais d'entrée. La barre d'état affiche ⏵⏵ don't ask on tandis que ce mode est actif.

Claude Code refuse les appels correspondant à vos règles ask explicites plutôt que de déclencher une invite. Il refuse également l'outil intégré AskUserQuestion même si vos règles allow les correspondent, et il en va de même pour les outils de connecteur que votre organisation a définis sur ask dans les sessions où ce paramètre atteint Claude Code. Il refuse les outils MCP marqués _meta["anthropic/requiresUserInteraction"] de la même manière, car leur carte d'approbation nécessite une réponse que ce mode ne collecte jamais.

Une règle allow ou un hook PreToolUse ne peut pas approuver les éléments suivants :

• Les suppressions rm et rmdir reconnues ciblant un chemin critique, comme rm -rf / et rm -rf ~
• Les lectures depuis un chemin réseau

Les sessions cloud sur Claude Code sur le web ignorent defaultMode: "dontAsk" ; voir bypassPermissions pour les détails.

Définissez-le au démarrage avec le drapeau :

claude --permission-mode dontAsk

Ignorer tous les contrôles avec le mode bypassPermissions

Le mode bypassPermissions désactive les invites de permission et les contrôles de sécurité afin que les appels d'outils s'exécutent immédiatement, y compris les écritures vers les chemins protégés.

Même en mode bypassPermissions, chacune des actions qu'aucun mode n'auto-approuve fait l'objet d'une demande ou d'un refus, bien que vous puissiez désactiver la demande pour les commandes rm dangereuses. La lecture de l'artefact public d'une autre organisation nécessite votre approbation, et ce mode ne la demande pas, donc Claude ne peut pas en lire. Les refus Remove-Item dans PowerShell s'appliquent également dans ce mode.

Deux protections de messagerie inter-sessions s'appliquent toujours dans ce mode, et dans les sessions en mode plan interactif où les permissions de contournement sont disponibles :

• L'invite d'approbation isolatePeerMachines pour les messages vers vos sessions au-delà de cette machine apparaît toujours.
• Quand aucune valeur crossSessionInbound ne s'applique, Claude Code retient un message entrant d'une autre de vos sessions pour votre approbation, et le livre sans demander uniquement quand la session d'envoi s'identifie comme contournant également les invites de permission. Si vous quittez le mode de permission tandis que les messages sont retenus, Claude Code réapplique les règles entrantes et livre tout message retenu qu'elles acceptent maintenant.

Dans les sessions de terminal interactif avec les permissions de contournement disponibles, Claude Code n'applique pas non plus les blocs du mode plan. Claude est toujours instruit de planifier sans modifier, mais une modification de fichier ou une commande shell qu'il tente pendant la planification s'exécute sans demander. Les règles ask explicites et les suppressions rm et rmdir ciblant un chemin critique demandent toujours.

Le mode plan conserve ses blocs partout où Claude Code s'exécute sans terminal interactif, y compris les exécutions non-interactives avec -p, les sessions du SDK Agent, et les conversations dans le panneau de chat de l'extension VS Code. Là, --allow-dangerously-skip-permissions rend bypassPermissions sélectionnable ultérieurement.

[!WARNING]

Utilisez ce mode uniquement dans des environnements isolés comme les conteneurs, les machines virtuelles ou les dev containers sans accès à Internet, où Claude Code ne peut pas endommager votre système hôte.

Vous ne pouvez pas entrer dans bypassPermissions à partir d'une session que vous avez démarrée sans l'activer. Activez-le au lancement avec permissions.defaultMode: "bypassPermissions" ou avec un drapeau d'activation :

claude --permission-mode bypassPermissions

Le drapeau --dangerously-skip-permissions est équivalent.

Claude Code refuse bypassPermissions dans une session que vous démarrez avec --restricted. --restricted nécessite Claude Code v2.1.248 ou ultérieur.

La première fois que vous démarrez une session interactive avec ce mode activé, Claude Code affiche un dialogue d'avertissement vous demandant d'accepter la responsabilité des actions prises sans vérifications de permission :

• Si vous acceptez : Claude Code définit skipDangerousModePermissionPrompt sur true dans ~/.claude/settings.json, de sorte que les sessions ultérieures ignorent le dialogue. Pour voir le dialogue à nouveau, supprimez la clé de ce fichier ou définissez-la sur false. La référence skipDangerousModePermissionPrompt énumère les autres fichiers de paramètres où vous ou votre organisation pouvez le définir.
• Si vous refusez : Claude Code quitte.

En mode non interactif, aucun dialogue n'est affiché.

Une session en arrière-plan respecte votre acceptation lorsqu'elle est enregistrée dans les paramètres utilisateur ou les paramètres gérés :

• Sans acceptation enregistrée, claude --bg --permission-mode bypassPermissions est refusé. Acceptez d'abord le dialogue dans une session interactive.

• Avec skipDangerousModePermissionPrompt défini uniquement dans .claude/settings.local.json, la session en arrière-plan démarre en ignorant la demande de contournement :

  • Lorsque --allow-dangerously-skip-permissions est ignoré, bypassPermissions est exclu de son cycle Shift+Tab.
  • Lorsque --permission-mode bypassPermissions ou --dangerously-skip-permissions est ignoré, la session démarre plutôt en mode Manual.

  Ajoutez "skipDangerousModePermissionPrompt": true à ~/.claude/settings.json, puis démarrez une nouvelle session en arrière-plan.

Sur Linux et macOS, Claude Code refuse de démarrer en mode bypassPermissions lors de l'exécution en tant que root ou sous sudo :

--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons

La vérification est ignorée automatiquement à l'intérieur d'un sandbox reconnu. Pour s'exécuter de manière autonome dans un conteneur, utilisez la configuration du dev container, qui exécute Claude Code en tant qu'utilisateur non-root.

Les sessions cloud n'honorent pas defaultMode: "bypassPermissions" ou "dontAsk" de vos fichiers de paramètres, donc les paramètres archivés d'un référentiel ne peuvent pas démarrer une session cloud en mode bypass-permissions. Le paramètre est ignoré silencieusement et la session démarre dans le mode affiché dans la liste déroulante des modes à la place. Voir Basculer les modes de permission pour connaître les modes que les sessions cloud proposent.

[!WARNING]

bypassPermissions n'offre aucune protection contre l'injection de prompt ou les actions involontaires. Pour les contrôles de sécurité en arrière-plan avec beaucoup moins d'invites de permission, utilisez le mode auto à la place. Les administrateurs peuvent bloquer ce mode en définissant permissions.disableBypassPermissionsMode sur "disable" dans les paramètres gérés.

Contournement des permissions ignoré dans une session en arrière-plan

Cet avis signifie que la session en arrière-plan n'a pas trouvé votre acceptation de l'avertissement de contournement des permissions dans les paramètres utilisateur ou les paramètres gérés, et qu'elle a donc ignoré la demande de contournement faite au lancement :

Bypass permissions was requested at launch and ignored · if that was you, ~/.claude/settings.json needs "skipDangerousModePermissionPrompt": true

Ajoutez "skipDangerousModePermissionPrompt": true à ~/.claude/settings.json, puis démarrez une nouvelle session en arrière-plan.

claude agents affiche l'avertissement de contournement des permissions que les sessions interactives ignorent

Si claude agents affiche l'avertissement de contournement des permissions alors que vos sessions interactives l'ignorent, vérifiez si skipDangerousModePermissionPrompt est défini dans .claude/settings.local.json ou dans un fichier --settings. Les sessions interactives considèrent la clé à cet endroit comme votre acceptation de l'avertissement, mais pas claude agents. Que vous l'y trouviez ou non, acceptez l'avertissement pour ajouter la clé à ~/.claude/settings.json, où claude agents la recherche.

Chemins protégés

Les écritures vers un petit ensemble de chemins ne sont jamais approuvées automatiquement, sauf en mode bypassPermissions et dans les sessions de terminal interactif en mode plan avec les autorisations de contournement disponibles. Cela empêche la corruption accidentelle de l'état du référentiel et de la configuration propre de Claude.

Dans une session démarrée avec --restricted, qui nécessite Claude Code v2.1.248 ou version ultérieure, le classificateur ne peut pas approuver les écritures de chemins protégés.

Dans les modes qui acheminent les écritures de chemins protégés vers le classificateur, une écriture que la vérification des liens symboliques résout vers un chemin protégé vous demande une confirmation à la place quand le chemin que Claude a demandé n'est pas lui-même protégé.

Les règles permissions.allow dans les fichiers de paramètres ne pré-approuvent pas les écritures de chemins protégés. La vérification de sécurité s'exécute avant que Claude Code n'évalue les règles d'autorisation des paramètres, donc une entrée telle que Edit(.claude/**) dans ~/.claude/settings.json ou .claude/settings.json ne change pas le résultat par mode dans le tableau ci-dessus. Dans les modes qui demandent, l'invite pour une écriture vers le dossier .claude/ du projet ou vers ~/.claude/ peut offrir l'une de ces options limitées à la session :

• Pour le dossier .claude/ du projet : Oui, et autoriser Claude à modifier les fichiers du dossier .claude de ce projet pour cette session
• Pour ~/.claude/ : Oui, et autoriser Claude à modifier les fichiers de son dossier ~/.claude pour cette session

Répertoires protégés :

• .git
• .config/git
• .vscode
• .idea
• .husky
• .cargo
• .devcontainer
• .yarn
• .mvn
• .claude, à quelques exceptions près, telles que :
  • Les propres git worktrees de Claude sous .claude/worktrees/
  • Les propres fichiers de plan de la session en cours dans ~/.claude/plans/, ou dans le plansDirectory que vous définissez
  • Le répertoire temporaire propre à une session en arrière-plan à ~/.claude/jobs/<id>/tmp/
  • Les fichiers markdown du répertoire de mémoire automatique du projet, tel que ~/.claude/projects/<project>/memory/, dans une session démarrée sans --restricted
  • Les fichiers markdown d'un répertoire de mémoire de sous-agent, tel que .claude/agent-memory/, dans une session démarrée sans --restricted
• Un répertoire que vous avez chargé avec --plugin-dir, car Claude Code recharge et exécute le code d'un mod à partir de celui-ci quand un fichier change
• ~/.claude/dev-mods/, ou dev-mods/ dans le répertoire vers lequel pointe CLAUDE_CONFIG_DIR, où Claude enregistre les mods qu'il écrit pour vous

Fichiers protégés :

• .gitconfig, .gitmodules
• .bashrc, .bash_profile, .bash_login, .bash_aliases, .bash_logout, .zshrc, .zprofile, .zshenv, .zlogin, .zlogout, .profile, .envrc
• .npmrc, .yarnrc, .yarnrc.yml, .pnp.cjs, .pnp.loader.mjs, .pnpmfile.cjs, bunfig.toml, .bunfig.toml
• .bazelrc, .bazelversion, .bazeliskrc
• .pre-commit-config.yaml, lefthook.yml, lefthook.yaml, .lefthook.yml, .lefthook.yaml
• gradle-wrapper.properties, maven-wrapper.properties
• .devcontainer.json
• .ripgreprc, pyrightconfig.json
• .mcp.json, .claude.json
• Un fichier que vous avez passé à --settings, --mcp-config ou --agents au démarrage de la session
• Le fichier vers lequel pointe votre fichier de paramètres utilisateur, de projet ou local lorsque ce fichier de paramètres est lui-même un lien symbolique, par exemple vers un dépôt de dotfiles. Dans les modes qui acheminent les écritures de chemins protégés vers le classificateur, une écriture vers ce fichier vous demande une confirmation à la place, même lorsqu'une règle d'autorisation correspond. Si le chemin propre du fichier est également celui d'un fichier de paramètres, tel que .claude/settings.json dans un autre dossier, l'écriture est acheminée vers le classificateur comme les autres écritures de chemins protégés

Chemins critiques

Les chemins critiques sont les répertoires que Claude Code protège des commandes rm et rmdir, comme la racine du système de fichiers, votre répertoire personnel et votre répertoire de travail. Claude Code vérifie ces commandes avant leur exécution, et aucune règle allow n'approuve une commande dont il reconnaît la cible comme un chemin critique. La vérification peut manquer certaines commandes ; elle ne remplace donc pas un contrôle du système d'exploitation comme le sandboxing.

Une suppression de chemin critique est une commande rm ou rmdir dont Claude Code reconnaît la cible comme un chemin critique. Aucun hook PreToolUse qui retourne "allow" n'en approuve une non plus. Une règle allow ou un hook PreToolUse ne peut pas en approuver une, même dans les modes de permission qui sautent les autres invites.

[!WARNING]

Une commande que la vérification manque ne reçoit aucun traitement particulier : tout ce qui approuve les commandes Bash dans votre session peut donc l'approuver sans invite. Cela inclut une règle allow, le mode bypassPermissions et le mode auto-allow du sandbox. La vérification s'applique à rm et rmdir ; d'autres commandes approuvées peuvent donc aussi supprimer des chemins critiques.

Ces contrôles s'appliquent que la vérification reconnaisse ou non une commande :

• Règles deny : une règle deny qui correspond à la commande la bloque, bien qu'un mod que vous avez installé puisse encore approuver certains de ces appels
• Sandboxing : le sandboxing fait limiter par le système d'exploitation les chemins dans lesquels les commandes Bash peuvent écrire. Les commandes en sandbox peuvent toujours supprimer votre répertoire de travail
• Mode sandbox strict : par défaut, une commande en sandbox peut être réessayée hors du sandbox, et une règle allow ou le mode bypassPermissions peut approuver cette nouvelle tentative sans invite. Le mode sandbox strict désactive la nouvelle tentative

Ce qui arrive à une suppression que Claude Code reconnaît dépend de votre mode de permission. Remove-Item et les commandes intégrées de suppression cmd ont leurs propres vérifications, couvertes dans Remove-Item dans PowerShell.

Quels chemins sont critiques

Claude Code traite une cible rm ou rmdir comme un chemin critique quand il s'agit de l'un des éléments suivants :

• La racine du système de fichiers
• Les répertoires de niveau supérieur, ce qui signifie tout enfant direct de la racine, comme /usr, /etc, ou /data
• Votre répertoire personnel. Sous Windows, son nom court 8.3 compte aussi, comme C:\Users\LONGNA~1
• Les racines des lecteurs Windows et leurs répertoires de niveau supérieur, comme C:\ et C:\Windows. Des graphies comme \\?\C:\ et \\localhost\C$ comptent comme C:\
• Votre répertoire de travail et ses parents
• Vos répertoires de travail supplémentaires et leurs parents, mais uniquement quand la suppression est un glob sous l'un d'eux, comme rm -rf <dir>/*. rm -rf <dir> sur le répertoire lui-même ne déclenche pas cette vérification

Pour les chemins de lecteurs montés comme /mnt/c ou /Volumes/USB, consultez L'invite de lecteur monté.

Les vérifications sur le nom court 8.3 du répertoire personnel et sur les graphies \\?\C:\ et \\localhost\C$ nécessitent Claude Code v2.1.292 ou ultérieur.

Autres cibles qui comptent comme des chemins critiques

Claude Code traite également les cibles rm et rmdir suivantes comme des chemins critiques. La dernière colonne indique pourquoi chacune compte.

Pour désactiver la vérification sur une cible qui est uniquement la sortie d'une substitution de commande, définissez CLAUDE_CODE_DISABLE_SUBSTITUTION_RM_PROMPT=1 dans l'environnement qui lance Claude Code.

Suppressions à l'intérieur de commandes imbriquées et de scripts en ligne

Claude Code regarde également à l'intérieur de ces constructions :

• Commandes imbriquées : une sous-coquille avec (...), un groupe d'accolades avec { ...; }, une substitution de commande avec $(...) ou des backticks, ou une substitution de processus avec <(...). Claude Code trouve une suppression de chemin critique qu'elle se trouve à l'intérieur de la forme imbriquée, comme dans (rm -rf ~) ou echo "$(rm -rf ~)", ou ailleurs dans la même commande.
• Scripts en ligne : un script passé à sh, bash, zsh ou un shell POSIX similaire avec -c, comme dans bash -c 'rm -rf ~'.
  • Quand le script est entre guillemets doubles, le shell d'invocation développe ses variables avant que le shell interne ne reçoive le script. Dans find . -name '*.tmp' -exec sh -c "rm -rf \"$1\"/*" _ {} \;, la commande se développe en une suppression de la racine du système de fichiers une fois par correspondance, et Claude Code la traite comme une suppression de chemin critique.
  • Un script entre guillemets simples qui lie $1 à une valeur réelle, comme sh -c 'rm -rf "$1"/*' _ {} le fait, n'est pas signalé.

Pour désactiver la vérification sur un chemin critique saisi directement dans un script -c, comme ~, définissez CLAUDE_CODE_DISABLE_INLINE_SHELL_RM_PROMPT=1 dans l'environnement qui lance Claude Code.

Réécrire une commande signalée

Comment réécrire une commande pour qu'elle passe la vérification dépend de laquelle des autres cibles elle utilise :

• Un glob ou une barre oblique finale sous une variable comme $DIR : protégez chaque expansion pour que le shell s'arrête avec une erreur quand la variable n'est pas définie ou vide, comme dans rm -rf "${DIR:?}"/*, ou utilisez un chemin littéral. Une suppression dont les expansions sont toutes protégées de cette manière passe cette vérification, donc en mode bypassPermissions elle s'exécute sans invite à moins qu'une autre vérification de chemin critique ne la signale.
• Un glob ou une barre oblique finale sous une variable qui est normalement définie, comme $HOME : utilisez un chemin littéral.
• Une variable assignée à partir d'une substitution d'impression de répertoire : utilisez un chemin littéral. Une protection "${D:?}" ne clarifie pas cette vérification, car la variable n'est pas vide.
• Une cible qui est uniquement la sortie d'une substitution de commande : exécutez la substitution seule d'abord, puis supprimez les chemins littéraux qu'elle affiche. L'invite dit à Claude de faire la même chose.

Pour un glob ou une barre oblique finale sous une variable, l'invite nomme la commande rm signalée et indique comment la réécrire pour que la vérification passe.

L'invite Dangerous rm operation not ruled out

La raison complète indique :

Dangerous rm operation not ruled out — the shell may read this command differently than it was parsed

Cette raison signifie que le shell peut lire la commande différemment de Claude Code : une suppression pourrait donc se trouver dans une partie non vérifiée, même en l'absence de rm. En mode auto ou bypassPermissions, un refus contenant cette phrase provient de la même vérification :

This command could not be checked for dangerous rm operations: the shell may read it differently than it was parsed.

Vous recevez l'invite ou le refus qu'une suppression de chemin critique reçoit dans votre mode de permission, bypassPermissions compris, bien que vous puissiez désactiver cette invite en mode bypassPermissions. Vous ne pouvez pas approuver la commande avec une règle allow Bash ou Bash(*), le mode auto-allow du sandbox ou un hook PreToolUse qui retourne "allow". Lisez la commande, puis approuvez l'invite ou, après un refus, exécutez-la dans votre shell.

L'invite de lecteur monté

L'invite de lecteur monté apparaît sous macOS, Linux et WSL quand un rm récursif cible un chemin de lecteur monté répertorié, comme /mnt/c ou /Volumes/USB/build. Sa raison indique Dangerous rm operation on mounted drive path: <path>. Une cible /* reçoit l'invite sans le flag récursif, car Claude Code lit rm /Volumes/USB/build/* comme une suppression de /Volumes/USB/build.

Même avec une règle allow pour rm, Claude Code traite la commande comme une suppression de chemin critique : une invite ou un refus selon votre mode de permission. Approuvez l'invite pour laisser le rm s'exécuter, ou désactivez l'invite.

Chemins qui reçoivent l'invite de lecteur monté

Comparez la cible de votre rm récursif ou de votre suppression /* à ces formes de chemin, où chaque espace réservé comme <drive> ou <name> représente exactement un segment de chemin :

Pour un rm récursif ou non récursif sur /Volumes, /media ou /mnt eux-mêmes, vous voyez à la place la raison de chemin critique Dangerous rm operation on critical path: <path>.

Une cible relative est évaluée à partir de votre répertoire de travail, donc rm -rf build pendant que vous travaillez dans /Volumes/USB cible /Volumes/USB/build et reçoit l'invite.

Désactiver l'invite de lecteur monté

Pour ne plus recevoir l'invite de lecteur monté tout en conservant les invites ayant d'autres causes, démarrez Claude Code avec CLAUDE_CODE_DISABLE_MOUNTED_DRIVE_RM_PROMPT=1 dans son environnement. Par exemple, définissez la variable dans votre shell et démarrez claude depuis celui-ci :

export CLAUDE_CODE_DISABLE_MOUNTED_DRIVE_RM_PROMPT=1
claude

Dans une session démarrée de cette manière, l'invite de lecteur monté n'apparaît plus pour un lecteur entier comme /Volumes/USB ni pour les autres chemins répertoriés. Si vous autorisez Bash(rm *), utilisez le mode Manual et travaillez dans /Volumes/USB, alors rm -rf build s'exécute sans invite.

Une invite qui affiche toujours Dangerous rm operation on mounted drive path signifie que la variable n'atteint pas la session :

• Variable dans un fichier de paramètres : Claude Code ignore la variable dans le bloc env d'un fichier de paramètres, quel que soit le type de fichier de paramètres, définissez donc plutôt la variable là où vous démarrez claude
• Session démarrée sans la variable : redémarrez claude depuis un environnement où la variable est définie, car une session en cours ne la prend pas en compte

Suppressions qui demandent toujours une approbation avec l'invite de lecteur monté désactivée

En mode Manual avec une règle allow pour rm, un rm sur un chemin de lecteur monté peut encore afficher une invite, sans la raison Dangerous rm operation on mounted drive path :

• Cible en dehors de vos répertoires de travail : rm -rf /Volumes/USB/other pendant que vous travaillez dans /Volumes/USB/project affiche une invite. Pour supprimer cette invite, ajoutez un répertoire qui contient la cible à la session
• Cible avec un * : rm -rf build/* affiche une invite. Approuvez cette invite pour exécuter la commande, ou demandez à Claude de nommer chaque cible sans *
• Cible qui est un chemin critique : /mnt lui-même et votre répertoire de travail lui-même restent des chemins critiques, donc rm -rf sur l'un ou l'autre affiche une invite. Approuvez cette invite pour laisser le rm s'exécuter

Suppressions de chemins critiques dans chaque mode de permission

Ce que Claude Code fait avec une suppression de chemin critique dépend de votre mode de permission :

Si une règle ask explicite correspond à la commande, Claude Code vous demande à la place, même en mode auto et sans limite de temps. Dans les modes qui demandent, un hook PermissionRequest peut répondre à l'invite.

Pour exécuter ces suppressions sans invite en mode bypassPermissions, consultez Désactiver l'invite de suppression de chemin critique.

Limites de temps et refus en modes auto et bypassPermissions

En modes auto et bypassPermissions, l'invite du terminal pour une suppression de chemin critique affiche un compte à rebours de deux minutes :

• Si le compte à rebours s'épuise avant que vous répondiez, Claude Code refuse la commande et dit à Claude quoi faire à la place, pour qu'une session sans surveillance continue de fonctionner.
• Appuyez sur n'importe quelle touche pendant que l'invite est ouverte pour arrêter le compte à rebours et garder l'invite en attente de votre réponse.
• Après trois de ces invites qui s'épuisent sans réponse dans une session, Claude Code arrête de les afficher et refuse immédiatement les suppressions de chemins critiques supplémentaires. L'envoi d'un nouveau message recommence le compte.

La limite de temps s'applique dans Claude Code v2.1.281 et ultérieur, tout comme le refus en mode auto hors du terminal.

Hors du terminal, vous ne recevez pas cette invite :

Partout où la suppression est refusée, vous pouvez lire la commande entière et l'exécuter dans votre shell.

Pour changer ce que vous obtenez dans chaque mode, définissez CLAUDE_CODE_DISABLE_DANGEROUS_RM_TIMEOUT sur 1 :

• bypassPermissions : l'invite du terminal n'a pas de limite de temps, et le panneau de chat VS Code vous demande
• auto : le classificateur décide, dans le terminal, le panneau de chat VS Code, les exécutions -p et les sessions Agent SDK

Définissez-la dans l'environnement qui démarre Claude Code, comme votre shell ou l'option env du SDK, et non dans un fichier de paramètres Claude Code. Pour le panneau de chat, ajoutez-la à claudeCode.environmentVariables dans le fichier utilisateur settings.json de VS Code lui-même, puis démarrez une nouvelle conversation :

{
  "claudeCode.environmentVariables": [
    { "name": "CLAUDE_CODE_DISABLE_DANGEROUS_RM_TIMEOUT", "value": "1" }
  ]
}

Désactiver l'invite de suppression de chemin critique en mode bypassPermissions

Pour exécuter sans invite, en mode bypassPermissions, les commandes Bash rm et rmdir qui ciblent des chemins critiques, démarrez Claude Code avec CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1 dans son environnement. Cela nécessite Claude Code v2.1.311 ou ultérieur. Claude Code lit la variable uniquement depuis l'environnement de lancement et l'ignore dans le bloc env d'un fichier de paramètres. Par exemple, définissez-la dans votre shell et démarrez claude depuis celui-ci :

macOS, Linux, WSL

export CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1
claude --permission-mode bypassPermissions

Windows PowerShell

$env:CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS = "1"
claude --permission-mode bypassPermissions

Windows CMD

set CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1
claude --permission-mode bypassPermissions

[!WARNING]

Avec cette variable définie, vous perdez une invite de sécurité pour les suppressions destructrices : une commande comme rm -rf ~ peut s'exécuter sans vous demander. Ne la définissez que dans un environnement isolé dont vous pouvez vous permettre de perdre le contenu.

Les suppressions s'exécutent sans invite uniquement dans le mode bypassPermissions lui-même, pas en mode plan, et uniquement pour ce que la vérification de chemin critique signale dans les outils Bash et Monitor. Cela inclut les commandes que Claude Code ne peut pas analyser entièrement, qui s'exécutent elles aussi sans invite.

Avis au démarrage concernant l'invite de suppression de chemin critique

Pour vérifier si CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS fonctionne, lisez la ligne que Claude Code affiche au démarrage. Dans une exécution -p, elle apparaît sur stderr. Dans une application Agent SDK, passez l'option stderr pour la lire. La ligne indique l'une des choses suivantes :

• is set, so dangerous rm commands can run without a prompt : les suppressions peuvent s'exécuter sans invite une fois les paramètres gérés et les hooks des plugins chargés. Si les suppressions continuent de recevoir une invite ou un refus, consultez Pourquoi l'invite de suppression de chemin critique reste active
• has no effect in this session : les suppressions conservent leur invite ou leur refus habituel pendant toute la session. Pour changer cela, trouvez votre cas dans Pourquoi l'invite de suppression de chemin critique reste active
• has no effect while the Windows registry cannot be read for managed settings : les suppressions conservent leur invite ou leur refus habituel, et la variable prend effet sans redémarrage si une lecture ultérieure du registre réussit. Si les suppressions continuent de recevoir une invite ou un refus, consultez Pourquoi l'invite de suppression de chemin critique reste active

L'absence de ligne ne signifie pas que l'invite est active : une application Agent SDK sans option stderr ne voit aucune ligne, et les suppressions peuvent tout de même s'exécuter sans invite. Sinon, vérifiez que vous avez défini la variable dans l'environnement de lancement, que la session peut passer en mode bypassPermissions, et que claude ne se trouve pas à l'intérieur d'une autre session. Certaines sessions démarrent sans la variable.

Si vous voyez l'une de ces lignes sans avoir défini la variable, trouvez où elle est définie, par exemple dans votre profil shell, et supprimez-la.

Pourquoi l'invite de suppression de chemin critique reste active

Si CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS n'a aucun effet et que les suppressions conservent leur invite ou refus habituel, recherchez des causes comme celles-ci :

• Autre chose gère les invites de permission : un --permission-prompt-tool ou un callback canUseTool de l'Agent SDK sans --permission-prompts none, un hook PermissionRequest avec n'importe quel matcher, ou un mod qui gère cet événement. Supprimez le hook, le mod, l'outil ou le callback et redémarrez claude
• Le panneau de chat de l'extension VS Code ou l'application Desktop exécute la session : démarrez plutôt claude dans un terminal, comme le terminal intégré d'un IDE
• Une règle couvre Bash, Edit ou Read : une règle deny ou ask qui cible l'un de ces outils, au lancement ou dès que Claude Code la lit pendant la session, même si vous la supprimez ensuite. Supprimez la règle et redémarrez claude. Pour exclure un outil, utilisez --tools au lieu d'une règle deny
• permissions.blockReadsOutsideWorkingDirectories est activé : supprimez le paramètre de chaque fichier de paramètres qui le définit sur true, puis redémarrez claude
• claude s'exécute à l'intérieur d'une autre session : un claude démarré depuis l'outil Bash d'une session ou depuis un hook, même avec la variable sur sa ligne de commande. Démarrez claude depuis votre propre shell. Ne comptez pas sur cette limite des sessions imbriquées comme frontière de sécurité
• Un hook PreToolUse répond ask pour une suppression : modifiez ce que le hook retourne
• Claude Code démarre la session pour vous : les sessions en arrière-plan, les coéquipiers d'une équipe d'agents dans des volets divisés et les sessions créées par un serveur Remote Control démarrent sans la variable. Démarrez claude depuis votre propre shell
• Les paramètres gérés ne peuvent pas être lus : Claude Code n'a pas réussi à lire vos sources de paramètres gérés. Si les paramètres gérés par le serveur continuent d'échouer au chargement, consultez Remote managed settings failed to load. Pour tout autre échec qui n'est pas une requête au registre, demandez à la personne qui gère cette source de le corriger
• Le registre Windows ne peut pas être interrogé : sous Windows et dans WSL, la variable nécessite une réponse du registre, même quand WSL ne l'utilise pas pour les paramètres. La requête peut échouer pendant toute la session sur un Windows non anglophone, dans WSL avec l'interop désactivée, ou dans un conteneur sur un noyau WSL2. Si l'interop est désactivée, activez-la. Sinon, exécutez ces suppressions vous-même

Remove-Item dans PowerShell

Quand vous activez l'outil PowerShell, Claude Code donne à Remove-Item et aux commandes intégrées cmd rd, rmdir, del, et erase leurs propres vérifications, distinctes de la liste des chemins critiques rm. Pour Remove-Item, le résultat dépend de la cible, et le premier cas correspondant s'applique :

• Chemins système : la racine du système de fichiers et ses répertoires de niveau supérieur, les racines des lecteurs et leurs répertoires de niveau supérieur, et votre répertoire personnel. Claude Code refuse la commande dans tous les modes, sans vous demander.
• Wildcards : un * nu, ou n'importe quelle cible se terminant par /* ou \*, y compris un glob sous une variable shell comme $dir/*. Claude Code refuse la commande dans tous les modes, sans vous demander, avant que le classificateur ne la voie.
• Votre répertoire de travail ou l'un de ses parents, avec -Recurse : Claude Code traite la commande comme n'importe quelle autre qui nécessite une approbation dans votre mode de permission, donc elle vous demande dans les modes qui demandent, l'envoie au classificateur en mode auto, et la refuse en mode dontAsk. Le mode bypassPermissions saute cette vérification.

Le cas des chemins système s'applique également à rd, rmdir, del, et erase quand Claude les exécute via cmd, comme dans cmd /c rd /s /q C:\Users. Par défaut, Claude Code refuse une telle commande dans tous les modes, sans vous demander. Cette vérification cmd nécessite Claude Code v2.1.283 ou ultérieur.

Lors de l'évaluation d'une cible cmd, Claude Code traite une variable PowerShell qui suit du texte littéral comme vide. Cela rend cmd /c rd /s /q "C:\$name" une suppression de C:\, donc elle est également refusée. Un wildcard final compte comme le dossier qu'il vide, donc cmd /c del /q C:\* est refusé et cmd /c del /q dist\* dans votre projet ne l'est pas.

Pour désactiver la vérification cmd, définissez CLAUDE_CODE_DISABLE_POWERSHELL_CMD_RM_DENY=1 dans l'environnement qui lance Claude Code. Claude Code ignore cette variable dans le bloc env d'un fichier de paramètres. Remove-Item sur un chemin système reste refusé de toute façon.

Voir aussi

• Permissions : règles allow, ask et deny ; politiques gérées
• Configurer le mode auto : indiquez au classificateur l'infrastructure de confiance de votre organisation
• Hooks : logique de permission personnalisée via les hooks PreToolUse et PermissionRequest
• Sécurité : protections et bonnes pratiques
• Sandboxing : isolation du système de fichiers et du réseau pour les commandes Bash
• Mode non-interactif : exécutez Claude Code avec le flag -p