Comment arrêter les demandes d'autorisation de Claude Code

Claude Code demande avant d'agir. C'est par conception, et à la première approche d'un dépôt inconnu, c'est le bon comportement par défaut. Après vingt demandes au cours d'une refonte, cela cesse de ressembler à de la sécurité et commence à ressembler à de la friction.

Il existe une réponse officielle, et ce n'est pas un commutateur qui éteint la vérification. Claude Code embarque six modes de permission, et celui conçu pour ce problème achemine les actions via un modèle classifieur séparé plutôt que par vous.

TL;DR

• Six modes : default (affiché comme Manual), acceptEdits, plan, auto, dontAsk, bypassPermissions^[1].
• auto est celui que vous voulez pour les tâches longues. Un classifieur examine chaque action ; vous cessez de voir les demandes routinières^[1].
• Shift+Tab bascule les modes en session. La barre d'état affiche celui qui est actif^[1].
• Les règles de permission sont la correction chirurgicale. Pré-approuvez les commandes spécifiques que vous continuez d'approuver, avec allow, et gardez tout le reste demandant^[2].
• Un vrai piège : defaultMode: "auto" est ignoré dans .claude/settings.json. Il doit vivre dans ~/.claude/settings.json^[1].
• bypassPermissions n'est pas la réponse en dehors des conteneurs isolés et des machines virtuelles^[1].

Les six modes

La source est la documentation des modes de permission d'Anthropic^[1]. Notez la nommage : le mode qui examine chaque action est étiqueté Manual dans la CLI et les extensions, tandis que sa valeur de config reste default. manual fonctionne comme un alias partout où vous tapez la valeur, sur v2.1.200 et plus tard.

Basculer en session

Appuyez sur Shift+Tab pour boucler default → acceptEdits → plan. La barre d'état affiche le mode actif : ⏸ manual mode on, ⏵⏵ accept edits on, ⏵⏵ auto mode on, ⏵⏵ don't ask on, ou ⏵⏵ bypass permissions on^[1].

Tous les modes ne sont pas dans cette boucle par défaut :

• auto apparaît une fois que votre compte répond à ses exigences, et basculer dedans ne demande pas de confirmation.
• bypassPermissions ne s'affiche que si vous avez lancé avec --permission-mode bypassPermissions, --dangerously-skip-permissions, --allow-dangerously-skip-permissions, ou l'avez défini comme defaultMode.
• dontAsk ne s'affiche jamais. Réglez-le avec --permission-mode dontAsk.

Au démarrage, passez-le comme un drapeau :

claude --permission-mode auto

Mode auto, et ce qu'il vérifie réellement

Le mode auto ne supprime pas l'examen. Il transfère l'examen de votre clavier vers un modèle classifieur séparé qui inspecte les actions avant qu'elles ne s'exécutent, bloquant tout ce qui s'escalade au-delà de ce que vous avez demandé, cible une infrastructure non reconnue ou semble poussé par un contenu hostile que Claude a lu^[1].

Les règles ask explicites forcent toujours une demande, donc tout ce que vous avez délibérément marqué comme nécessitant une confirmation continue de confirmer.

Ce qu'il bloque par défaut^[1] :

• Télécharger et exécuter du code, comme curl | bash
• Envoyer des données sensibles à des points de terminaison externes
• Déploiements et migrations de production
• Suppression en masse du stockage cloud
• Octroi de permissions IAM ou de dépôt
• Forcer la poussée
• git reset --hard, git checkout -- ., git restore ., git clean -fd, git stash drop, git stash clear
• git commit --amend quand le commit HEAD n'a pas été créé dans cette session ou a déjà été poussé
• terraform destroy, pulumi destroy, cdk destroy, terragrunt destroy
• Détruire irrémédiablement des fichiers qui existaient avant la session
• Valider ou pousser une modification qui enverrait des secrets en dehors du dépôt, ou élargir ce qu'un déploiement expose

Le classifieur fait confiance à votre répertoire de travail et aux distants git configurés au début de la session. Un distant ajouté ou réorienté en session avec git remote add ou git remote set-url est pas approuvé^[1].

