SpyBara
Go Premium

permission-modes.md 2026-09-28 22:59 UTC to 2026-09-29 06:02 UTC

This page contains 167 additions and 129 deletions.

2026
Wed 9 22:58 Sat 12 03:02 Fri 18 23:58 Sat 19 23:57 Tue 22 23:59 Fri 25 23:58 Mon 28 22:59 Tue 29 06:02

Choisir un mode de permission

Contrôlez si Claude demande une approbation avant d'agir. Basculez entre les modes avec Maj+Tab dans la CLI, l'indicateur de mode dans VS Code, ou le sélecteur de mode dans Desktop.

Un mode de permission définit les actions que Claude Code peut effectuer dans une session sans vous demander d'abord. En mode Manuel, Claude Code s'arrête et vous demande avant la plupart des actions qui modifient des fichiers, exécutent des commandes shell ou accèdent au réseau. En mode auto, un second modèle, le classificateur, examine les actions à votre place ; comment le classificateur évalue les actions énumère les actions qu'il examine et celles qu'il ignore.

Avec Claude Code v2.1.283 ou version ultérieure, le mode auto est le mode de permission de démarrage intégré pour les sessions de terminal interactif et VS Code. Sur les versions antérieures, c'est le mode de permission de démarrage intégré uniquement sur les plans Pro, Max et Team. Quel mode une session démarre couvre les surfaces et les paramètres qui changent le mode de permission de démarrage. Vous pouvez également modifier le mode de permission d'une session en cours à tout moment.

Modes disponibles

Chaque mode fait un compromis différent entre la commodité et la supervision. Le tableau ci-dessous montre ce que Claude peut faire sans invite de permission dans chaque mode. Le mode Manuel apparaît sous sa valeur de configuration, default.

Mode Ce qui s'exécute sans demander Idéal pour
default Lectures uniquement Examiner chaque action vous-même, travail sensible
acceptEdits Lectures, modifications de fichiers et commandes courantes du système de fichiers (mkdir, touch, mv, cp, etc.) Itération sur le code que vous examinez
plan Lectures, plus commandes approuvées par le classificateur quand le mode auto est disponible Explorer une base de code avant de la modifier
auto Tout, avec des vérifications de sécurité en arrière-plan Tâches longues, réduction de la fatigue des invites
dontAsk Lectures et outils pré-approuvés ; tout ce qui déclencherait une invite est refusé CI verrouillé et scripts
bypassPermissions Tout Conteneurs et machines virtuelles isolés uniquement

Le mode qui examine chaque action s'appelle Manual dans la CLI, dans claude --help, dans les extensions VS Code et JetBrains, et dans l'application de bureau. Sa valeur de configuration est default, ce que les hooks et les intégrations SDK utilisent. La CLI accepte manual comme alias partout où vous tapez la valeur, par exemple claude --permission-mode manual ou "defaultMode": "manual". L'étiquette Manual et l'alias manual nécessitent Claude Code v2.1.200 ou version ultérieure. L'étiquette de l'application de bureau ne dépend pas de votre version CLI.

Les écritures vers les chemins protégés ne sont jamais auto-approuvées sauf en mode bypassPermissions et dans les sessions en mode plan où les permissions de contournement sont disponibles, ce qui signifie les sessions démarrées d'une manière qui place bypassPermissions dans le cycle de mode.

Les modes définissent la ligne de base. Superposez les règles de permission sur le dessus pour pré-approuver ou bloquer des outils spécifiques. Les règles de refus bloquent dans tous les modes, y compris bypassPermissions. Les règles de refus et de demande ne s'appliquent pas à EndConversation tant que Claude a au moins un autre outil qu'il peut appeler. Les règles d'autorisation n'ont aucun effet en mode bypassPermissions.

Actions qu'aucun mode n'auto-approuve

Claude Code n'auto-approuve pas les éléments suivants dans aucun mode, y compris bypassPermissions. Chaque point renvoie à la section qui dit ce qui se passe à la place dans chaque mode :

  • Outils correspondant à une règle ask explicite

  • Outils de connecteur que votre organisation a définis sur ask, dans les sessions où ce paramètre atteint Claude Code

  • Outils qui nécessitent une interaction utilisateur : l'outil intégré AskUserQuestion et les outils MCP marqués requiresUserInteraction

  • Les suppressions rm et rmdir ciblant un chemin critique, qu'aucune règle allow ou hook PreToolUse "allow" n'approuve

  • Les protections de messagerie inter-sessions

  • Les lectures en dehors des répertoires de travail tandis que permissions.blockReadsOutsideWorkingDirectories est activé : les commandes Bash reconnues de lecture de fichiers et tout retry non sandboxé qui nécessite une approbation pour s'exécuter en dehors du sandbox même en mode auto et mode bypassPermissions. Nécessite Claude Code v2.1.257 ou version ultérieure.

    Une commande que l'analyseur de shell ne peut pas tracer, comme une qui change de répertoire plus d'une fois ou exécute un sous-shell, demande de la même manière même quand elle ne nomme aucun chemin extérieur. Cette invite ne s'applique pas quand la commande s'exécute dans le sandbox et le sandbox applique le bloc.

Configurations courantes

Les modes de permission décident si Claude demande une confirmation avant une action, et le sandbox Bash et les limites d'isolation externes décident ce qu'une action peut atteindre une fois qu'elle s'exécute. Chaque ligne ci-dessous associe un objectif aux drapeaux ou paramètres qui vous y mènent et à l'isolation nécessaire, comme point de départ. Les modes disponibles énumère ce qui s'exécute sans invite dans chaque mode.

