Autorisations Claude Code : arrêtez de les ignorer, commencez à décider

Recherchez « Claude Code permissions » et la moitié des résultats vous expliqueront comment les désactiver. --dangerously-skip-permissions, l'option YOLO, une liste d'autorisation longue comme le bras. Cela donne une impression de productivité. C'est un mauvais réflexe, et cet article présente la bonne approche.

Pourquoi ignorer les autorisations de Claude Code est une mauvaise solution

Ignorer les autorisations supprime la demande sans apporter le moindre discernement. Tout le problème est là. La demande en soi n'a jamais été le sujet. Ce qui compte, c'est la décision sous-jacente : cette action peut-elle être exécutée en toute sécurité à cet instant précis ? Faites taire la demande, et la décision ne s'améliore pas. Elle disparaît. Un mauvais rm -rf ou un force-push sur un historique partagé s'exécute désormais sans aucun filtre entre l'agent et votre dépôt.

La friction est réelle, et on a de bonnes raisons de la détester. Approuver le même ls inoffensif pour la cinquantième fois vous habitue à cliquer sur oui pour tout, et c'est précisément ainsi que l'appel dangereux passe entre les mailles du filet. Mais la solution n'est pas de réduire le discernement. C'est de l'intégrer au code, pour ne plus être le goulot d'étranglement sans pour autant rester sans défense.

Le véritable modèle d'autorisation : autoriser, refuser ou demander

Chaque appel d'outil dans Claude Code passe par une étape PreToolUse avant de s'exécuter, et un hook associé à cet outil peut rendre l'un des trois verdicts suivants : autoriser, refuser ou demander. Voilà le modèle. L'autorisation n'est pas une liste statique à maintenir à la main. C'est une question de politique de sécurité à laquelle votre code répond, pour chaque appel, face à la commande réelle.

Vous associez un hook à un outil via un filtre. Filtrez sur Bash et votre script verra chaque commande shell avant son exécution. Filtrez sur Edit|Write|MultiEdit|NotebookEdit et il verra chaque fichier que l'agent s'apprête à modifier. Le hook lit l'entrée de l'outil depuis stdin, décide et affiche son verdict. Pour refuser, il renvoie du JSON avec hookSpecificOutput.permissionDecision défini sur "deny", et Claude Code rejette l'appel. Voilà comment cela fonctionne. Si vous voulez tous les détails techniques, nous les avons décrits dans hooks Claude Code.

Deux décisions opposées que nous avons intégrées, et pourquoi

Dans le kit kitstarter, nous exécutons deux hooks PreToolUse qui prennent délibérément des décisions opposées. L'un bloque strictement. L'autre se contente d'avertir. Cette divergence contient toute la leçon : voici chacun d'eux et la logique qui les sous-tend.

Le verrou de build : clarity.mjs refuse les modifications tant que l'objectif n'est pas confirmé

Notre hook de clarté cible Edit|Write|MultiEdit|NotebookEdit et, tant qu'une demande de build floue n'est pas confirmée, renvoie permissionDecision: "deny" systématiquement. L'agent ne peut physiquement pas écrire de code avant que l'objectif ne soit validé. C'est un véritable verrou, appliqué par l'outil, et non une consigne polie dans un fichier Markdown que le modèle pourrait survoler et ignorer.

Le motif de refus affiché est l'explication textuelle suivante : « l'objectif n'est pas encore confirmé, le build est donc verrouillé. Terminez la phase de clarification : posez des questions à choix multiples, une à la fois, reformulez l'objectif, obtenez un oui explicite de l'utilisateur. Le verrou se lèvera après validation. » Les fichiers de planification restent modifiables pendant cette phase, car écrire dans CLAUDE.md ou rédiger une note de conception est précisément le moyen pour l'agent de lever le verrou. C'est la génération de code qui est bloquée, pas la réflexion sur papier. Cela fonctionne de pair avec les commandes qui gèrent la phase de clarification elle-même.

Pourquoi bloquer ici ? Parce que l'erreur coûte cher et la friction est faible. Un agent qui développe la mauvaise fonctionnalité pendant vingt minutes est difficile et coûteux à corriger. Poser une question de clarification au préalable ne prend que quelques secondes. Quand la balance est aussi déséquilibrée, on automatise la règle dans le code et on n'y pense plus.

L'avertissement : safety-guard.mjs signale le danger mais ne bloque jamais