Anthropic énonce clairement la limite : le mode auto réduit les demandes mais ne garantit pas la sécurité. C'est pour les tâches où vous faites confiance à la direction générale, pas un substitut à l'examen des opérations sensibles^[1].

Exigences

Le mode auto n'est disponible que lorsque tous ces éléments sont vrais^[1] :

• Forfait : tous les forfaits.
• Propriétaire : sur Team et Enterprise, un propriétaire doit d'abord l'activer dans les paramètres d'administration de Claude Code. Les administrateurs peuvent également le forcer avec permissions.disableAutoMode: "disable" dans les paramètres gérés.
• Modèle : sur l'API Anthropic, Claude Opus 4.6 ou plus tard, Sonnet 4.6 ou plus tard, ou Fable 5. Sur Bedrock, la plateforme Agent de Google Cloud et Microsoft Foundry, seuls Sonnet 5, Opus 4.7 ou plus tard et Fable 5. Les modèles plus anciens incluant Sonnet 4.5, Opus 4.5, Haiku et claude-3 sont non supportés partout.
• Fournisseur : disponible par défaut sur l'API Anthropic, Claude Platform sur AWS, Bedrock, Agent Platform, Foundry et les sessions de passerelle d'applications Claude connectées.

Si Claude Code signale que le mode auto est indisponible, l'une de ces conditions n'est pas remplie. Ce n'est pas une panne transitoire.

Le piège des paramètres

Celui-ci gaspille du temps réel. Si vous réglez defaultMode: "auto" et que la session démarre toujours en Manual sans erreur, le paramètre est probablement dans le mauvais fichier.

À partir de v2.1.142, Claude Code ignore auto dans .claude/settings.json et .claude/settings.local.json, donc un dépôt ne peut pas s'accorder lui-même le mode auto^[1]. Il doit être dans vos paramètres utilisateur :

// ~/.claude/settings.json
{
  "permissions": {
    "defaultMode": "auto"
  }
}

Les fichiers de paramètres se rechargent à chaud, donc les modifications permissions s'appliquent à une session en exécution sans redémarrage^[2].

La correction chirurgicale : règles de permission

Les modes définissent une base de référence. Les règles sont ce que vous saisissez quand les mêmes trois commandes continuent de demander et tout le reste va bien.

// ~/.claude/settings.json
{
  "permissions": {
    "allow": ["Bash(git diff *)", "Bash(npm test *)"],
    "ask":   ["Bash(git push *)"],
    "deny":  ["Read(./.env)", "Read(./secrets/**)", "Bash(curl *)"]
  }
}

Trois choses méritent d'être su sur le comportement de ces éléments^[2] :

Les règles fusionnent entre les portées plutôt que de se remplacer. Contrairement à la plupart des paramètres, où une valeur de projet remplace une valeur utilisateur, les règles de permission des paramètres utilisateur, projet, local et gérés restent toutes en vigueur.

deny et ask explicite s'appliquent dans chaque mode, y compris bypassPermissions. Cela fait deny le bon endroit pour les secrets : Read(./.env) tient indépendamment du mode dans lequel quelqu'un bascule.

Les règles d'autorisation locale ignorent l'étape de confiance de l'espace de travail. Les règles dans votre propre .claude/settings.local.json prennent effet sans l'invite de confiance que les règles d'autorisation de .claude/settings.json exigent, car ce fichier est le vôtre plutôt que celui du dépôt. Si le dépôt valide le fichier, la confiance s'applique à nouveau.

Pourquoi ne pas simplement contourner tout

bypassPermissions existe et il fait ce que le nom dit. Anthropic le limite aux conteneurs isolés et aux machines virtuelles, et la raison est structurelle plutôt que prudente.

Les écritures sur les chemins protégés ne sont jamais pré-approuvées dans aucun mode sauf bypassPermissions^[1]. Ces protections gardent l'état du dépôt et la configuration d'Claude contre la corruption accidentelle. Les éteindre sur une machine qui contient quelque chose dont vous vous souciez supprime la dernière chose se tenant entre une mauvaise commande et votre arborescence de travail.