Vous voulez Commencez par Isolation nécessaire Notes
Examiner chaque action vous-même Mode manuel : claude --permission-mode default Aucune Travail sensible, code non familier
Itérer localement avec moins d'invites, sans classificateur Mode manuel plus le sandbox Bash en mode auto-allow : claude --permission-mode default, puis exécutez /sandbox et sélectionnez auto-allow Le sandbox Bash intégré, sur macOS, Linux et WSL2 Les règles de refus s'appliquent toujours, et les règles d'ask qui nomment une commande, comme Bash(git push *), invitent toujours. Pour activer le sandbox à partir d'un fichier de paramètres à la place, définissez sandbox.enabled sur true
Explorer avant de modifier quoi que ce soit claude --permission-mode plan Aucune Claude Code bloque les modifications jusqu'à ce que vous approuviez un plan
Travailler en mode automatique sans intervention claude --permission-mode auto, le mode de permission de démarrage intégré avec v2.1.283 ou ultérieur Aucune ; un sandbox ou un conteneur ajoute une défense en profondeur Nécessite un modèle pris en charge, et votre organisation peut désactiver le mode auto
Exécuter en CI avec une liste d'autorisation exacte claude -p "run the test suite" --permission-mode dontAsk --allowedTools "Bash(npm test)" "Read" Aucune au-delà de ce que votre exécuteur CI fournit Les sessions cloud ignorent dontAsk des fichiers de paramètres
Exécuter complètement sans surveillance à l'intérieur d'un conteneur claude -p "<prompt>" --dangerously-skip-permissions Obligatoire : un conteneur, une VM ou le runtime sandbox ; sur Linux et macOS, exécutez-le en tant qu'utilisateur non-root Les sessions cloud ignorent ce mode des fichiers de paramètres. Dans cette exécution -p, les quelques appels qui inviteraient toujours sont refusés à la place

Le sandbox Bash et le mode auto fonctionnent indépendamment et se combinent, avec les exceptions énumérées sous Sandbox modes. Pour l'interaction complète, consultez How sandboxing relates to permissions and permission modes et How isolation relates to permission modes.

Quel mode une session démarre

Quand vous démarrez une nouvelle session dans un terminal, Claude Code prend le mode de permission du premier de ces éléments qui s'applique :

  1. Le drapeau --permission-mode, ou --dangerously-skip-permissions

  2. permissions.defaultMode dans un fichier de paramètres

    Si vous définissez "auto" dans .claude/settings.json ou .claude/settings.local.json, la valeur ne prend pas effet, et Claude Code utilise alors la valeur par défaut intégrée plutôt qu'un defaultMode de ~/.claude/settings.json. Si vous définissez "bypassPermissions" dans ces deux fichiers, cela ne prend pas effet non plus, et la session démarre en mode Manuel. Les autres valeurs s'appliquent à partir de n'importe quel fichier de paramètres.

  3. La valeur par défaut intégrée

Les conversations que l'extension VS Code démarre suivent la propre liste de l'extension dans Basculer les modes de permission. Pour le mode de permission dans lequel Claude Code démarre une session reprise, voir mode de permission à la reprise.

La valeur par défaut auto intégrée nécessite Claude Code v2.1.228 ou version ultérieure sur macOS, Linux et WSL, et v2.1.233 ou version ultérieure sur Windows natif. Sur les versions antérieures, la valeur par défaut intégrée est Manuel.

La valeur par défaut intégrée dépend de la façon dont vous exécutez Claude Code. La première ligne qui correspond à votre session s'applique. Le tableau couvre les sessions que vous démarrez dans un terminal ou via l'extension VS Code ; pour l'application de bureau et claude.ai, voir les onglets Desktop et Web dans Basculer les modes de permission.

Comment vous exécutez Claude Code Mode de permission de démarrage intégré
Un fichier de paramètres définit disableAutoMode sur "disable" default
claude -p ou le SDK Agent default
Dans un terminal ou via l'extension VS Code auto avec Claude Code v2.1.283 ou version ultérieure ; sur les versions antérieures, auto sur les plans Pro, Max ou Team dans les sessions qui récupèrent les drapeaux de fonctionnalité, et default sinon

Dans votre première session après une installation ou une mise à niveau, Claude Code peut choisir le mode de permission de démarrage avant l'arrivée de ses drapeaux de fonctionnalité. Cette session peut démarrer dans un mode de permission différent de celui que le tableau indique, et votre session suivante correspond au tableau.

Quand le drapeau, un fichier de paramètres ou la valeur par défaut intégrée sélectionne auto mais que le mode auto n'est pas disponible pour la session, Claude Code démarre la session en mode Manuel à la place. Le mode auto est indisponible quand la session ne répond pas aux exigences de disponibilité, comme un fichier de paramètres le désactivant ou un modèle qui ne le supporte pas, ou quand Anthropic l'a temporairement désactivé côté serveur.

La première fois que la valeur par défaut intégrée démarre l'une de vos sessions en mode auto, Claude Code affiche un avis qui renvoie à cette page :

  • Dans un terminal, une fois, en haut de la session
  • Dans l'extension VS Code, sous forme de carte sur l'écran de nouvelle conversation qui reste jusqu'à ce que vous la fermiez

