Passer au contenu principal
Le mode auto permet à Claude Code de s’exécuter sans invites de permission en acheminant chaque appel d’outil via un classificateur qui bloque tout ce qui est irréversible, destructeur ou destiné en dehors de votre environnement. Utilisez le bloc de paramètres autoMode pour indiquer à ce classificateur quels dépôts, buckets et domaines votre organisation approuve, afin qu’il cesse de bloquer les opérations internes courantes. Par défaut, le classificateur n’approuve que le répertoire de travail et les remotes configurées du dépôt actuel. Les actions comme pousser vers l’organisation de contrôle de source de votre entreprise ou écrire dans un bucket cloud d’équipe sont bloquées jusqu’à ce que vous les ajoutiez à autoMode.environment. Pour savoir comment activer le mode auto et ce qu’il bloque par défaut, consultez Modes de permission. Cette page est la référence de configuration. Cette page couvre comment :

​
Où le classificateur lit la configuration

Le classificateur lit le même contenu CLAUDE.md que Claude lui-même charge, donc une instruction comme « ne jamais forcer la poussée » dans le CLAUDE.md de votre projet guide à la fois Claude et le classificateur en même temps. Commencez par là pour les conventions de projet et les règles de comportement. Pour les règles qui s’appliquent à plusieurs projets, comme l’infrastructure approuvée ou les règles de refus à l’échelle de l’organisation, utilisez le bloc de paramètres autoMode. Le classificateur lit autoMode à partir des portées suivantes :
PortéeFichierUtiliser pour
Un développeur~/.claude/settings.jsonInfrastructure approuvée personnelle
Un projet, un développeur.claude/settings.local.jsonBuckets ou services approuvés par projet, gitignorés
À l’échelle de l’organisationParamètres gérésInfrastructure approuvée distribuée à tous les développeurs
Drapeau --settings ou Agent SDKJSON en ligneRemplacements par invocation pour l’automatisation
Le classificateur ne lit pas autoMode à partir des paramètres de projet partagés dans .claude/settings.json, donc un dépôt enregistré ne peut pas injecter ses propres règles d’autorisation. Les entrées de chaque portée sont combinées. Un développeur peut étendre environment, allow et soft_deny avec des entrées personnelles mais ne peut pas supprimer les entrées que les paramètres gérés fournissent. Parce que les règles d’autorisation agissent comme des exceptions aux règles de blocage à l’intérieur du classificateur, une entrée allow ajoutée par un développeur peut remplacer une entrée soft_deny d’organisation : la combinaison est additive, pas une limite de politique stricte.
Le classificateur est une deuxième porte qui s’exécute après le système de permissions. Pour les actions qui ne doivent jamais s’exécuter indépendamment de l’intention de l’utilisateur ou de la configuration du classificateur, utilisez permissions.deny dans les paramètres gérés, qui bloque l’action avant que le classificateur ne soit consulté et ne peut pas être remplacée.

​
Définir l’infrastructure approuvée

Pour la plupart des organisations, autoMode.environment est le seul champ que vous devez définir. Il indique au classificateur quels dépôts, buckets et domaines sont approuvés : le classificateur l’utilise pour décider ce que signifie « externe », donc toute destination non listée est une cible d’exfiltration potentielle. La définition de environment remplace la liste d’environnement par défaut, qui inclut l’entrée qui approuve le dépôt de travail et ses remotes. Exécutez claude auto-mode defaults pour imprimer les valeurs par défaut, puis incluez-les aux côtés de vos propres entrées afin d’étendre la liste plutôt que de la réduire. 
{
  "autoMode": {
    "environment": [
      "Source control: github.example.com/acme-corp and all repos under it",
      "Trusted cloud buckets: s3://acme-build-artifacts, gs://acme-ml-datasets",
      "Trusted internal domains: *.corp.example.com, api.internal.example.com",
      "Key internal services: Jenkins at ci.example.com, Artifactory at artifacts.example.com"
    ]
  }
}
Les entrées sont en prose, pas en regex ou en motifs d’outil. Le classificateur les lit comme des règles en langage naturel. Écrivez-les comme vous décririez votre infrastructure à un nouvel ingénieur. Une section d’environnement approfondie couvre :
  • Organisation : le nom de votre entreprise et ce pour quoi Claude Code est principalement utilisé, comme le développement logiciel, l’automatisation de l’infrastructure ou l’ingénierie des données
  • Contrôle de source : chaque organisation GitHub, GitLab ou Bitbucket vers laquelle vos développeurs poussent
  • Fournisseurs cloud et buckets approuvés : noms de buckets ou préfixes que Claude devrait pouvoir lire et écrire
  • Domaines internes approuvés : noms d’hôtes pour les API, tableaux de bord et services à l’intérieur de votre réseau, comme *.internal.example.com
  • Services internes clés : CI, registres d’artefacts, index de packages internes, outils d’incident
  • Contexte supplémentaire : contraintes d’industrie réglementée, infrastructure multi-locataire ou exigences de conformité qui affectent ce que le classificateur devrait traiter comme risqué
