Les règles d'autorisation dans Claude Code sont appliquées par le runtime de l'agent, non par le modèle lui-même. Cette distinction a plus d'importance qu'il n'y paraît. Les instructions dans votre prompt ou CLAUDE.md façonnent ce que Claude essaie de faire, mais elles ne modifient pas ce que Claude Code autorise réellement, comme le précise la documentation officielle des autorisations. Pour accorder ou révoquer l'accès, vous utilisez /permissions, les fichiers de paramètres décrits ci-dessous, un mode d'autorisation, ou un hook PreToolUse. Cet article parcourt chaque niveau : choisir un mode, comprendre la précédence, rédiger un fichier de politique fonctionnel, le tester et savoir où le système ne peut pas vous aider.
Choisir un mode d'autorisation
Le mode que vous choisissez établit la base de tout le reste. Il y en a cinq.
Manual arrête Claude Code avant la plupart des modifications de fichiers, des commandes shell et des appels réseau. Vous confirmez chacun d'eux. Lent, mais rien ne vous surprend.
Auto confie l'approbation à un modèle classificateur qui examine les actions en votre nom. Sur les plans Pro, Max et Team, c'est le mode de démarrage intégré, selon la documentation des modes d'autorisation. Le classificateur a ses propres règles sur les actions qu'il examine et celles qu'il ignore, donc auto n'est pas la même chose que « approuver tout ».
Accept Edits approuve automatiquement les opérations sur les fichiers mais affiche toujours une invite pour les commandes shell. Un équilibre raisonnable pour le travail individuel sur une base de code que vous possédez et comprenez.
Plan bloque entièrement les modifications de fichiers et les écritures shell. Claude peut lire, analyser et produire un plan, mais il ne peut pas agir. Idéal pour les examens précoces quand vous voulez voir l'approche avant que rien ne change.
dontAsk refuse automatiquement tout outil qui ne figure pas sur votre liste d'autorisation explicite. Pas d'invite, juste un refus silencieux. C'est le bon mode pour les pipelines CI/CD où personne ne surveille.
bypassPermissions contourne tous les contrôles. Claude exécute ce qu'il veut. Utile dans les environnements jetables en bac à sable ; pas quelque chose à exécuter contre un dépôt de production.
Pour épingler le mode de démarrage dans VS Code, définissez claudeCode.initialPermissionMode dans vos paramètres utilisateur à default, manual, acceptEdits, plan ou bypassPermissions. Note : ce paramètre n'accepte pas auto. Pour démarrer en Auto, laissez-le non défini et choisissez-le une fois à partir de l'indicateur de mode ; l'extension mémorise ce choix pour les conversations suivantes.
Pour les sessions de terminal, définissez permissions.defaultMode dans ~/.claude/settings.json ou dans les paramètres gérés. Cette valeur s'applique sur les plans Pro, Max et Team quand la récupération des drapeaux de fonctionnalité est disponible.
Un cas limite à connaître : si votre organisation a défini un outil connecteur claude.ai sur ask, les règles d'autorisation pour cet outil ne prennent pas effet même en modes auto ou bypassPermissions. Claude Code affiche une invite à chaque appel. En mode dontAsk, il refuse l'appel au lieu d'afficher une invite.
Comment fonctionnent la précédence des règles et des paramètres
Cinq niveaux, évalués de haut en bas. Un niveau supérieur prévaut.
- Paramètres gérés (
managed-settings.json) : déployés par l'IT, non remplaçables. Si votre organisation bloque SSH ici, c'est définitif. - Paramètres locaux (
.claude/settings.local.json) : par machine, ignoré par git par défaut. Les remplacements personnels ou sensibles en matière de sécurité vont ici. - Paramètres du projet (
.claude/settings.json) : validés dans le dépôt. Partagés sur l'ensemble de l'équipe pour ce projet. - Paramètres utilisateur (
~/.claude/settings.json) : valeurs par défaut globales, appliquées à chaque projet sauf si une couche supérieure les annule. - Drapeaux de session :
--dangerously-skip-permissionset arguments de runtime similaires.
La documentation de configuration administrateur ajoute deux contrôles de verrouillage à connaître : allowManagedPermissionRulesOnly (rend les paramètres gérés la seule source de règles de permissions, ignorant les fichiers utilisateur et projet) et permissions.disableBypassPermissionsMode (supprime entièrement l'option de contournement). Si vous exploitez une agence avec des prestataires accédant aux dépôts clients, ces deux paramètres réunis vous donnent un plafond inviolable qu'aucun développeur ne peut silencieusement annuler.
Chaque couche accepte trois types de règles : allow, deny et ask. Au sein d'une couche, deny a la priorité sur allow. La correspondance de motif shell est prise en charge (par exemple Bash(git *)), mais soyez précis : un motif qui semble hermétique en test souvent des failles quand les chaînes de commande réelles diffèrent de ce que vous attendiez.
Un point que la documentation signale explicitement : refuser WebFetch bloque l'outil fetch de Claude, mais si Bash est autorisé, curl et wget peuvent quand même atteindre n'importe quelle URL. Le sandboxing (via /sandbox) comble cette lacune avec une liste blanche de domaines appliquée au niveau du système d'exploitation. Les permissions et le sandboxing couvrent des couches différentes et vous en voulez généralement les deux pour tout ce qui est sérieux.
Exemple de politique de dépôt client
Voici un .claude/settings.json illustratif pour un projet client où l'équipe peut lancer les compilations et lire la base de données mais ne doit pas toucher aux scripts de déploiement ni aux secrets. C'est une structure représentative, non une politique de production à copier-coller.
{
"permissions": {
"defaultMode": "auto",
"allow": [
"Bash(npm run build)",
"Bash(npm run test*)",
"Bash(git log*)",
"Bash(git diff*)",
"Bash(git status)",
"Read(**)"
],
"deny": [
"Bash(rm -rf*)",
"Bash(git push*)",
"Bash(kubectl*)",
"Edit(.env*)",
"Edit(deploy/**)"
]
}
}
En parallèle, un ~/.claude/settings.json sur chaque machine de développeur gère la confiance globale personnelle, comme autoriser curl pour un usage général. Les identifiants sensibles ou les chemins spécifiques à la machine vont dans .claude/settings.local.json, que git ne validera pas.
Pour le côté CLAUDE.md, où vous définissez des conventions et un contexte de projet plutôt que des règles d'application, le guide agence CLAUDE.md couvre le flux de rédaction en détail.
Testez la politique avec des commandes réalistes
Mettez la politique dans un dépôt jetable (un git init nu dans un répertoire temporaire fonctionne bien), puis exécutez une poignée de commandes qui exercent les trois catégories de règles. L'objectif est de voir lesquelles demandent confirmation, lesquelles s'exécutent silencieusement, et lesquelles sont refusées sans demande.
Une séquence de test représentative :
npm run build(devrait être auto-approuvé, c'est dans la liste d'autorisation)git diff HEAD~1(devrait être auto-approuvé)git push origin main(devrait être refusé)rm -rf node_modules(devrait être refusé)- Éditer un fichier dans
deploy/(devrait être refusé) - Éditer
src/index.js(pas de règle de refus, pas d'autorisation explicite : le comportement dépend du mode) - Un appel
curlvers une URL externe (teste comment les règles d'autorisationBashet le sandbox interagissent)
Regardez spécifiquement le cas 6. En mode auto le classificateur l'examine. En mode dontAsk il est silencieusement refusé car il n'est pas sur la liste d'autorisation. Cette différence surprendra les développeurs qui testent en un mode et déploient dans un autre.
Si vous ajoutez de l'automatisation au niveau des événements (exécution de linters sur les sauvegardes de fichiers, déclenchement de notifications sur des appels d'outil spécifiques), c'est une préoccupation de hooks plutôt que de permissions. Le guide hooks couvre PreToolUse et PostToolUse complètement.
Pour les équipes qui ont besoin d'exécutions sans surveillance ou d'intégration CI, envisagez d'utiliser la configuration de l'agence Claude Code pour obtenir la ligne de base de configuration dès le départ.
Paramètres gérés et tâches sans surveillance
Quand aucune personne n'est présente pour cliquer sur « approuver », le modèle de permissions doit être entièrement pré-déclaré. Cela pointe vers le mode dontAsk avec une liste d'autorisation explicite dans les paramètres gérés.
La documentation de configuration d'admin vous donne permissions.defaultMode comme clé gérée pour cela. Définissez-le sur dontAsk, puis énumérez exactement ce dont la tâche a besoin dans permissions.allow. Tout ce qui n'est pas listé est silencieusement refusé. C'est ce que vous voulez dans un pipeline.
Quelques points que la documentation officielle note pour les scénarios d'équipe d'agent (où une session lead crée des coéquipiers) :
- Les coéquipiers commencent avec les paramètres de permission du lead. Si le lead s'exécute avec
--dangerously-skip-permissions, tous les coéquipiers le font aussi. - Vous pouvez modifier les modes de coéquipier individuels après leur création, mais pas au moment de la création.
- Les invites de permission des coéquipiers apparaissent dans la session lead. Les approbations de plan sont l'exception conçue : le lead les accorde sans invite séparée.
Managed Agents (le service d'orchestration au niveau de la plateforme) est actuellement en version bêta selon l'aperçu de Managed Agents. N'architecturez pas les pipelines de production autour de fonctionnalités bêta sans solution de secours.
Pour le flag permissions.disableAutoMode : le définir supprime le mode auto comme option pour les développeurs de cette organisation. Utile quand vous voulez que toutes les sessions restent dans un mode où un humain ou une liste d'autorisation explicite prend chaque décision, plutôt qu'un classificateur.
Ce que les permissions ne peuvent pas garantir
Réponse honnête : pas mal de choses.
Les règles de refus basées sur des modèles shell ne sont pas une limite de sécurité. Elles correspondent à la chaîne de commande que Claude Code construit, mais une injection de prompt suffisamment créative ou une reformulation intelligente d'une commande shell peut produire des chaînes que vos modèles ne détectent pas. La documentation des permissions est explicite : les règles de refus et le sandboxing couvrent des couches différentes. Vous avez besoin des deux, et même dans ce cas vous réduisez le risque, vous ne l'éliminez pas.
Le mode bypassPermissions ne rend pas le code autorisé inoffensif. Si Claude exécute du code qui contient un bug ou fait quelque chose d'inattendu, ignorer les vérifications de permission signifie qu'il n'y avait aucune porte entre « Claude a décidé de le faire » et « c'est arrivé ».
Les permissions ne vérifient pas non plus ce qui se trouve à l'intérieur du code que Claude écrit ou exécute. Une dépendance qu'il installe, un script qu'il exécute, le contenu d'un fichier qu'il crée : rien de tout cela n'est inspecté par le système de permissions. C'est une préoccupation distincte, plus proche de l'hygiène de la chaîne d'approvisionnement que de la politique d'exécution.
Et le modèle lui-même n'est pas la couche d'application. Vous pouvez écrire des instructions CLAUDE.md qui disent « ne touchez jamais aux secrets de production ». Ces instructions façonnent l'intention de Claude. Elles ne préviennent pas une règle d'autorisation mal configurée de permettre que cela se produise de toute façon. Le runtime est la couche d'application. Les fichiers de paramètres sont la manière de configurer le runtime. Traitez-les en conséquence.
FAQ
Les paramètres de permission se synchronisent-ils automatiquement entre les machines ?
Non. Les paramètres utilisateur (~/.claude/settings.json) sont locaux à chaque machine. Les paramètres de projet (.claude/settings.json) se synchronisent via git. Les paramètres gérés sont distribués par votre infrastructure IT. Il n'y a pas de synchronisation intégrée pour les fichiers au niveau utilisateur ; chaque développeur doit configurer les leurs.
Les développeurs peuvent-ils ignorer les paramètres gérés ?
Seulement dans les limites que les paramètres gérés permettent. Si allowManagedPermissionRulesOnly est défini, les règles de permission utilisateur et projet sont entièrement ignorées. Sans ce flag, les paramètres utilisateur et projet peuvent ajouter des règles d'autorisation, mais ils ne peuvent pas ignorer un refus géré.
Qu'advient-il des invites de permission dans les environnements headless ou CI ?
En mode dontAsk, tout ce qui n'est pas sur la liste d'autorisation est silencieusement refusé. Aucune invite n'apparaît car il n'y a pas de terminal pour l'afficher. C'est volontaire. En mode auto dans un environnement headless, le classificateur s'exécute toujours, mais s'il ne peut pas résoudre une invite (pas de TTY), le comportement dépend de la configuration du runner. Utilisez dontAsk avec une liste d'autorisation explicite pour les tâches sans surveillance.
Le mode de permission s'applique-t-il aux outils MCP de la même manière qu'aux outils intégrés ?
Principalement, mais avec des différences. Les outils MCP récupérés directement par Claude Code apparaissent sous la forme mcp__claude_ai_<server>__<tool>. Les règles d'autorisation et de refus peuvent les cibler par ce nom. Les outils provenant de connecteurs que votre organisation a configurés pour demander systématiquement vous invitent toujours, indépendamment du mode, sauf en mode dontAsk, où ils sont refusés à la place.
Est-il sûr de valider `.claude/settings.json` dans un dépôt public ?
Le fichier lui-même ne contient que du JSON avec des noms d'outils et des motifs, pas de secrets. Mais une liste d'autorisation publique indique à quiconque lit votre dépôt exactement quelles opérations Claude Code exécutera sans demander confirmation. Pour les projets open-source, c'est probablement acceptable. Pour tout ce qui est propriétaire, vérifiez ce que vous validez. Les secrets et les clés API ne doivent jamais apparaître dans aucun fichier de paramètres ; ils appartiennent aux variables d'environnement en dehors de la configuration de Claude Code.
L'essentiel à retenir : les règles de refus et le sandboxing résolvent des problèmes différents, et aucun des deux ne peut se substituer à l'autre. Configurez les deux si vous exécutez Claude Code dans un environnement où le coût d'une erreur est réel.