Sur les plans Pro, Max et Team, si votre ~/.claude/settings.json définit un defaultMode autre que auto et qu'aucun autre fichier de paramètres n'en définit un, vos sessions continuent à démarrer dans ce mode. Claude Code demande une fois, dans le terminal ou dans l'extension VS Code, si vous souhaitez modifier le paramètre en mode auto. Si vous refusez, votre paramètre reste tel quel.

Démarrer dans un mode de permission différent

Vous pouvez définir le mode de permission de démarrage pour une session, ou comme valeur par défaut pour chaque session sur une machine, dans un projet ou dans une organisation. Quand plus d'un fichier de paramètres définit permissions.defaultMode, la précédence des paramètres décide, donc une valeur de projet ou gérée surclasse ~/.claude/settings.json. Pour modifier le mode de permission d'une session déjà en cours, voir Basculer les modes de permission.

Pour définir le mode de permission de démarrage pour Faites ceci
Une session que vous êtes sur le point de démarrer Passez le mode de permission en tant que drapeau, par exemple claude --permission-mode default
Chaque session de terminal que vous démarrez sur cette machine Définissez permissions.defaultMode dans ~/.claude/settings.json. Pour ce que l'extension VS Code lit, voir Basculer les modes de permission
Chaque session de terminal que vous démarrez dans un projet Définissez permissions.defaultMode dans le .claude/settings.json du projet. Les sessions que vous démarrez dans un terminal honorent chaque valeur sauf auto et bypassPermissions ; les sessions que l'extension VS Code démarre ne lisent pas les paramètres du projet pour le mode de permission de démarrage
Chaque session de terminal dans votre organisation Définissez permissions.defaultMode dans les paramètres gérés. Les sessions de terminal démarrent dans ce mode et les gens peuvent toujours basculer vers le mode auto ; pour ce que l'extension VS Code lit, voir Basculer les modes de permission. Pour supprimer le mode auto afin que personne ne puisse le sélectionner, définissez permissions.disableAutoMode sur "disable" à la place

Cet exemple fait que chaque session de terminal sur votre machine démarre en mode Manuel, dont la valeur de configuration est default. Enregistrez-le dans ~/.claude/settings.json :

{
  "permissions": {
    "defaultMode": "default"
  }
}

La session suivante que vous démarrez affiche ⏸ manual mode on dans la barre d'état.

Basculer les modes de permission

Chaque interface a son propre contrôle pour basculer les modes de permission pendant une session et sa propre façon de choisir le mode de permission que les nouvelles sessions démarrent. Sélectionnez votre interface pour voir ses contrôles.

En cours de session : appuyez sur Shift+Tab pour parcourir les modes de permission. À partir de auto, le premier appui bascule vers default, et le cycle s'exécute ensuite default → acceptEdits → plan → retour à default. Les modes optionnels, décrits ci-dessous, s'insèrent après plan. La barre d'état affiche le mode actif sous la forme d'un ⏸ manual mode on gris pour default, ou sous la forme ⏵⏵ accept edits on, ⏸ plan mode on, ⏵⏵ auto mode on, ⏵⏵ don't ask on, ou ⏵⏵ bypass permissions on.

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.

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

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. Les chemins en dehors de cette portée, les écritures vers les chemins protégés, les suppressions rm et rmdir ciblant un chemin critique, et toutes les autres commandes Bash sauf l'ensemble intégré en lecture seule invitent toujours.

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

Analysez avant de modifier avec le mode plan

Le mode plan indique à Claude de rechercher et de proposer des modifications sans les effectuer. Claude lit les fichiers, exécute des commandes shell pour explorer et rédige un plan, mais ne modifie pas votre source. Sauf dans les sessions avec les permissions de contournement disponibles, les modifications restent bloquées jusqu'à ce que vous approuviez le plan.

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

  • Sessions de terminal interactives avec permissions de contournement disponibles : ni le classificateur ni une invite ne s'appliquent aux commandes de planification. Ignorer tous les contrôles avec le mode bypassPermissions couvre les quelques choses qui invitent toujours là.
  • Mode auto disponible et le paramètre useAutoModeDuringPlan activé, ce qui est le cas par défaut : le classificateur examine les commandes shell autres que les suppressions de chemin critique au lieu de vous inviter. Les commandes approuvées s'exécutent, et les commandes rejetées sont bloquées.
  • Mode auto non disponible, ou useAutoModeDuringPlan désactivé : les commandes en dehors de l'ensemble intégré en lecture seule invitent une approbation, y compris quand le mode auto-allow du sandbox est activé.

Entrez en mode plan en appuyant sur Shift+Tab ou en préfixant une seule invite avec /plan. Vous pouvez également démarrer en mode plan à partir de la CLI :

claude --permission-mode plan

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

Examinez et approuvez un plan

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

  • Oui, et utiliser le mode auto : 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 lit Oui, auto-accepter les modifications. Si vous avez démarré la session avec les permissions de contournement activées, l'option lit Oui, et basculer vers BYPASS PERMISSIONS (aucune invite supplémentaire) pour cette session à la place.
  • Oui, approuver manuellement les modifications : approuver et examiner chaque modification individuellement.
  • Non, continuer la planification : rester en mode plan et dire à Claude ce qu'il faut modifier.

L'approbation d'un plan quitte le mode plan et bascule la session vers le mode de permission que chaque option d'approbation décrit, de sorte que Claude commence à modifier. Pour planifier à nouveau, revenez au mode plan avec Shift+Tab, ou préfixez votre prochaine invite 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 procède. Quand showClearContextOnPlanAccept est activé, la liste gagne une première option qui approuve le plan et efface le contexte de planification.

