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 routinières en acheminant les appels d'outils 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 routinières.

[!NOTE]

Cette page est la référence de configuration. L'activation et la désactivation du mode auto sont couvertes sur la page Modes de permission :

• Basculer vers le mode auto en cours de session, ou en sortir : voir Basculer les modes de permission
• Démarrer une session en mode auto : voir Démarrer dans un mode de permission différent

Le mode auto est disponible pour tous les utilisateurs sur chaque fournisseur, y compris l'API Anthropic, Claude Platform on AWS, Amazon Bedrock, la plateforme Agent de Google Cloud, Microsoft Foundry, et les sessions de passerelle d'applications Claude connectées. 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 le contrôle au niveau de l'organisation sur les plans Team et Enterprise.

Par défaut, le classificateur approuve uniquement le répertoire de travail et les télécommandes 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.

Cette page couvre comment :

• 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

Le mode auto permet les poussées vers n'importe quelle branche du référentiel sur lequel vous travaillez, y compris la branche par défaut, et la création de demandes de tirage par défaut. Une branche non-par défaut dont le nom la marque comme cible de déploiement ou de publication, comme production, release, ou gh-pages, n'est pas couverte par ce défaut : le classificateur juge une poussée là-bas selon ses propres termes, y compris comme un déploiement en production. Le contenu de la poussée est également toujours vérifié, donc une poussée forcée, un secret entrant dans le commit, ou une modification qui enverrait des secrets en dehors du référentiel lorsque CI ou un pipeline de déploiement l'exécute reste bloquée.

Si vous souhaitez un point de contrôle humain avant les commandes de poussée et de demande de tirage de Claude, ajoutez des règles de permission : les recettes ci-dessous maintiennent le mode auto activé pour tout le reste.

Ajouter un point de contrôle humain

Le mécanisme le plus direct est permissions.ask. Les règles ask délimitées par le contenu comme celles ci-dessous sont évaluées avant le classificateur et forcent toujours une invite de permission, même en mode auto, car une règle ask explicite est votre intention déclarée d'être invité pour cette action. Ajoutez les règles dans vos paramètres :

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

Ces règles correspondent aux commandes qui commencent par git push ou gh pr create. Une poussée que Claude écrit d'une autre manière, comme git -C <dir> push ou git -c <key>=<value> push, ne correspond pas à la règle, donc elle n'est pas contrôlée. Pour un point de contrôle qui inspecte le texte complet de la commande, ajoutez un hook PreToolUse.

Choisissez le mécanisme qui correspond à la fermeté requise de la limite :

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 un push » dans le CLAUDE.md de votre projet oriente à la fois Claude et le classificateur. 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 de confiance 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 dans .claude/settings.json ou .claude/settings.local.json. Les deux fichiers se trouvent dans le répertoire du dépôt, donc un dépôt archivé ou une étape de construction pourrait autrement injecter ses propres règles d'autorisation. Déplacez tout bloc autoMode dans .claude/settings.local.json vers ~/.claude/settings.json.

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.

[!NOTE]

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 de confiance

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 de confiance : le classificateur l'utilise pour décider ce que signifie « externe », donc toute destination non listée est une cible d'exfiltration potentielle.

claude auto-mode defaults affiche trois types d'entrée d'environnement.

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

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

Après avoir enregistré vos paramètres, exécutez claude auto-mode config pour confirmer que les règles effectives incluent vos entrées.

Les entrées sont en prose, pas en regex ou en motifs d'outils. 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 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é

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

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 de confiance et les buckets cloud. Remplissez le reste à mesure que les blocages surviennent.

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

Exécutez /auto-mode-setup pour que Claude Code rédige des entrées autoMode.environment, et parfois aussi des entrées de règles, à partir de votre projet et de vos sessions récentes dans celui-ci. Si vous acceptez le brouillon, Claude Code l'écrit dans ~/.claude/settings.json.

[!NOTE]

/auto-mode-setup est disponible avec les forfaits Pro, Max, Ultra, Team et Enterprise, ainsi qu'avec une clé API Claude Console. Avec un forfait Pro, Max, Ultra ou Team, vous avez besoin de la v2.1.228 ou ultérieure, ou de la v2.1.233 ou ultérieure sous Windows natif. Avec un forfait Enterprise ou une clé API Claude Console, vous avez besoin de la v2.1.283 ou ultérieure. Si la commande est absente de votre session, consultez /auto-mode-setup renvoie « Unknown command ».