Un modèle de démarrage utile : remplissez les champs entre crochets et supprimez les lignes qui ne s’appliquent pas. 
{
  "autoMode": {
    "environment": [
      "Organization: {COMPANY_NAME}. Primary use: {PRIMARY_USE_CASE, e.g. software development, infrastructure automation}",
      "Source control: {SOURCE_CONTROL, e.g. GitHub org github.example.com/acme-corp}",
      "Cloud provider(s): {CLOUD_PROVIDERS, e.g. AWS, GCP, Azure}",
      "Trusted cloud buckets: {TRUSTED_BUCKETS, e.g. s3://acme-builds, gs://acme-datasets}",
      "Trusted internal domains: {TRUSTED_DOMAINS, e.g. *.internal.example.com, api.example.com}",
      "Key internal services: {SERVICES, e.g. Jenkins at ci.example.com, Artifactory at artifacts.example.com}",
      "Additional context: {EXTRA, e.g. regulated industry, multi-tenant infrastructure, compliance requirements}"
    ]
  }
}
Plus le contexte que vous fournissez est spécifique, mieux le classificateur peut distinguer les opérations internes courantes des tentatives d’exfiltration. Vous n’avez pas besoin de tout remplir à la fois. Un déploiement raisonnable : commencez par les valeurs par défaut et ajoutez votre organisation de contrôle de source et vos services internes clés, ce qui résout les faux positifs les plus courants comme pousser vers vos propres dépôts. Ajoutez ensuite les domaines approuvés et les buckets cloud. Remplissez le reste à mesure que les blocages surviennent.

​
Remplacer les règles de blocage et d’autorisation

Deux champs supplémentaires vous permettent de remplacer les listes de règles intégrées du classificateur : autoMode.soft_deny contrôle ce qui est bloqué, et autoMode.allow contrôle quelles exceptions s’appliquent. Chacun est un tableau de descriptions en prose, lu comme des règles en langage naturel. Il n’y a pas de champ autoMode.deny ; pour bloquer dur une action indépendamment de l’intention, utilisez permissions.deny, qui s’exécute avant le classificateur. À l’intérieur du classificateur, la précédence fonctionne en trois niveaux :
  • Les règles soft_deny bloquent d’abord
  • Les règles allow remplacent ensuite les blocages correspondants comme exceptions
  • L’intention explicite de l’utilisateur remplace les deux : si le message de l’utilisateur décrit directement et spécifiquement l’action exacte que Claude est sur le point de prendre, le classificateur l’autorise même quand une règle soft_deny correspond
