Configurer le mode auto

• Ajouter un point de contrôle humain pour les poussées et les demandes de tirage avec permissions.ask
• Définir l’infrastructure approuvée avec autoMode.environment
• Générer des entrées d’environnement avec /auto-mode-setup
• Examinez les refus pour savoir ce qu’il faut ajouter ensuite

​

Limites communes

​

Ajouter un point de contrôle humain

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

​

Où le classificateur lit la configuration

​

Définir l’infrastructure de confiance

• Emplacements de contexte : décrivez votre organisation, votre pile technologique et votre posture de sécurité afin que le classificateur lise les autres règles dans votre contexte. Chacun par défaut à None configured 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 indiquent le contraire, ou si le classificateur lit une vérification de visibilité plus tôt dans la conversation montrant qu’il est public. Dans les demandes du classificateur envoyées par Claude Code lui-même, le classificateur lit vos messages et les commandes que Claude exécute, pas leur sortie. La preuve doit être quelque chose que le classificateur 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.
  • Partage interne / hébergement d’extraits : les services publics de pâte et de gist sont traités comme en dehors de la limite de confiance jusqu’à ce que vous en nommez un
  • CLIs spécifiques à l’organisation
  • Gestion des secrets
  • Cibles de déploiement CI/CD
  • Posture réseau
  • Confinement d’hôte : par défaut une machine de développeur ordinaire ou un exécuteur CI avec internet ouvert. Si Claude Code s’exécute dans un conteneur, une VM ou un pod avec une liste d’autorisation de sortie ou des voisins qu’il ne doit pas toucher, nommez les hôtes autorisés, si le point de terminaison des métadonnées cloud doit être accessible, et quel projet cloud, cluster ou registre la tâche utilise et sous quelle identité. Jusqu’à ce que cette entrée nomme cette identité, le classificateur bloque les demandes pour les propres identifiants de l’hôte. Nécessite Claude Code v2.1.257 ou ultérieur
  • Espaces de déploiement protégés / environnements : revient à l’heuristique des cibles distantes sensibles jusqu’à ce que vous les nommez
  • Rétention des données / déclassification
• Emplacements de confiance : nommez ce que le classificateur traite comme à l’intérieur de votre limite. Les emplacements sont Dépôt de confiance, Contrôle de source, Domaines internes de confiance, Buckets cloud de confiance, Services internes clés et Registre de paquets interne. Les entrées de dépôt et de contrôle de source par défaut au dépôt de travail et ses télécommandes configurées. Tous les autres emplacements de confiance par défaut à None configured, donc rien d’autre n’est de confiance jusqu’à ce que vous l’ajoutiez. La visibilité d’un dépôt ne limite que le matériel confidentiel : un dépôt privé est une destination acceptable pour le matériel confidentiel, mais rendre un dépôt privé n’autorise jamais les secrets ou les données personnelles ou confiées à y entrer, 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 propre travail de ce dépôt.
• Emplacements de sensibilité : nommez 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 Étendues IaC protégées. Chacun par défaut à une large heuristique, 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 appliquer ces règles 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 de confiance : noms ou préfixes de buckets que Claude devrait pouvoir lire et écrire
• Domaines internes de confiance : 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 paquets internes, outils d’incident
• Registre de paquets interne : le registre npm, PyPI ou autre privé par lequel les installations doivent être acheminées, afin que les installations qui le contournent pour un registre public soient 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 dans chaque emplacement peuvent être partagé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, afin que les shells distants et les transferts de port vers eux aient besoin de votre approbation explicite
• Étendues IaC protégées : les ressources d’infrastructure dont l’application ou la destruction doivent toujours vous obliger à nommer le changement
• Contexte supplémentaire : contraintes de secteur réglementé, 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}"
    ]
  }
}

​

Générer des entrées d’environnement avec /auto-mode-setup

​

Ce que /auto-mode-setup lit

• Le CLAUDE.md, README.md, les fichiers de configuration et les télécommandes git de ce projet
• Vos paramètres autoMode et permissions.allow
• Les hôtes, les buckets et les noms de commandes à partir des commandes que Claude a exécutées dans vos sessions récentes dans ce projet, jamais vos messages

• Le premier mot de chaque commande dans votre historique shell
• Les hôtes distants et les noms des référentiels sous votre répertoire personnel

​

Examiner et enregistrer le brouillon

• Claude Code écrit la liste environment sans "$defaults", car le brouillon énumère les entrées intégrées qu’il a laissées inchangées
• Claude Code inclut "$defaults" dans chacune des listes allow, soft_deny et hard_deny auxquelles le brouillon ajoute des entrées, sauf si vous avez déjà écrit une liste allow sans elle, de sorte que les règles intégrées que vous n’avez pas remplacées restent en vigueur
• Après l’enregistrement, Claude Code propose de supprimer les règles permissions.allow dans ~/.claude/settings.json que le mode auto ignore, telles que Bash(*), ou qui approuvent automatiquement les commandes destructrices

​

Désactiver /auto-mode-setup

{
  "skillOverrides": {
    "auto-mode-setup": "off"
  }
}

​

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

​

Modifier les règles depuis /permissions

​

Acheminer toutes les commandes shell via le classificateur

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

​

Inspectez les paramètres par défaut et votre configuration effective

claude auto-mode defaults

claude auto-mode config

{
  "allow": [
    ...
    "Test Artifacts: Hardcoded test API keys, placeholder credentials in examples, or hardcoding test cases. Placeholder means authored as a placeholder — a file or value copied from a real secret or sensitive path is never a test artifact (see Sensitive-Source Provenance).",
    ...
  ],
  "soft_deny": [
    "Git Destructive [named+specifics — **must name:** the destructive operation and its target]: Force pushing (`git push --force`), deleting remote branches, tags, or releases, or rewriting remote history. Also `git commit --amend` when the commit being rewritten is not the agent's own unpushed work: either no prior `git commit` is visible (HEAD pre-dates the session), or a `git push` of the current branch is visible after the most recent commit (it has been pushed). Clears when the user asked to amend/reword/fixup, or when it is a message-only reword (`--amend -m …`, nothing newly staged) of a commit the agent visibly created this session.",
    ...
  ],
  "hard_deny": [...],
  "environment": [
    ...
    "**Trusted repo**: The git repository the agent started in (its working directory) and its configured remote(s). When the repo's public/private visibility is given — by the Repository visibility entry or the user's own message — use it to scope what is OK to commit or push there: confidential material is fine in a private repo; in a public one, only that repo's own work is — and content ported, repointed, or first read from outside this session's repo is not its own work, whoever directed the port. Visibility scopes confidential material only: secrets and sensitive data (personal & entrusted) are never cleared into any repo by its visibility (see Definitions).",
    ...
  ]
}

claude auto-mode critique

claude auto-mode reset

​

Examiner les refus

​

Corriger un refus avec une règle d’autorisation, une entrée d’environnement ou un réessai

• Une destination dont Claude a besoin tout au long de la tâche, telle qu’un registre de paquets, un domaine interne ou un hôte de référentiel : ajoutez-la à autoMode.environment.
• Une commande que vous souhaitez exécuter sans révision à partir de maintenant : ajoutez une règle allow.
• Une action ponctuelle que vous aviez l’intention de faire : indiquez cette intention dans votre prochain message et laissez Claude réessayer.

​

Corriger les refus répétés

​

Voir aussi

• Modes de permission : qu’est-ce que le mode auto, ce qu’il bloque par défaut et quelles sessions le démarrent
• Paramètres gérés : déployer 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
• Tous les paramètres : chaque clé de paramètres, y compris autoMode