Configurer le mode auto

Indiquez au classificateur du mode auto quels dépôts, buckets et domaines votre organisation approuve. Définissez le contexte d'environnement, remplacez les règles de blocage et d'autorisation par défaut, et inspectez votre configuration effective avec les sous-commandes CLI du mode auto.

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. Les règles de refus et de demande explicite sont évaluées avant le classificateur et bloquent ou invitent toujours. 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 :

• Choisir où définir les règles dans CLAUDE.md, les paramètres utilisateur et les paramètres gérés
• Définir l'infrastructure approuvée avec autoMode.environment
• Remplacer les règles de blocage et d'autorisation quand les valeurs par défaut ne correspondent pas à votre pipeline
• Inspecter votre configuration effective avec les sous-commandes claude auto-mode
• Examiner les refus pour savoir ce qu'il faut ajouter ensuite

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 :

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.

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"
    ]
  }
}

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