Ce que lit /auto-mode-setup

Si ~/.claude/settings.json contient déjà des entrées autoMode, Claude Code commence par vous demander s'il doit compléter votre liste d'environnement ou la remplacer, et conserve dans les deux cas les règles que vous avez écrites. Claude Code vous demande ensuite comment vous utilisez ce projet et propose deux analyses facultatives avant d'analyser quoi que ce soit. Lors de l'analyse, Claude Code lit toujours ces sources :

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

Les deux analyses facultatives ajoutent chacune une source :

• Le premier mot de chaque commande de votre historique shell
• Les hôtes distants et les noms des dépôts situés dans votre répertoire personnel

Examiner et enregistrer le brouillon

Claude Code effectue l'analyse en arrière-plan, puis vous montre le brouillon. Vous l'acceptez ou le rejetez dans son ensemble ; modifiez donc ~/.claude/settings.json par la suite pour ajuster des entrées individuelles. Lorsque vous acceptez, Claude Code écrit le brouillon et le concilie avec vos paramètres existants :

• Si vous avez choisi de compléter la liste environment de ~/.claude/settings.json, vous conservez toute entrée "$defaults" qu'elle contient. Si vous avez choisi de remplacer cette liste, vous perdez cette entrée ; rajoutez donc "$defaults" si vous souhaitez conserver les entrées par défaut
• 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 lui, afin 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 de ~/.claude/settings.json que le mode auto ignore, comme Bash(*), ou qui approuvent automatiquement des commandes destructrices

Exécutez ensuite claude auto-mode config pour voir le résultat effectif.

Désactiver /auto-mode-setup

Une fois que le mode auto a bloqué plusieurs actions et que vous n'avez toujours aucune entrée autoMode.environment, Claude Code affiche à la fin d'un tour une boîte de dialogue intitulée « Teach auto mode about your environment? » et propose d'exécuter /auto-mode-setup pour vous. Pour ne plus recevoir cette proposition tout en conservant la commande, sélectionnez Don't show again dans cette boîte de dialogue.

Pour désactiver à la fois la commande et la proposition, ajoutez cette entrée skillOverrides à ~/.claude/settings.json :

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

/auto-mode-setup est une commande intégrée et non un skill fourni ; cette entrée skillOverrides s'y applique donc quand même, mais disableBundledSkills ne la désactive pas.

/auto-mode-setup renvoie « Unknown command »

Si la saisie de /auto-mode-setup dans le prompt de Claude Code affiche Unknown command: /auto-mode-setup, vérifiez les causes suivantes :

• Première session après une installation ou une mise à jour : démarrez une nouvelle session. Si la commande est toujours absente, consultez les configurations dans lesquelles les sessions suivantes démarrent également sans elle.
• Version obsolète : exécutez claude --version dans votre shell. Si la version est inférieure au minimum requis pour votre forfait, mettez à jour Claude Code.
• Télémétrie désactivée, fournisseur tiers ou passerelle d'applications Claude : avant la v2.1.304, la commande n'est pas disponible dans les sessions où la récupération des feature flags est désactivée. Si votre session en fait partie, mettez à jour Claude Code vers la v2.1.304 ou ultérieure.

Dans une session cloud, la commande affiche plutôt /auto-mode-setup isn't available in this environment. Exécutez-la dans une session interactive de votre terminal.

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 : actions à bloquer même lorsque l'utilisateur les demande
• 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 actions à bloquer même lorsque l'utilisateur les demande.

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",
      "Running terraform apply in infra/terraform/prod/ needs an explicit request: production infrastructure changes go through the review workflow"
    ],
    "hard_deny": [
      "$defaults",
      "Never send repository contents to third-party code-review APIs"
    ]
  }
}

[!CAUTION]

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. Si vous définissez un tableau sans "$defaults", vous rejetez les règles intégrées pour cette section :

• soft_deny : chaque règle de blocage intégrée, y compris la poussée forcée, curl | bash, les déploiements en production et le contournement du mode auto
• hard_deny : la règle intégrée d'exfiltration de données

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.

