Claude Code demande sans cesse l’autorisation ? Réglez le problème sans --dangerously-skip-permissions
Approuver npm test pour la quarantième fois, c’est du bruit. Claude Code a tout ce qu’il faut pour faire taire les demandes sans intérêt et garder les dangereuses. Tout est simplement réparti entre trois fichiers et six modes.
RÉPONSE COURTE
Placez les commandes que vous approuvez toujours dans permissions.allow (par exemple Bash(npm run *)), celles qui doivent toujours s’arrêter dans ask ou deny, et choisissez un mode d’autorisation adapté à la tâche : acceptEdits pour beaucoup de modifications, auto pour le travail courant, plan pour la lecture. Les règles sont évaluées dans l’ordre deny → ask → allow, donc un deny ne peut jamais être contourné. Utilisez /permissions pour voir d’où vient chaque règle. Réservez --dangerously-skip-permissions aux conteneurs jetables.
Pourquoi Claude Code demande si souvent
Dans le mode par défaut (appelé Manual dans la CLI), Claude Code demande l’autorisation la première fois qu’il utilise chaque outil, puis à nouveau pour chaque commande shell qu’il n’a pas encore le droit d’exécuter. Cette demande est le moment où vous pouvez arrêter un rm erroné ou un git push accidentel : elle mérite d’être conservée. Le problème, c’est qu’elle se déclenche aussi pour les centaines d’actions inoffensives qu’un agent effectue au cours d’une session.
Trois éléments déterminent si une demande s’affiche : les règles de vos fichiers de paramètres, le mode d’autorisation actif et les réponses données précédemment avec « Yes, and don’t ask again ». Pour réduire le bruit, il faut régler les trois.
Depuis la v2.1.283, Claude Code démarre les sessions interactives dans le terminal et dans VS Code en mode auto, quels que soient le forfait et le fournisseur. En mode auto, un classifieur en arrière-plan compare les commandes et les requêtes réseau à ce que vous avez demandé, au lieu de vous solliciter pour les actions de routine. Si une demande s’affiche encore pour tout, regardez la barre d’état : « ⏸ manual mode on » signifie que vous êtes dans le mode par défaut.
Règles allow, ask et deny
Les règles se trouvent sous permissions dans un fichier de paramètres. Cet exemple provient directement de la référence des paramètres d’Anthropic :
allow: s’exécute sans demander.ask: demande toujours, même dans les modes qui l’approuveraient sinon.deny: ne s’exécute jamais.
L’ordre est essentiel : deny, puis ask, puis allow. La première correspondance l’emporte, et une règle plus précise ne change pas cet ordre. Une règle allow ne peut pas créer d’exception à une règle deny, et si un outil est refusé à un niveau, aucun autre niveau ne peut l’autoriser. Les règles sont appliquées par Claude Code lui-même, pas par le modèle : écrire « never push » dans CLAUDE.md n’a donc pas le même effet qu’une règle deny.
Comment écrire une règle
| Règle | Ce qu’elle cible |
|---|---|
Bash(npm run *) | npm run build, npm run test --watch, mais pas npm install |
Bash(git log *) | Uniquement git log …. À comparer avec Bash(git *), qui autorise toutes les commandes git. |
Bash(ls:*) | Identique à Bash(ls *) : :* est une autre façon d’écrire un caractère générique final |
Read(./.env) | La lecture de ce fichier. Les règles Read et Edit utilisent les motifs de gitignore |
Edit(//Users/alice/notes/**) | Un chemin absolu. Un seul / au début est relatif au fichier de paramètres, les chemins absolus nécessitent donc // |
WebFetch(domain:example.com) | Uniquement example.com. Ajoutez WebFetch(domain:*.example.com) pour les sous-domaines |
mcp__github__* | Tous les outils du serveur MCP github. Les règles avec des parenthèses après mcp__ sont ignorées |
Sous Windows, les règles PowerShell ont la même forme que les règles Bash.
Quel fichier de paramètres utiliser
| Portée | Fichier | À utiliser pour |
|---|---|---|
| Utilisateur | ~/.claude/settings.json (Windows : %USERPROFILE%\.claude\settings.json) | Vos propres habitudes, dans tous les projets |
| Projet, partagé | .claude/settings.json | Les règles que toute l’équipe doit recevoir (à commiter) |
| Projet, local | .claude/settings.local.json | Vos règles personnelles pour un dépôt (non commitées) |
| Géré | managed-settings.json et autres sources gérées | La stratégie de l’entreprise ; rien ne peut la remplacer |
Priorité, de la plus haute à la plus basse : géré, ligne de commande, projet local, projet partagé, utilisateur. Les clés de type liste comme permissions.allow sont cumulées entre les fichiers, pas remplacées. Deux détails piègent souvent :
- Les fichiers de paramètres sont du JSON strict : un commentaire
//ou une virgule finale est une erreur de syntaxe, et tout le fichier est ignoré. - Les règles allow d’un fichier de projet partagé ne s’appliquent qu’une fois que chaque membre de l’équipe a approuvé le dossier. Les règles deny et ask s’appliquent immédiatement.
La plupart des modifications s’appliquent à la session en cours sans redémarrage, y compris permissions et hooks. Pour voir ce qui a réellement été chargé, lancez /status (ligne Setting sources) ou /permissions, qui liste chaque règle et le fichier dont elle provient.
Ce que « Yes, and don’t ask again » enregistre vraiment
Répondre à une demande par « don’t ask again » écrit une règle pour vous dans .claude/settings.local.json, à la racine du dépôt git. Sa durée dépend de l’outil :
| Outil | Mémorisé |
|---|---|
| Commandes Bash | De façon permanente, par dépôt et par commande |
| Modifications de fichiers | Jusqu’à la fin de la session |
| WebFetch | De façon permanente, par dépôt et par domaine |
Si Claude redemande de modifier des fichiers à chaque nouvelle session, c’est donc voulu : les approbations de modification de fichiers valent pour une session. Utilisez plutôt le mode acceptEdits ou une règle allow Edit(...). Et si une commande continue de demander même après « don’t ask again », cherchez une règle ask dans un fichier de projet ou un fichier géré. Une règle allow dans votre fichier local ne l’emporte pas sur elle.
Les modes d’autorisation, et quand utiliser chacun
| Mode | Ce qu’il fait | Idéal pour |
|---|---|---|
default (Manual) | Demande à la première utilisation de chaque outil | Dépôts inconnus, travail risqué |
acceptEdits | Accepte les modifications de fichiers sans demander | Longs refactorings que vous relirez dans git |
plan | Lit et planifie, ne modifie rien | Explorer une base de code, concevoir une modification |
auto | Aucune demande de routine ; un classifieur vérifie d’abord les commandes et les requêtes réseau | Le travail au quotidien |
dontAsk | Ne demande rien | Scripts et automatisation |
bypassPermissions | Ignore les demandes, y compris pour les écritures dans .git et .claude | Uniquement dans des conteneurs ou des VM isolés |
Appuyez sur Shift+Tab pour passer d’un mode à l’autre. Depuis auto, le premier appui revient à default, puis default → acceptEdits → plan. Définissez le mode de départ avec permissions.defaultMode ; notez que auto et bypassPermissions ne prennent effet que depuis les paramètres utilisateur ou gérés, pas depuis un fichier de projet.
Certaines actions demandent toujours, dans tous les modes, y compris bypass : les règles ask explicites, les questions que Claude vous pose et rm sur des chemins critiques, entre autres. Les administrateurs peuvent désactiver les modes risqués en définissant permissions.disableBypassPermissionsMode ou permissions.disableAutoMode sur "disable".
À propos de --dangerously-skip-permissions
--dangerously-skip-permissions équivaut à --permission-mode bypassPermissions. La documentation d’Anthropic est sans ambiguïté : ne l’utilisez que dans des environnements isolés comme des conteneurs, des VM ou des dev containers sans accès à Internet. Il refuse de s’exécuter en root sous Linux et macOS, et une fois l’avertissement accepté, il définit skipDangerousModePermissionPrompt dans vos paramètres utilisateur.
Si ce que vous voulez vraiment, c’est « arrêter de me demander des choses sans intérêt », le mode auto et quelques règles allow suffisent, sans renoncer aux demandes qui comptent.
Le bac à sable : moins de demandes, avec un filet de sécurité
Claude Code peut exécuter les commandes shell dans un bac à sable (sandbox). Il est désactivé par défaut ; activez-le avec /sandbox ou sandbox.enabled: true. Un mode du bac à sable approuve automatiquement les commandes isolées, l’autre continue de demander. Le bac à sable ne couvre que les commandes shell : les outils de fichiers, les serveurs MCP et les hooks s’exécutent en dehors.
Il fonctionne sous macOS, Linux et WSL2. Sous Windows natif, le bac à sable ne fonctionne pas, et les commandes s’exécutent sans isolation. C’est une raison de plus d’y garder une courte liste ask.
Une configuration qui fonctionne
Voici un point de départ raisonnable pour un projet JavaScript. Adaptez les commandes à votre stack :
- Commencez par une liste allow de commandes en lecture seule et de tests.
- Placez tout ce qui sort de votre machine (push, publish, deploy) dans
ask. - Refusez purement et simplement l’accès aux secrets.
- Travaillez en mode auto ou acceptEdits, et passez en mode plan quand vous explorez.
- Tous les deux ou trois jours, ouvrez
.claude/settings.local.jsonet faites le tri dans les règles ajoutées par « don’t ask again ».
Quand les demandes restantes ne s’affichent pas au bon endroit
Une fois les réglages faits, on ne devrait vous solliciter que pour ce qui mérite une décision. Le problème restant, c’est l’endroit où la question apparaît : dans un onglet de terminal derrière votre navigateur, où l’agent peut attendre vingt minutes avant que vous ne le remarquiez.
Pet Island déplace ces questions vers une petite île en haut de votre écran. Quand Claude Code a besoin d’une autorisation, la demande s’y affiche avec la commande ou le diff, et vous l’autorisez, la refusez ou l’autorisez toujours sans changer de fenêtre. Les questions et les plans de Claude Code fonctionnent aussi depuis l’île, et si l’île est fermée, Claude Code revient simplement aux demandes dans le terminal.
FAQ
Comment empêcher Claude Code de demander l’autorisation pour chaque commande ?
Ajoutez les commandes de confiance à permissions.allow dans ~/.claude/settings.json, par exemple "Bash(npm run *)", et utilisez le mode auto ou acceptEdits. Gardez les commandes risquées dans permissions.ask pour qu’elles s’arrêtent toujours.
Pourquoi Claude Code redemande-t-il pour les modifications de fichiers alors que j’ai choisi « don’t ask again » ?
Les approbations de modification de fichiers ne durent que jusqu’à la fin de la session. Utilisez le mode acceptEdits ou une règle allow Edit(...) si vous voulez que les modifications restent approuvées d’une session à l’autre.
Une règle allow peut-elle remplacer une règle deny ?
Non. Les règles sont évaluées dans l’ordre deny, puis ask, puis allow, et la première correspondance l’emporte. Un outil refusé à un niveau ne peut être autorisé nulle part ailleurs.
--dangerously-skip-permissions est-il sûr ?
Anthropic ne le recommande que dans des environnements isolés, comme des conteneurs ou des VM sans accès à Internet. Il supprime aussi les demandes pour les écritures dans .git et .claude.
Où « Yes, and don’t ask again » enregistre-t-il la règle ?
Dans .claude/settings.local.json, à la racine du dépôt git.
Le bac à sable de Claude Code fonctionne-t-il sous Windows ?
Pas sous Windows natif : les commandes s’y exécutent sans isolation. Il fonctionne sous macOS, Linux et WSL2.
Sources
Chaque paramètre et chaque comportement décrits sur cette page ont été vérifiés dans ces pages le 26 octobre 2026. Les agents évoluent vite : si quelque chose ne correspond plus, c’est la page officielle qui fait foi.
- Documentation Claude Code : Configure permissions
- Documentation Claude Code : Permission modes
- Documentation Claude Code : Settings
- Documentation Claude Code : Settings reference
- Documentation Claude Code : Sandboxing