L'acceptation d'un plan donne également à la session un titre généré basé sur le plan, sauf si vous avez déjà nommé la session.

Définissez le mode plan comme valeur par défaut

Pour faire du mode plan la valeur par défaut pour les sessions de terminal d'un projet, définissez defaultMode sur plan dans .claude/settings.json, placé comme l'exemple sous Démarrer dans un mode de permission différent le montre. Les conversations que l'extension VS Code démarre ne lisent pas les paramètres du projet pour le mode de permission de démarrage. Là, définissez claudeCode.initialPermissionMode sur plan dans vos paramètres utilisateur VS Code à la place.

Éliminer les invites de permission avec le mode auto

Le mode auto permet à Claude d'exécuter sans invites de permission routinières. 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 invite.

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 structuré d'équipe d'agents, 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 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 invite ou une compétence s'y fient explicitement. Pour un comportement plus autonome dans un mode qui vous invite toujours, définissez plutôt le style de sortie proactif.

Le mode auto est disponible uniquement quand 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, ou un modèle Fable. Sur Amazon Bedrock, la plateforme d'agents de Google Cloud, 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, et les modèles Fable. Les modèles plus anciens, y compris Sonnet 4.5, Opus 4.5, Haiku et les modèles claude-3, ne sont pas pris en charge sur aucun fournisseur.
  • Fournisseur : disponible par défaut sur l'API Anthropic, Claude Platform sur AWS, Amazon Bedrock, la plateforme d'agents de Google Cloud, 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 critères 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, donc 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 demande 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 Changer les modes de permission.

Mode auto sur Bedrock, Agent Platform ou Foundry

Sur Amazon Bedrock, la plateforme d'agents de Google Cloud, Microsoft Foundry et les sessions de passerelle d'applications Claude connectées, le mode auto est disponible par défaut. Avec Claude Code v2.1.283 ou ultérieur, c'est aussi le mode de permission intégré de démarrage pour les sessions de terminal interactif et VS Code. Pour choisir vous-même le mode de permission de démarrage, définissez permissions.defaultMode comme le décrit Démarrer dans un mode de permission différent, ou choisissez un mode de permission dans l'indicateur de mode de l'extension VS Code.

Seuls Claude Sonnet 5 ou ultérieur, Opus 4.7 ou ultérieur, 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.

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'à sa fin.

Dans v2.1.158 à v2.1.206, le mode auto était désactivé sur ces fournisseurs jusqu'à ce que vous définissiez CLAUDE_CODE_ENABLE_AUTO_MODE=1, et Claude Code ignorait defaultMode: "auto" sur ces fournisseurs à moins que la variable ne soit également définie. La variable est toujours acceptée pour la compatibilité et n'a aucun effet à partir de v2.1.207.

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 demandes de modèle de la session, à la place d'envoyer ses propres demandes de classificateur. Ces sessions demandent :

  • Une connexion directe à l'API Anthropic : dans une session de terminal interactif, sur tous les plans claude.ai et sur les comptes qui utilisent l'API Claude, au fur et à mesure qu'Anthropic le déploie. 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. À partir de v2.1.282, une session qui ne récupère pas les drapeaux de fonctionnalité, 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, ou une passerelle LLM ou un proxy : sur Claude Platform sur AWS, Amazon Bedrock, la plateforme d'agents de Google Cloud 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

Où le serveur examine les actions, ses verdicts les 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 supprime la demande 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 revient à ses propres demandes de classificateur. Une fois que ce retour en arrière tient pour le reste de la session, il affiche un avis sur les frais de demande de classificateur sur les comptes où ces demandes 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 ignorer la demande au serveur et toujours utiliser les propres demandes 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, comme une session -p ou Agent SDK, à 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 de demander au serveur, sauf comme le décrit Désactiver les capacités de pré-version.

Ce que le classificateur bloque par défaut

Le classificateur fait confiance à votre répertoire de travail et aux télécommandes qui ont été configurées pour lui quand la session a démarré. Une télécommande ajoutée ou réorientée pendant la session avec git remote add ou git remote set-url n'est pas approuvée, et tout le reste est traité comme externe jusqu'à ce que vous configuriez l'infrastructure approuvée. Avant v2.1.200, les télécommandes ajoutées en milieu de session étaient également approuvées.

Bloqué par défaut :

  • Téléchargement et exécution de code, comme curl | bash
  • Envoi de données sensibles à des points de terminaison externes
  • Déploiements et migrations de production
  • Suppression en masse sur le stockage cloud
  • Octroi de permissions IAM ou de dépôt
  • Modification d'infrastructure partagée
  • Destruction irréversible de fichiers qui existaient avant la session
  • Forcer la poussée
  • Valider ou pousser une modification qui enverrait des secrets ou des données sensibles en dehors du dépôt quand elle s'exécute, ou élargir ce qu'un déploiement expose. Cela couvre un flux de travail 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, et une modification de configuration qui élargit ce qu'un déploiement publie, comme un registre, une visibilité, un artefact ou un paramètre 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 validée ou poussée, que ce commit ou cette poussée déclenche le pipeline ou non ; la clarifier nécessite de nommer l'effet d'exécution, pas seulement le commit ou la poussée. Avant v2.1.211, cette vérification était limitée à la branche par défaut à la place : une poussée là était bloquée quand elle portait du contenu sensible, des modifications dissimulées ou mal décrites par rapport à ce que vous avez demandé, du contenu porté de l'extérieur du dépôt, ou contourné une révision que vous avez demandée
  • git reset --hard, git checkout -- ., git restore ., git clean -fd, git stash drop ou git stash clear, que le classificateur présume éliminerait les modifications non validé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 réécriture de message uniquement n'est pas bloquée : --amend -m sans rien de nouvellement préparé, sur un commit que Claude a créé pendant cette session
  • terraform destroy, pulumi destroy, cdk destroy ou terragrunt destroy, et appliquer un plan qui détruit des ressources