Modifier les règles depuis /permissions

Pour afficher et modifier les règles du classificateur et les entrées environment sans ouvrir un fichier de paramètres, exécutez /permissions et sélectionnez l'onglet Auto mode. L'onglet nécessite Claude Code v2.1.246 ou une version ultérieure, et il n'apparaît que lorsque le mode auto est disponible pour votre session.

Claude Code affiche les entrées des paramètres gérés ou l'indicateur --settings en lecture seule, et enregistre chaque modification que vous apportez à l'onglet dans ~/.claude/settings.json.

Acheminer toutes les commandes shell via le classificateur

Par défaut, les règles étroites Bash et PowerShell telles que Bash(npm test) restent en vigueur en mode auto. Claude Code les résout avant que le classificateur ne s'exécute, sauf si la commande porte des domaines autorisés par commande. Claude Code suspend uniquement les règles larges qui accordent l'exécution de code arbitraire, telles que Bash(*) ou les interpréteurs avec caractères génériques, ainsi que chaque règle qui nomme Monitor, car les commandes Monitor s'exécutent via le shell. Cela signifie qu'une règle étroite peut toujours laisser passer un argument destructeur sans que le classificateur ne le voie, par exemple un chemin de script ou un drapeau que le préfixe de la règle n'avait pas anticipé.

Définissez autoMode.classifyAllShell sur 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, sauf les suppressions de chemins critiques.

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

Cela échange la latence contre 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 au 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.

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

Les sous-commandes claude auto-mode vous aident à inspecter, valider et réinitialiser votre configuration.

Imprimez les règles environment, allow, soft_deny et hard_deny intégrées au format JSON :

claude auto-mode defaults

Pour lire la formulation complète d'une règle sans passer par jq, passez --label avec le début du libellé de la règle, par exemple claude auto-mode defaults --label 'Git Destructive'. La correspondance est un préfixe insensible à la casse sur le libellé de chaque règle, et les sections sans correspondance s'affichent comme des listes vides.

Imprimez ce que le classificateur utilise réellement au format JSON, avec vos paramètres appliqués où définis et les valeurs par défaut sinon :

claude auto-mode config

defaults et config impriment tous les quatre listes de règles comme un seul objet JSON, avec chaque règle sous forme de chaîne de prose. Voici un exemple tronqué :

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

Obtenez des commentaires d'IA sur vos entrées personnalisées allow, soft_deny, hard_deny et environment :

claude auto-mode critique

Si vous avez écrit des règles personnalisées, claude auto-mode critique les examine et signale les entrées ambiguës, redondantes ou susceptibles de causer des faux positifs.

Pour abandonner vos personnalisations et revenir aux paramètres par défaut intégrés, exécutez la sous-commande reset, qui supprime la section autoMode de votre fichier de paramètres utilisateur :

claude auto-mode reset

La commande résume ce qu'elle supprimera et demande Reset auto mode configuration to defaults? avant d'écrire ; passez --yes pour ignorer la confirmation. Reset modifie uniquement ~/.claude/settings.json : les règles autoMode des paramètres gérés par le serveur ou l'indicateur --settings s'appliquent toujours.

Examiner les refus

Pour permettre à Claude de réessayer une action bloquée, utilisez l'onglet Recently blocked dans /permissions :

1. Ouvrir l'onglet

Exécutez /permissions dans votre session pour ouvrir la boîte de dialogue des permissions, puis sélectionnez l'onglet Recently blocked.

2. Vérifier l'action

Mettez en surbrillance la ligne de l'action et lisez sa commande ou son entrée sous la liste. Fiez-vous à la commande ou à l'entrée, et non à la description de la ligne, qui a été rédigée par Claude ou par l'outil.

3. Approuver l'action

Appuyez sur r pour approuver l'action et permettre à Claude de la réessayer.

4. Fermer la boîte de dialogue

Appuyez sur Esc pour fermer la boîte de dialogue et appliquer votre approbation. Si Claude était en train de travailler lorsque vous avez ouvert /permissions, envoyez un message une fois que Claude a terminé pour lui permettre de réessayer l'action. Sinon, vous n'avez rien à envoyer : Claude continue immédiatement et peut la réessayer. Si ce n'est pas le cas, nommez l'action dans votre prochain message, comme le décrit Approbations que vous énoncez dans la conversation.

