SpyBara
Go Premium

auto-mode-config.md 2026-06-29 23:02 UTC to 2026-06-30 23:02 UTC

61 added, 7 removed.

2026
Tue 30 23:02 Mon 29 23:02 Sat 27 01:01 Fri 26 23:00 Thu 25 23:58 Wed 24 22:02 Tue 23 22:00 Mon 22 23:59 Fri 19 22:58 Thu 18 22:00 Wed 17 17:02 Tue 16 21:57 Mon 15 23:02 Sat 13 21:59 Fri 12 22:00 Thu 11 23:01 Wed 10 23:57 Tue 9 06:34 Mon 8 06:52 Sat 6 06:24 Fri 5 06:45 Thu 4 06:52 Wed 3 06:53 Tue 2 06:51

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 :

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ée Fichier Utiliser pour
Un développeur ~/.claude/settings.json Infrastructure approuvée personnelle
Un projet, un développeur .claude/settings.local.json Buckets ou services approuvés par projet
À l'échelle de l'organisation Paramètres gérés Infrastructure approuvée distribuée à tous les développeurs
Drapeau --settings ou Agent SDK JSON en ligne Remplacements 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 logiciel à 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.

À partir de Claude Code v2.1.195, claude auto-mode defaults imprime deux types d'entrées d'environnement.

  • Emplacements de confiance : nomment ce que le classificateur traite comme à l'intérieur de votre limite. Les emplacements sont Dépôt approuvé, Contrôle de source, Domaines internes approuvés, Buckets cloud approuvés, Services internes clés et Registre de packages interne. Les entrées de dépôt et de contrôle de source sont par défaut le dépôt de travail et ses remotes configurées. Tous les autres emplacements de confiance sont par défaut Aucun configuré, donc rien d'autre n'est approuvé jusqu'à ce que vous l'ajoutiez.
  • Emplacements de sensibilité : nomment ce que les règles de protection traitent comme à haut risque. Les emplacements sont Emplacements de données PII / réglementées, Cibles distantes sensibles et Portées IaC protégées. Chacun est par défaut une heuristique large, comme traiter tout hôte ou espace de noms dont le nom porte prod ou production comme une cible distante sensible, donc les règles de protection sont actives avant que vous configuriez quoi que ce soit. Nommer des cibles concrètes dans un emplacement de sensibilité fait que ces règles s'appliquent aux cibles nommées au lieu de l'heuristique.

Les versions antérieures à v2.1.195 impriment uniquement les cinq premiers emplacements de confiance.

Pour ajouter vos propres entrées aux côtés des valeurs 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 elles.

L'exemple suivant conserve les entrées par défaut et ajoute les dépôts, buckets, domaines et services d'une organisation.

{
  "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
  • Registre de packages interne : le registre npm, PyPI ou autre privé par lequel les installations doivent être acheminées, donc les installations qui le contournent pour un registre public sont bloquées
  • Emplacements de données PII / réglementées : les buckets, bases de données ou chemins qui contiennent des données personnelles ou réglementées, afin que le classificateur protège ces emplacements au lieu de deviner à partir du contenu
  • Cibles distantes sensibles : les espaces de noms, hôtes ou conteneurs qui comptent comme production, donc les shells distants et les redirections de ports vers eux ont besoin de votre approbation explicite
  • Portées IaC protégées : les ressources d'infrastructure dont l'application ou la destruction doivent toujours vous demander de nommer le changement
  • 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é

Les entrées Registre de packages interne, Emplacements de données PII / réglementées, Cibles distantes sensibles et Portées IaC protégées nécessitent Claude Code v2.1.195 ou ultérieur. Les versions antérieures les lisent toujours comme du contexte simple mais n'ont pas les règles intégrées qui les ciblent.

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 : limites de sécurité inconditionnelles
  • autoMode.soft_deny : actions destructrices que l'intention de l'utilisateur peut lever
  • autoMode.allow : exceptions aux règles de blocage logiciel

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.

L'exemple suivant conserve les valeurs par défaut dans les quatre listes et ajoute des règles spécifiques à l'organisation à chacune.

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

Router tous les commandes shell via le classificateur

Par défaut, les règles d'autorisation Bash et PowerShell étroites comme Bash(npm test) sont reportées en mode auto et résolues avant l'exécution du classificateur. Le mode auto suspend uniquement les règles larges qui accordent l'exécution de code arbitraire, comme Bash(*) ou les interpréteurs avec caractères génériques. Cela signifie qu'une règle étroite peut toujours laisser passer un argument destructeur sans que le classificateur le voie, par exemple un chemin de script ou un drapeau que le préfixe de la règle n'a pas anticipé.

Définissez autoMode.classifyAllShell à true pour suspendre chaque règle d'autorisation Bash et PowerShell pendant que le mode auto est actif, afin que le classificateur évalue chaque commande shell indépendamment de votre liste d'autorisation.

{
  "autoMode": {
    "classifyAllShell": true
  }
}

Cela échange la latence pour la couverture : une commande qu'une règle d'autorisation aurait approuvée instantanément attend maintenant une décision du classificateur, et chaque commande shell compte comme un appel du classificateur.

Le paramètre s'applique uniquement pendant que le mode auto est actif, et vos règles d'autorisation se comportent normalement dans les autres modes de permission.

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.

Dans Claude Code v2.1.193 et ultérieur, la raison du classificateur pour chaque refus apparaît aux côtés de l'appel d'outil bloqué dans la transcription, dans la notification de refus et sous chaque entrée de l'onglet Récemment refusé. Utilisez la raison pour décider si la correction est une entrée environment, une exception allow ou un réessai avec intention explicite dans votre prochain message.

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