Notre hook de sécurité cible Bash et surveille les commandes shell réellement destructrices : suppressions récursives de la racine ou du dossier utilisateur, force-pushes, hard resets, suppressions de bases de données. Lorsqu'il en détecte une, il affiche un avertissement puis s'efface délibérément. Il appelle process.exit(0) avec le commentaire « avertir uniquement, ne jamais bloquer ».

La logique est inscrite dans l'en-tête même du fichier : il avertit sans bloquer car « un kit qui bloque complètement vos commandes finit par être désinstallé ». Ce n'est pas un compromis, c'est la bonne décision. Les commandes shell sont le lieu où l'agent effectue un travail réel, varié et légitime. Bloquez-les de manière stricte, et chaque faux positif devient un mur entre le développeur et sa propre machine. L'avertissement joue son rôle utile (« vouliez-vous vraiment faire cela, et avez-vous créé un point de sauvegarde ? ») sans jamais vous confisquer les clés.

La règle : bloquer là où l'erreur coûte cher et la friction est faible

C'est toute la philosophie de notre approche, et c'est pourquoi les deux hooks fonctionnent à l'opposé. Bloquer les modifications de fichiers avant confirmation de l'objectif est facile à accepter et évite des corrections coûteuses : c'est donc un refus strict. Bloquer les commandes shell serait trop contraignant et se déclencherait constamment sur du travail légitime : c'est donc un simple avertissement. Même événement, verdicts opposés, arbitrés en comparant le coût de l'erreur à la friction de la bonne pratique.

De plus, les deux hooks échouent en mode ouvert. À la moindre erreur, ils restent silencieux et laissent passer l'appel. Une fonctionnalité d'accompagnement qui fait planter votre session est pire que pas de fonctionnalité du tout : si le hook échoue, il autorise. C'est un véritable principe de conception, pas une simple réflexion après coup : le filet de sécurité ne doit jamais devenir ce qui vous met en échec.

Cette gestion des autorisations est-elle vraiment rentable ?

Dans notre benchmark en environnement isolé, oui, même s'il y a des pertes bien réelles. Le verrou de clarté a forcé le kit à demander confirmation avant de générer du code sur 5 tâches sur 5, de manière systématique, contre 2 sur 5 pour Claude Code brut, où la demande dépendait de l'humeur du modèle. Le volume de code généré a été réduit d'environ 40 % pour un résultat identique. C'est là que le refus déterministe prouve son utilité.

Les pertes sont réelles et nous ne les cachons pas, c'est une règle d'or chez nous. Sur une tâche d'application de type todo-list déjà claire, le kit s'est révélé environ deux fois plus lent et 75 % plus cher pour un résultat quasi identique, car la phase de clarification est une pure perte de temps lorsque la consigne de départ était déjà limpide. Sur l'ensemble des tests, les jetons de contexte des hooks ont entraîné un surcoût moyen d'environ 25 %. Une politique d'autorisation n'est pas gratuite. C'est un compromis, et ce compromis n'est avantageux que si ce que vous protégez coûte réellement plus cher que la protection elle-même.

Questions fréquentes

Dois-je utiliser --dangerously-skip-permissions dans Claude Code ? Uniquement dans un bac à sable jetable que vous pouvez détruire. Cette option supprime toutes les demandes sans apporter le moindre discernement : un mauvais rm ou un force-push s'exécutera sans aucun obstacle. Dans un vrai dépôt, gérez plutôt les autorisations avec un hook PreToolUse : bloquez les rares actions à coût élevé, avertissez sur les autres, et autorisez tout le reste.

Un hook Claude Code peut-il refuser un appel d'outil ? Oui. Un hook PreToolUse peut renvoyer du JSON avec hookSpecificOutput.permissionDecision défini sur deny, et Claude Code refusera l'appel d'outil avant son exécution. Cela transforme une règle d'autorisation en code, appliqué de manière déterministe à chaque appel correspondant, plutôt qu'en une simple ligne dans un fichier Markdown que l'agent pourrait ignorer.

Comment fonctionnent concrètement les autorisations de Claude Code ? Chaque appel d'outil passe par PreToolUse avant de s'exécuter. Un hook associé à un outil peut renvoyer allow, deny ou ask. L'autorisation est donc une politique à laquelle votre code répond à chaque appel, et non une liste statique. Vous associez un hook à un outil par son nom, lisez l'entrée de l'outil depuis stdin, puis décidez.