Approuver une action n'ajoute pas de règle de permission. En mode auto, une action réessayée passe à nouveau par la vérification et peut donc être bloquée de nouveau. Pour laisser passer une commande à partir de maintenant, ajoutez une règle allow.

Si vous ne voulez pas que Claude réessaie tout de suite, vous pouvez approuver une action pour plus tard, retirer une approbation, ou fermer la boîte de dialogue et abandonner vos approbations :

• Approuver pour plus tard : appuyez sur Enter sur la ligne, puis sur Esc. La ligne quitte l'onglet, et Claude peut réessayer l'action après votre prochain message, une fois que Claude a terminé. Si vous avez également appuyé sur r sur une autre ligne, la ligne sur laquelle vous avez appuyé sur Enter reste dans l'onglet et Claude n'est pas informé de cette action. Approuvez cette ligne lors de votre prochaine visite, ou appuyez sur r sur les deux
• Retirer une approbation : avant d'appuyer sur Esc, appuyez sur Enter sur la ligne, que vous l'ayez approuvée avec Enter ou avec r
• Fermer la boîte de dialogue et abandonner vos approbations : appuyez deux fois sur Ctrl+C

Vous ne pouvez pas approuver une action depuis l'onglet lorsque sa ligne ne peut pas afficher l'intégralité de sa commande ou de son entrée, ou lorsque l'action n'a pas de ligne :

• La ligne indique This row can't be approved here : si vous aviez l'intention d'effectuer cette action, dites-le à Claude dans votre prochain message et Claude pourra la tenter à nouveau
• Aucune ligne, et Not run ou une erreur du classifieur dans la conversation : le classifieur du mode auto n'a rendu aucun verdict. Pour savoir comment exécuter l'action, consultez Auto mode cannot determine the safety of an action

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

Les avis se présentent sous la forme bash blocked by auto mode · /permissions · Auto mode: [Data Exfiltration]. Pour lire la commande ou l'URL derrière l'un d'eux, utilisez l'onglet Recently blocked, un hook ou la conversation :

• Onglet Recently blocked : mettez en surbrillance la ligne de l'action. En mode lecteur d'écran, toutes les commandes et entrées apparaissent avant la liste.
• Hook : pour capturer l'entrée exacte des refus par programmation, ajoutez un hook PermissionDenied, qui la reçoit en tant que tool_input. Si votre hook lit reason, attendez-vous à l'absence du préfixe Auto mode: et à un texte tel que Blocked by classifier au lieu de No reason provided.
• Conversation : trouvez l'appel d'outil. Si l'appel apparaît raccourci ou replié dans une ligne de résumé telle que Ran 3 shell commands, appuyez sur Ctrl+O pour ouvrir la visionneuse de transcription, qui le développe.

Le texte sous l'appel vous indique s'il y a quelque chose à corriger. Une ligne grisée Not run · auto mode's check had no usable answer, ou un texte qui signale un problème avec le classificateur lui-même, tel que Auto mode could not evaluate this action, signifie que Claude Code a bloqué l'appel sans verdict du classificateur. Pour une ligne Not run, appuyez sur Ctrl+O pour lire le message complet, puis consultez Auto mode cannot determine the safety of an action ou The server returned no safety verdict pour savoir quoi faire.

Sinon, une ligne Blocked by auto mode signifie que le classifieur a jugé l'appel non sécurisé. Pour laisser passer l'appel, effectuez l'étape qui correspond à ce que Claude tentait d'atteindre ou de faire :

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

Vous pouvez ajouter l'entrée d'environnement ou la règle allow à partir de l'onglet Auto mode de la boîte de dialogue /permissions.

Le texte entre crochets, tel que [Data Exfiltration], est le nom de la règle que le classificateur a mise en correspondance. Pour lire le libellé complet de cette règle, consultez Inspecter les valeurs par défaut et votre configuration effective.

Corriger les refus répétés

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, ou exécutez /auto-mode-setup pour que Claude Code rédige les entrées, puis exécutez claude auto-mode config pour confirmer que la modification a pris effet.

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