Claude Code v2.1.195 et ultérieur bloquent plus de catégories par défaut. Plusieurs dépendent d'entrées d'environnement, comme les cibles de télécommande sensibles et les portées IaC protégées, que vous pouvez affiner à des noms concrets.

  • Écriture dans un gestionnaire de secrets, ou modification des enregistrements DNS ou des certificats TLS
  • Fusion d'une demande de tirage qu'aucun humain n'a approuvée, approbation de la propre demande de tirage de Claude, ou désactivation des vérifications CI
  • Publication d'un commentaire qui est lui-même une commande à l'automatisation, comme atlantis apply ou le /deploy ou /merge d'un bot
  • Basculement, augmentation ou suppression d'un drapeau de fonctionnalité de production
  • Application de modifications d'infrastructure à une portée IaC protégée, ou drainage 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 transferts de port vers une cible de télécommande sensible
  • Ouverture d'un tunnel ou d'un shell inverse qui rend un service local accessible depuis l'internet public
  • Impression d'une identifiant ou d'un jeton en direct dans la transcription ou un fichier
  • Accès à un emplacement répertorié comme emplacement de données sensibles dans votre environnement, ou copie de données hors de celui-ci. À partir de v2.1.198, cela bloque également l'envoi de données d'un vers un public que l'entrée exclut
  • Routage d'une installation de paquet autour de votre registre de paquet interne vers un registre public. À partir de v2.1.198, cela s'applique également quand vous avez dit à Claude qu'un registre interne ou un miroir existe dans la conversation, pas seulement quand un est répertorié dans votre environnement
  • Exécution d'une commande avec un drapeau qui désarme une garde de sécurité, comme --insecure
  • Lancement d'une boucle d'agent autonome qui s'exécute sans approbation humaine ou bac à sable, comme une lancée avec --dangerously-skip-permissions ou --no-sandbox. À partir de v2.1.198, cela couvre également l'exécution d'un agent tiers ou d'un harnais d'évaluation avec isolation et approbation par action désactivées, comme un coureur 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

Claude Code v2.1.198 et ultérieur bloquent également ceux-ci par défaut :

  • Suppression de fichiers dans /tmp, $TMPDIR ou un autre répertoire de travail partagé ou de cache 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 le contenu envoyé, téléchargé, publié ou écrit à d'autres personnes ou systèmes partagés, quand votre propre message n'a pas autorisé ces détails pour ce destinataire. Les corps de PR et de problème, 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. La portée de PR, de problème et de message de commit nécessite Claude Code v2.1.200 ou ultérieur. Les données personnelles en direct d'une réponse API dans un corps de PR ou de problème, 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é du dépôt ou de la limite de confiance. Cette vérification nécessite Claude Code v2.1.203 ou ultérieur
  • Envoi de frappes au clavier au propre volet tmux de Claude Code pour piloter sa propre interface, que le classificateur traite comme Claude changeant ses propres permissions ou surveillance

Claude Code v2.1.200 et ultérieur bloquent également ceux-ci par défaut :

  • Commentaire, suppression ou passage en force d'un test ou d'une assertion qui protège le comportement de sécurité, comme l'authentification, le contrôle d'accès, la validation d'entrée ou le bac à sable
  • 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 API, d'un point de terminaison proxy, d'un récepteur 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 poussées avec git remote set-url ou git remote add, à moins que vous n'ayez nommé la nouvelle télécommande
  • Poussée de secrets ou de données personnelles ou confiées vers un dépôt connu pour être public, ou poussée de matériel confidentiel là 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 ; les deux raffinements nécessitent Claude Code v2.1.203 ou ultérieur. Avant v2.1.203, les données personnelles étaient groupées avec le matériel confidentiel et bloquées uniquement quand elles ne faisaient pas partie du travail propre de ce dépôt. Quand la visibilité d'un dépôt n'est pas établie, le classificateur ne bloque pas sur cela seul ; il juge le contenu par rapport aux autres règles à la place
  • Ouverture d'une demande de tirage contre un dépôt ou une organisation différente, bifurcation avec gh repo fork, ou poussée vers un dépôt tiers, à moins que vous n'ayez nommé cette cible externe

Claude Code v2.1.203 et ultérieur bloquent également ceux-ci par défaut :

  • Contenu 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, une poussée, un texte de PR ou de problème, une giste ou un collage, 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 de points de configuration d'identifiant et de configuration comme les clés SSH, les identifiants cloud, les profils de navigateur et l'historique du shell, et les exportations de données utilisateur comptent tous, et le dépôt étant privé ne le clarifie pas

Claude Code v2.1.205 et ultérieur bloquent également ceux-ci par défaut :

  • É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é à une telle variable. La valeur provenait uniquement de la 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 bloc se clarifie 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 la cible le classificateur peut résoudre ne sont pas affectées.

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

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

  • Demande d'identifiants à partir du point de terminaison 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
  • Atteinte d'un hôte public par une route autre qu'une demande 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 du registre de conteneurs du nœud
  • Connexion à ou analyse de conteneurs, pods ou VMs frères que Claude n'a pas démarrés, ou le nœud sous le conteneur

