Configurer le mode auto

• Ajouter un point de contrôle humain pour les poussées et les demandes de tirage avec permissions.ask
• 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
• Acheminer toutes les commandes shell via le classificateur avec autoMode.classifyAllShell
• Inspectez votre configuration effective avec les sous-commandes claude auto-mode
• Examinez les refus pour savoir ce qu’il faut ajouter ensuite

​

Limites communes

{
  "permissions": {
    "ask": [
      "Bash(git push *)",
      "Bash(gh pr create *)"
    ]
  }
}

​

Où le classificateur lit la configuration

​

Définir l’infrastructure approuvée

• Emplacements de contexte : décrivent votre organisation, votre pile technologique et votre posture de sécurité afin que le classificateur lise les autres règles dans votre contexte. Contrairement aux deux autres types, les emplacements de contexte n’ont pas de règles propres qui les ciblent. Chacun est par défaut Aucun configuré ou à l’hypothèse conservatrice nommée à côté :
  • Organisation
  • Utilisation principale de Claude Code : par défaut développement logiciel
  • Fournisseur(s) cloud
  • Visibilité du dépôt : un dépôt est supposé privé sauf si son hôte distant et son nom l’indiquent autrement, ou une vérification de visibilité antérieure dans la conversation que le classificateur lit montre qu’il est public. Le classificateur lit vos messages et les commandes que Claude exécute, pas leur sortie, donc la preuve doit être quelque chose qu’il peut lire, comme votre propre message nommant le dépôt comme public ; la sortie d’un gh repo view seul ne l’atteint pas. La vérification des preuves de transcription nécessite Claude Code v2.1.200 ou ultérieur
  • Partage interne / hébergement d’extraits : les services publics de paste et gist sont traités comme en dehors de la limite de confiance jusqu’à ce que vous en nomiez un
  • CLI spécifiques à l’organisation
  • Gestion des secrets
  • Branches par défaut / protégées : main et master sont traités comme protégés jusqu’à ce que vous en nomiez d’autres
  • Cibles de déploiement CI/CD
  • Posture réseau
  • Espaces de noms / environnements de déploiement protégés : revient à l’heuristique des cibles distantes sensibles jusqu’à ce que vous les nomiez
  • Rétention des données / déclassification
• 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. La visibilité d’un dépôt ne s’applique qu’au matériel confidentiel : un dépôt privé est une destination acceptable pour le matériel confidentiel, mais rendre un dépôt privé ne supprime jamais les secrets ou les données personnelles ou confiées qu’il contient, et le classificateur traite le contenu porté, réorienté ou d’abord lu de l’extérieur du dépôt de travail comme n’étant pas le travail propre de ce dépôt. Cette portée nécessite Claude Code v2.1.203 ou ultérieur.
• Emplacements de sensibilité : nomment ce que les règles de protection traitent comme à haut risque. Les emplacements sont Emplacements de données sensibles et audiences, 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.

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

• 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 sensibles et audiences : les buckets, bases de données ou chemins qui contiennent des données personnelles, des données commerciales confidentielles, des identifiants, des données réglementées ou du matériel similaire sensible, et les audiences avec lesquelles les données de chaque emplacement peuvent être partagées, afin que le classificateur protège ces emplacements au lieu de deviner à partir du contenu. Claude Code v2.1.195 à v2.1.197 nomme cette entrée Emplacements de données PII / réglementées et couvre uniquement les emplacements qui contiennent des données personnelles ou réglementées, sans la dimension d’audience
• 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é

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

​

Remplacer les règles de blocage et d’autorisation

• 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

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

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

​

Router tous les commandes shell via le classificateur

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

​

Inspecter les valeurs par défaut et votre configuration effective

claude auto-mode defaults

claude auto-mode config

claude auto-mode critique

​

Examiner les refus

​

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