Si la fatigue des demandes est le problème, auto la résout tout en gardant un classifieur en boucle. Atteignez bypassPermissions seulement quand tout l'environnement est jetable.

Choisir une configuration

Travailler dans un dépôt inconnu : restez en Manual. Les demandes font leur travail.

Séance d'édition que vous observez activement : acceptEdits via Shift+Tab. Les éditions de fichiers cessent de demander, les commandes toujours.

Tâche autonome longue : auto, défini comme defaultMode dans ~/.claude/settings.json si vous le voulez à chaque session.

La même commande demandant vingt fois : une règle allow pour cette commande, pas un changement de mode.

CI ou un script : dontAsk avec une liste d'approbation explicite, donc tout ce qui n'est pas listé échoue plutôt que d'attendre.

Conteneur jetable : bypassPermissions, et seulement là.

FAQ

Comment j'arrête Claude Code de demander la permission ?

Basculez en mode auto, qui achemine les actions via un classifieur au lieu de vous demander. Appuyez sur Shift+Tab pour basculer dedans en session, commencez par claude --permission-mode auto, ou réglez defaultMode: "auto" dans ~/.claude/settings.json^[1].

Pourquoi mon defaultMode: "auto" est-il ignoré ?

Parce qu'il est dans .claude/settings.json ou .claude/settings.local.json. Claude Code ignore auto de ces fichiers afin qu'un dépôt ne puisse pas s'accorder lui-même le mode. Déplacez-le vers ~/.claude/settings.json^[1].

Le mode auto signifie-t-il aucune vérification de sécurité ?

Non. Un classifieur séparé examine chaque action et bloque l'escalade, l'infrastructure non reconnue, les opérations git destructrices, les déploiements de production et plus. Les règles ask explicites demandent toujours^[1].

Pourquoi le mode auto est-il indisponible pour moi ?

L'une des exigences n'est pas remplie : forfait, un propriétaire l'activant sur Team ou Enterprise, un modèle supporté ou un fournisseur supporté. Ce n'est pas une panne transitoire^[1].

Comment j'arrête une commande spécifique de demander ?

Ajoutez une règle allow pour elle plutôt que de changer de mode : "allow": ["Bash(npm test *)"]^[2].

Quelle est la différence entre Manual et default ?

Aucune. default est la valeur de config ; Manual est l'étiquette affichée dans la CLI et les extensions. manual fonctionne comme un alias sur v2.1.200 et plus tard^[1].

Puis-je empêcher Claude de lire .env ?

Oui, avec une règle deny. Les règles de refus s'appliquent dans chaque mode y compris bypassPermissions^[2].

bypassPermissions est-il sûr sur mon ordinateur portable ?

Non. Il est limité aux conteneurs isolés et aux machines virtuelles, et c'est le seul mode où les écritures sur les chemins protégés sont pré-approuvées^[1].

Mettre en correspondance le mode et le risque

L'instinct quand les demandes s'accumulent est de chercher le commutateur qui éteint la vérification. Ce commutateur existe, et c'est le mauvais pour une machine dont vous vous souciez.

Le meilleur encadrement est que Claude Code vous donne trois cadrans séparés : un mode qui définit la base de référence, des règles qui découpent les outils spécifiques dans les deux sens, et un classifieur qui examine ce que le mode laisserait autrement passer. La fatigue des demandes sur une tâche longue est un problème de mode, résolu par auto. La même commande demandant vingt fois est un problème de règles, résolu par une ligne allow. Savoir comment arrêter Claude Code de demander la permission, c'est surtout savoir quel problème vous avez réellement.

References

1. Anthropic. Claude Code permission modes — the six modes, auto mode requirements, and what the classifier blocks. Retrieved July 2026 from docs.claude.com/en/docs/claude-code/permission-modes
2. Anthropic. Claude Code settings — permission rules, scopes, and precedence. Retrieved July 2026 from docs.claude.com/en/docs/claude-code/settings

Further reading

• reAPI. How to use Claude Code. reapi.ai/blog/how-to-use-claude-code
• reAPI. How to use Claude Opus 5. reapi.ai/blog/how-to-use-claude-opus-5
• reAPI. Model catalog. reapi.ai/models