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.
Le mode auto est disponible pour tous les utilisateurs sur l’API Anthropic. Sur Amazon Bedrock, Google Cloud Vertex AI et Microsoft Foundry, vous devez d’abord définir CLAUDE_CODE_ENABLE_AUTO_MODE. Si Claude Code signale que le mode auto n’est pas disponible pour votre compte, consultez les exigences complètes, qui couvrent également les modèles pris en charge et l’activation par l’administrateur sur les plans Team et Enterprise.
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, soft_deny et hard_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 liste d’environnement par défaut approuve le dépôt de travail et ses remotes configurées. Pour ajouter vos propres entrées aux côtés de cette valeur par défaut, incluez la chaîne littérale "$defaults" dans le tableau. Les entrées par défaut sont insérées à cette position, donc vos entrées personnalisées peuvent aller avant ou après. 
{
  "autoMode": {
    "environment": [
      "$defaults",
      "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": [
      "$defaults",
      "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

Trois champs supplémentaires vous permettent de remplacer les listes de règles intégrées du classificateur : autoMode.hard_deny pour les limites de sécurité inconditionnelles, autoMode.soft_deny pour les actions destructrices que l’intention de l’utilisateur peut lever, et autoMode.allow pour les exceptions. Chacun est un tableau de descriptions en prose, lu comme des règles en langage naturel. Pour les blocages durs basés sur des motifs d’outils qui s’exécutent avant le classificateur, utilisez permissions.deny. À l’intérieur du classificateur, la précédence fonctionne en quatre niveaux :
  • Les règles hard_deny bloquent inconditionnellement. L’intention de l’utilisateur et les exceptions allow ne s’appliquent pas.
  • Les règles soft_deny bloquent ensuite. L’intention de l’utilisateur et les exceptions allow peuvent remplacer celles-ci.
  • Les règles allow remplacent ensuite les règles soft_deny correspondantes comme exceptions.
  • L’intention explicite de l’utilisateur remplace les blocages souples restants : 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. Pour assouplir, 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 destructeurs spécifiques à votre environnement que les valeurs par défaut manquent, ou à hard_deny pour les limites de sécurité qui ne doivent jamais être franchies. Pour conserver les règles intégrées tout en ajoutant les vôtres, incluez la chaîne littérale "$defaults" dans le tableau. Les règles par défaut sont insérées à cette position, donc vos règles personnalisées peuvent aller avant ou après elles, et vous continuez à hériter des mises à jour à mesure que la liste intégrée change entre les versions. 
{
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.example.com/acme-corp and all repos under it"
    ],
    "allow": [
      "$defaults",
      "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": [
      "$defaults",
      "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"
    ],
    "hard_deny": [
      "$defaults",
      "Never send repository contents to third-party code-review APIs"
    ]
  }
}
La définition de l’un de environment, allow, soft_deny ou hard_deny sans "$defaults" remplace la liste par défaut entière pour cette section. Un tableau soft_deny sans "$defaults" rejette chaque règle de blocage intégrée, y compris la poussée forcée, curl | bash et les déploiements en production. Un tableau hard_deny sans "$defaults" rejette les règles intégrées d’exfiltration de données et de contournement des vérifications de sécurité.
Chaque section est évaluée indépendamment, donc la définition de environment seule laisse les listes allow, soft_deny et hard_deny par défaut intactes. Omettez "$defaults" uniquement quand vous avez l’intention de prendre la responsabilité complète de la liste. Pour ce faire 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.

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

Trois sous-commandes CLI vous aident à inspecter et valider votre configuration. Imprimez les règles environment, allow, soft_deny et hard_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, soft_deny et hard_deny personnalisées : 
claude auto-mode critique
Exécutez claude auto-mode config après avoir enregistré vos paramètres pour confirmer que les règles effectives sont ce que vous attendez, avec "$defaults" développé en place. 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. Si vous devez supprimer ou réécrire une règle intégrée plutôt que d’en ajouter une à côté, enregistrez la sortie de claude auto-mode defaults dans un fichier, modifiez les listes, et collez le résultat dans votre fichier de paramètres à la place de "$defaults".

​
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