Si Claude Code s'exécute quelque part qui est censé permettre l'un de ceux-ci, décrivez cette configuration dans une entrée Host containment dans autoMode.environment.

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

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

Autorisé par défaut :

  • Opérations de fichier local 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
  • Demandes HTTP en lecture seule
  • Poussée vers n'importe quelle branche du dépôt sur lequel vous travaillez, y compris la branche par défaut. Une branche non par défaut dont le nom la marque comme cible de déploiement ou de publication, comme production ou gh-pages, n'est pas couverte : le classificateur juge une poussée là sur ses propres termes. Le contenu de la poussée est toujours vérifié par rapport aux autres règles, les règles permissions.deny peuvent toujours bloquer les commandes de poussée telles qu'écrites dans chaque mode, et la protection de branche propre de la télécommande s'applique toujours. Avant v2.1.211, seules les poussées vers la branche sur laquelle vous avez démarré, les branches que Claude a créées, et les poussées routinières vers la branche par défaut étaient autorisées par défaut, et avant v2.1.203 toute poussée directe vers la branche par défaut était bloquée

Claude Code v2.1.195 et ultérieur autorisent également ceux-ci par défaut :

  • Suppression des tâches exactes que Claude a créées plus tôt dans la même session
  • Lecture, révision 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 vers les domaines approuvés, les buckets et les services que vous répertoriez dans environment. Cela couvre le flux de données uniquement, pas les opérations destructrices ou d'identifiant sur la même infrastructure
  • Claude dans Chrome navigation vers un domaine interne approuvé, localhost ou une URL que vous avez nommée

Les commandes en bac à sable n'obtiennent pas d'accès réseau par défaut. Claude nomme les hôtes qu'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 atteint un hôte non répertorié.

Exécutez claude auto-mode defaults pour imprimer les listes de règles complètes en JSON. Si les actions routinières 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 demande de tirage qui correspond à votre demande s'exécutent sans invite, à moins que la poussée ou la demande de tirage ne tombe sous la liste bloquée, comme des secrets ou des données sensibles quittant le dépôt, ou une demande de tirage qui cible un dépôt ou une organisation différente. Pour exiger un point de contrôle 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 courantes.

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

Tandis que permissions.blockReadsOutsideWorkingDirectories est désactivé, les lectures de fichier s'exécutent sans invite 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 d'eux, Claude Code demande s'il faut autoriser cette lecture.

L'invite n'apparaît pas dans les exécutions -p non interactives ou les sessions en arrière-plan ; les lectures là 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 l'invite 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 ces 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 invite à nouveau
  • 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 invite à nouveau

Limites que vous énoncez dans la conversation

Le classificateur traite les limites que vous énoncez dans la conversation comme un signal de bloc. Si vous dites à Claude « ne poussez pas » ou « attendez 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 une règle deny à la place.

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 clarifier le bloc. La façon dont vous l'avez formulé décide 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 la chose spécifique qui la rend dangereuse, comme la branche d'une poussée forcée. Nommer le verbe seul ne clarifie rien, donc « vous pouvez forcer la poussée » laisse le bloc en place.
  • Attendez-vous à ce qu'elle couvre une action : une approbation couvre l'action destructrice que vous avez nommée, donc une action ultérieure est bloquée à nouveau à moins que vous n'ayez accordé l'approbation en tant que permanente. Pour arrêter d'approuver un modèle routinier une action à la fois, ajoutez-le à autoMode.allow.
  • Certains blocs restent en place : l'ordre de précédence du classificateur énonce les blocs que votre approbation peut atteindre. Pour exécuter une étape qu'elle ne clarifiera pas, quittez le mode auto et répondez à l'invite de permission.

Quand le mode auto revient en arrière

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. Quand le classificateur produit aucun verdict sur l'action, parce qu'une vérification de sécurité distincte du mode auto a refusé la propre demande du classificateur ou sa réponse n'a pas été analysée, Claude Code refuse l'action sans la notification ou l'entrée Recently denied.
  • Blocs répétés : si le classificateur bloque une action 3 fois de suite ou 20 fois au total, le mode auto s'interrompt et Claude Code reprend l'invite. Approuver l'action invitée reprend le mode auto. Ces seuils ne sont pas configurables. Toute action autorisée réinitialise le compteur consécutif, tandis que le compteur total persiste pour la session et se réinitialise uniquement quand sa propre limite déclenche un retour en arrière. Claude Code ne compte pas un refus vers l'un ou l'autre seuil quand une vérification de sécurité distincte du mode auto refuse la demande du classificateur ; l'entrée liée couvre comment Claude Code gère ces refus.
  • Sessions qui ne peuvent pas inviter : une exécution -p non interactive sans --permission-prompt-tool n'a pas d'invite pour revenir en arrière. Quand les blocs répétés atteignent un seuil, l'action ne s'exécute pas et Claude continue à travailler. La même chose s'applique quand une vérification de sécurité distincte du mode auto refuse la demande du classificateur. Claude Code n'arrête pas l'exécution dans l'un ou l'autre cas.
  • Aucun verdict du serveur : sous 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 les modes de permission tandis qu'une vérification de classificateur est en attente, Claude Code rejette un verdict que le nouveau mode n'aurait pas demandé plutôt que de l'appliquer : vous êtes invité pour approbation à la place, ou l'action est auto-refusée en mode dontAsk.

Les blocs 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 faites en sorte qu'un administrateur configure l'infrastructure approuvée.