Les demandes générales ne comptent pas comme une intention explicite. Demander à Claude de « nettoyer le dépôt » n’autorise pas la poussée forcée, mais demander à Claude de « forcer la poussée de cette branche » le fait.
La définition de l’un de environment, allow ou soft_deny remplace la liste par défaut entière pour cette section. Si vous définissez soft_deny avec une seule entrée, chaque règle de blocage intégrée est rejetée : poussée forcée, exfiltration de données, curl | bash, déploiements en production et toutes les autres règles de blocage par défaut deviennent autorisées. Pour personnaliser en toute sécurité, exécutez claude auto-mode defaults pour imprimer les règles intégrées, copiez-les dans votre fichier de paramètres, puis examinez chaque règle par rapport à votre propre pipeline et tolérance au risque. Supprimez uniquement les règles pour les risques que votre infrastructure atténue déjà.
Pour assouplir : supprimez les règles de soft_deny quand les valeurs par défaut bloquent quelque chose que votre pipeline garde déjà avec l’examen des PR, CI ou les environnements de staging, ou ajoutez à allow quand le classificateur signale à plusieurs reprises un motif courant que les exceptions par défaut ne couvrent pas. Pour renforcer : ajoutez à soft_deny pour les risques spécifiques à votre environnement que les valeurs par défaut manquent, ou supprimez de allow pour maintenir une exception par défaut aux règles de blocage. Dans tous les cas, exécutez claude auto-mode defaults pour obtenir les listes par défaut complètes, puis copiez et modifiez : ne commencez jamais par une liste vide. 
{
  "autoMode": {
    "environment": [
      "Source control: github.example.com/acme-corp and all repos under it"
    ],
    "allow": [
      "Deploying to the staging namespace is allowed: staging is isolated from production and resets nightly",
      "Writing to s3://acme-scratch/ is allowed: ephemeral bucket with a 7-day lifecycle policy"
    ],
    "soft_deny": [
      "Never run database migrations outside the migrations CLI, even against dev databases",
      "Never modify files under infra/terraform/prod/: production infrastructure changes go through the review workflow",
      "...copy full default soft_deny list here first, then add your rules..."
    ]
  }
}
Chaque section remplace uniquement sa propre valeur par défaut, donc la définition de environment seule laisse les listes allow et soft_deny par défaut intactes.

​
Inspecter les valeurs par défaut et votre configuration effective

Parce que la définition de l’un des trois tableaux remplace ses valeurs par défaut, commencez toute personnalisation en copiant les listes par défaut complètes. Trois sous-commandes CLI vous aident à inspecter et valider. Imprimez les règles environment, allow et soft_deny intégrées en JSON : 
claude auto-mode defaults
Imprimez ce que le classificateur utilise réellement en JSON, avec vos paramètres appliqués où définis et les valeurs par défaut sinon : 
claude auto-mode config
Obtenez des commentaires IA sur vos règles allow et soft_deny personnalisées : 
claude auto-mode critique
Enregistrez la sortie de claude auto-mode defaults dans un fichier, modifiez les listes pour qu’elles correspondent à votre politique, et collez le résultat dans votre fichier de paramètres. Après l’enregistrement, exécutez claude auto-mode config pour confirmer que les règles effectives sont ce que vous attendez. Si vous avez écrit des règles personnalisées, claude auto-mode critique les examine et signale les entrées qui sont ambiguës, redondantes ou susceptibles de causer des faux positifs.

​
Examiner les refus

Quand le mode auto refuse un appel d’outil, le refus est enregistré dans /permissions sous l’onglet Récemment refusé. Appuyez sur r sur une action refusée pour la marquer pour réessai : quand vous quittez la boîte de dialogue, Claude Code envoie un message indiquant au modèle qu’il peut réessayer cet appel d’outil et reprend la conversation. Les refus répétés pour la même destination signifient généralement que le classificateur manque de contexte. Ajoutez cette destination à autoMode.environment, puis exécutez claude auto-mode config pour confirmer que cela a pris effet. Pour réagir aux refus par programmation, utilisez le hook PermissionDenied.

​
Voir aussi

  • Modes de permission : ce qu’est le mode auto, ce qu’il bloque par défaut et comment l’activer
  • Paramètres gérés : déployez la configuration autoMode dans votre organisation
  • Permissions : règles d’autorisation, de demande et de refus qui s’appliquent avant l’exécution du classificateur
  • Paramètres : la référence complète des paramètres, y compris la clé autoMode