Chaque action passe par un ordre de décision fixe. La première étape correspondante gagne : 
1. Les actions correspondant à vos [règles allow, ask ou deny](/docs/fr/permissions#manage-permissions) se résolvent immédiatement, avec ces exceptions :
   * Les écritures vers [chemins protégés](#protected-paths) sont acheminées vers le classificateur même quand une règle allow correspond
   * Aucune règle allow n'approuve les suppressions `rm` et `rmdir` ciblant un [chemin critique](#critical-paths)
   * Les outils MCP marqués [`requiresUserInteraction`](/docs/fr/mcp#require-approval-for-a-specific-tool) vous invitent directement 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`](/docs/fr/mcp#organization-controls-on-connector-tools) dans les sessions où ce paramètre atteint Claude Code
   * Une commande shell qui porte [domaines autorisés par commande](/docs/fr/sandboxing#per-command-allowed-domains-in-auto-mode) est également acheminée vers le classificateur même quand une règle allow correspond, parce qu'une règle approuve la commande, pas ses hôtes
   * Les règles ask qui correspondent sur le contenu d'une commande, comme `Bash(git push *)`, reviennent à une invite de permission
   * Une écriture que la [vérification de lien symbolique](/docs/fr/permissions#symlinks) résout à un chemin protégé vous invite quand le chemin que Claude a demandé n'est pas lui-même protégé
2. Les actions en lecture seule et les éditions de fichier dans votre répertoire de travail sont auto-approuvées, sauf les écritures vers [chemins protégés](#protected-paths) et [la première lecture en dehors des répertoires de travail](#first-read-outside-the-working-directories), qui vous invite
   * Dans une session avec [examen du classificateur côté serveur](#server-side-classifier-review), les actions en lecture seule et les commandes shell [en bac à sable](/docs/fr/sandboxing#sandbox-modes) attendent cet examen et sont bloquées s'il les signale
   * Une écriture dans votre répertoire de travail que la [vérification de lien symbolique](/docs/fr/permissions#symlinks) résout à un emplacement en dehors de celui-ci vous invite
3. Tout le reste va au classificateur, à part les [suppressions de chemin critique](#critical-paths) sous leur gestion par défaut. Les outils de connecteur et les outils MCP `requiresUserInteraction` qui vous invitent directement à l'étape 1 n'atteignent jamais le classificateur non plus, donc ni une approbation requise par l'organisation ni une étape de consentement n'est auto-approuvée
4. Si le classificateur bloque, Claude reçoit la raison et essaie une alternative. Dans la plupart des sessions, la raison nomme la règle que le classificateur a correspondue, comme `[Data Exfiltration]`, plutôt que de donner une explication écrite ; voir [Examiner les refus](/docs/fr/auto-mode-config#review-denials)

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

* Blanket `Bash(*)` ou `PowerShell(*)`
* Interpréteurs avec caractères génériques comme `Bash(python*)`
* Commandes d'exécution du gestionnaire de paquet
* Règles `Agent` allow
* Règles [`Monitor`](/docs/fr/tools-reference#monitor-tool) allow, parce que 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 éliminerait le travail non validé, comme `git reset --hard` ou `rm -rf`, et montre au classificateur si du travail préparé, 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 demandes de classificateur envoyées par Claude Code lui-même, le classificateur voit les messages utilisateur, les appels d'outil autres que les recherches en lecture seule comme les lectures de fichier et les recherches, et votre contenu CLAUDE.md. Les résultats d'outil sont supprimés de ces demandes, donc le contenu hostile dans un fichier ou une page web ne peut pas manipuler le classificateur directement.

Vous pouvez annoter le résultat d'un appel avec le champ `classifierContext` d'un [hook PostToolUse](/docs/fr/hooks#annotate-a-result-for-the-auto-mode-classifier), 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'outil 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](https://claude.com/blog/auto-mode) et l'[approfondissement technique](https://www.anthropic.com/engineering/claude-code-auto-mode).
Comment le mode auto gère les sous-agents

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

  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. Tandis que le sous-agent s'exécute, chacune de ses actions passe par le classificateur avec les mêmes règles que la session parent, et 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 toujours 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 pour vérifier le travail du sous-agent avant d'agir en fonction de celui-ci.
Coût et latence

Le classificateur s'exécute sur Claude Sonnet 5 par défaut plutôt que sur votre sélection /model. Un modèle de classificateur qu'Anthropic configure côté serveur prend précédence sur ce défaut. Quand le modèle de votre session est Claude Sonnet 4.6, ou quand availableModels exclut Sonnet 5, le classificateur s'exécute sur le modèle de votre session à la place, ou sur un modèle Opus quand la session s'exécute sur un modèle Fable ; sur les fournisseurs autres que l'API Anthropic, ce retour en arrière Opus est le modèle Opus par défaut du fournisseur.

La première demande en mode auto de la session valide le défaut Sonnet 5 : si la demande réussit, Sonnet 5 reste le modèle de classificateur de la session, et si elle échoue parce que le modèle n'est pas disponible, la session utilise le retour en arrière à la place. Après que cette validation se règle, le modèle du classificateur ne change pas pour la session.

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

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

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 invite. 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, ainsi que les actions correspondant à vos règles permissions.allow et les appels approuvés par un hook PreToolUse. 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 ; cela nécessite Claude Code v2.1.199 ou ultérieur.

Les suppressions rm et rmdir ciblant un chemin critique, comme rm -rf / et rm -rf ~, sont refusées même quand une règle allow les correspond ou qu'un hook PreToolUse les approuve.

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.

Les actions qu'aucun mode n'auto-approuve invitent toujours dans ce mode. Les Remove-Item dans PowerShell refusent également s'appliquent 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 inviter. Les règles ask explicites et les suppressions rm et rmdir ciblant un chemin critique invitent 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.

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. Claude Code enregistre votre acceptation dans les paramètres utilisateur, donc le dialogue n'apparaît qu'une fois. Si vous refusez, Claude Code quitte. En mode non-interactif, aucun dialogue n'est affiché, et une session en arrière-plan démarrée avec --bg est refusée jusqu'à ce que vous ayez accepté le dialogue dans une session interactive.

Sur Linux et macOS, Claude Code refuse de démarrer dans ce mode 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.

Claude Code sur le web n'honore 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.

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.

Mode Écritures de chemins protégés
default, acceptEdits Demandé
plan Autorisé dans les sessions de terminal interactif avec les autorisations de contournement disponibles. Sinon, acheminé vers le classificateur quand le mode auto est disponible pendant la planification, et demandé quand il ne l'est pas
auto Acheminé vers le classificateur
dontAsk Refusé
bypassPermissions Autorisé

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, sauf pour .claude/worktrees où Claude stocke ses propres git worktrees

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

Chemins critiques

Claude Code ne laisse jamais une règle permissions.allow ou un hook PreToolUse qui retourne "allow" approuver une commande rm ou rmdir qui cible un chemin critique, même dans les modes qui sautent d'autres invites. Ce disjoncteur protège contre l'erreur du modèle. Une règle deny correspondante bloque toujours la commande complètement.

Ce qui se passe à la place dépend de votre mode de permission :

Mode Ce que Claude Code fait avec une suppression de chemin critique
default, acceptEdits Vous demande de l'approuver
plan Vous demande de l'approuver. Quand le classificateur examine les commandes pendant la planification et qu'aucune permission de contournement n'est disponible, la traite comme en mode auto
auto Vous demande de l'approuver dans le terminal, avec une limite de temps. Ailleurs, la refuse
dontAsk La refuse
bypassPermissions Vous demande de l'approuver, avec une limite de temps dans le terminal

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.

La gestion auto et bypassPermissions nécessite Claude Code v2.1.281 ou ultérieur. Pour la désactiver, définissez CLAUDE_CODE_DISABLE_DANGEROUS_RM_TIMEOUT=1 dans l'environnement qui lance Claude Code. En mode auto, les suppressions de chemins critiques vont alors au classificateur à la place, et en mode bypassPermissions l'invite n'a pas de limite de temps.

En modes auto et bypassPermissions, l'invite du terminal 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.

En mode auto, partout où Claude Code ne peut pas vous afficher une invite de terminal, il refuse la commande immédiatement, par exemple dans les exécutions non interactives avec -p, dans les sessions Agent SDK, et dans le panneau de chat de l'extension VS Code et l'application Desktop. Le refus dit à Claude de signaler ce qu'il voulait supprimer et de laisser la suppression à vous.

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
  • Les racines des lecteurs Windows et leurs répertoires de niveau supérieur, comme C:\ et C:\Windows
  • 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

Claude Code traite également un glob ou une barre oblique finale directement sous une variable shell, comme rm -rf "$DIR"/*, comme une suppression de chemin critique, car la commande devient une suppression de la racine du système de fichiers quand la variable est vide.

L'invite pour ce cas de variable nomme la commande rm signalée et indique comment la réécrire pour que la vérification passe :

  • Pour 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
  • Pour une variable qui est normalement définie, comme $HOME, 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 dans cette section ne la signale.

Claude Code traite également ces cibles comme des chemins critiques :

  • Une variable shell suivie d'un nom de répertoire de niveau supérieur, comme rm -rf "$TMPDIR/mnt" : quand la variable se développe vide, la commande supprime /mnt. Cela couvre les noms de niveau supérieur courants comme mnt, tmp, usr, et Users.
  • Une variable que la même commande assigne à partir d'une substitution d'impression de répertoire, comme D=$(pwd); rm -rf "$D" ou une assignation à partir de $(git rev-parse --show-toplevel) : la valeur peut nommer votre répertoire de travail ou la racine du référentiel. Une protection "${D:?}" ne clarifie pas cette vérification, car la variable n'est pas vide ; utilisez un chemin littéral à la place.
  • Une cible avec barre oblique inverse uniquement, comme rm -rf "\\" : Git Bash sur Windows lit une barre oblique inverse seule comme la racine du lecteur actuel, donc la vérification s'applique sur chaque plateforme.
  • Uniquement la sortie d'une substitution de commande, comme rm -rf "$(pwd)", quand le rm est récursif : Claude Code ne peut pas vérifier la cible avant que la commande s'exécute, donc l'invite dit à Claude d'exécuter la substitution seule d'abord puis de supprimer les chemins littéraux qu'elle affiche. Pour désactiver cette vérification, définissez CLAUDE_CODE_DISABLE_SUBSTITUTION_RM_PROMPT=1 dans l'environnement qui lance Claude Code.

Quand une substitution de commande finale peut se développer vide, comme dans rm -rf ~/$(cmd), Claude Code vérifie le chemin qui resterait, votre répertoire personnel dans cet exemple.

Masquer la suppression à l'intérieur d'une sous-coquille avec (...), un groupe d'accolades avec { ...; }, une substitution de commande avec $(...) ou des backticks, ou une substitution de processus avec <(...), ne saute pas la vérification. 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.

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