Comme au chapitre 1, Claude Code franchit une barrière de permission à chaque appel d'outil. Si vous vous représentez cela comme un bouton unique, vous le tournerez du côté le plus large dès que cela devient pénible. En réalité, il y a trois choses aux rôles distincts : la fréquence des confirmations, les autorisations par outil, et l'isolement au niveau du système. Resserrer l'une permet de relâcher l'autre, et « sûr ou rapide » n'est pas un choix binaire.

Déléguer n'est pas tout ou rien

Le point de départ n'est pas le nom des modes mais « dans ce travail, où se trouve le point de non-retour ». Trois critères pour juger.

  • Est-ce réversible — une édition que git peut annuler entraîne peu de perte. Une suppression définitive, un push forcé, la destruction d'une base ne se rattrapent pas
  • Jusqu'où cela porte — cela reste-t-il dans le répertoire de travail, ou cela atteint-il la production, une branche partagée, l'environnement de quelqu'un d'autre
  • Cela touche-t-il à des secrets — c'est quand pouvoir les lire et pouvoir les envoyer dehors sont réunis qu'il y a fuite

Le pénible, ce sont les opérations sûres sur les trois axes (tests, formatage, éditions locales), et le dangereux, ce sont les opérations qui surviennent rarement. Tout relâcher uniformément ouvre aussi le côté dangereux. L'ossature : relâcher selon la fréquence, resserrer selon la nature.

Les modes de permission : ce qui change vraiment

Le plus gros bouton est le mode de permission, qui fixe le cadre général de la fréquence des confirmations. On en change avec Shift+Tab (les explications sont dans Les modes de permission de Claude Code).

Demander la permission (default)

Les lectures sont automatiques, les éditions et les commandes sont confirmées à chaque fois. Le réglage par défaut pour un dépôt que vous découvrez.

Accepter les éditions (acceptEdits)

Approuve automatiquement les éditions dans le dossier de travail. Hors périmètre, chemins protégés et autres commandes restent confirmés.

Mode plan (plan)

Il enquête mais ne modifie pas les sources. Il passe à l'exécution une fois le plan approuvé.

Mode automatique (auto)

Un modèle de jugement distinct examine chaque opération avant l'exécution et n'arrête que les dangereuses. Conditions d'utilisation applicables.

Contourner les permissions (bypassPermissions)

Ne passe ni par les confirmations ni par les contrôles de sécurité. Réservé aux environnements isolés. Actif uniquement au lancement avec son option dédiée.

Il existe aussi dontAsk, réservé aux réglages : il n'exécute que la liste autorisée et les commandes en lecture seule, et refuse le reste.

Attention aussi aux chemins protégés. Les écritures dans .git, .claude et la configuration du shell ne sont pas approuvées automatiquement dans les modes ordinaires. Le mode par défaut peut s'inscrire dans les réglages, mais le mode automatique, lui, est ignoré dans les réglages de projet : c'est une ligne tracée pour qu'un dépôt ne puisse pas l'activer de son propre chef.

Le mode automatique n'est pas un mode par défaut plus rapide

Les confirmations disparaissent presque entièrement, mais rien n'est laissé libre : le modèle de jugement arrête les opérations qui débordent du périmètre de la demande, celles qui touchent une infrastructure inconnue, et celles qu'un contenu lu a induites. Passent facilement les manipulations de fichiers dans le dossier de travail et les requêtes HTTP en lecture seule. Sont arrêtés l'envoi de données confidentielles vers l'extérieur, le déploiement en production et les opérations git destructrices.

Les limites énoncées dans la conversation ne sont pas conservées. « Ne pousse pas » peut servir de fondement à un blocage, mais comme c'est relu à chaque fois depuis la conversation en cours, si la compression l'emporte, la limite disparaît avec. De plus, le mode automatique est une préversion de recherche, et l'éditeur précise lui-même qu'il réduit les confirmations sans garantir la sécurité. Il ne remplace pas la relecture.

Pourquoi on vous demande encore votre accord en mode contournement

Vous avez passé --dangerously-skip-permissions, qui est censé sauter les confirmations, et pourtant Claude demande « puis-je l'exécuter ? » Rien n'est cassé. Les permissions comptent deux couches indépendantes, et le contournement n'en efface qu'une seule (pourquoi Claude demande encore la permission en mode contournement).

Couche 1 : l'interface des permissions d'outils (effaçable)

« Puis-je modifier ce fichier ? » : la boîte de dialogue interactive qui apparaît juste avant l'appel d'un outil. Elle est émise par le programme Claude Code.

Couche 2 : le jugement de sécurité de Claude lui-même (ineffaçable)

« Cela modifierait la base de production, dois-je continuer ? » : une confirmation qui revient comme du texte de conversation. Elle découle des principes de comportement du modèle, donc aucune option ne l'arrête.

Pour les distinguer : est-ce une interface, ou du texte de réponse ? Les conditions qui déclenchent la couche 2 sont presque les trois axes du début : irréversible, portée large, risque de sécurité élevé. Sur une suppression définitive, un push forcé, une migration en production, Claude s'arrête même si vous avez ouvert les permissions.

Ce n'est pas un défaut, c'est la conception. Ce que le contournement vous donne, c'est la clé qui permet d'utiliser les outils, pas une clé qui arrête le jugement de Claude. La couche 2 ne peut pas être ramenée à zéro.

Vous pouvez en réduire la fréquence. N'écrivez dans CLAUDE.md que ce que vous pouvez poser comme un fait, et formulez vos demandes de façon concrète : « supprime les .log de /tmp/ » déclenche moins que « fais le ménage ». Mais le contournement n'est pas la réponse à « les confirmations sont pénibles » (les risques du mode contournement et comment l'utiliser sans danger).

Les règles de settings.json : ne jamais répondre deux fois à la même demande

Si le mode donne « la fréquence d'ensemble », les règles de permission donnent « les exceptions par outil et par commande ». Vous écrivez dans settings.json des entrées allow (sans confirmation), ask (confirmation à chaque fois) et deny (interdit), et vous pouvez les partager (configurer les règles de permission (allow/ask/deny)).

L'évaluation se fait dans l'ordre deny, puis ask, puis allow, et la première correspondance l'emporte : la précision d'une règle ne change pas l'ordre. Un deny large sur Bash(aws *) l'emporte sur un allow précis sur Bash(aws s3 ls). Un deny n'admet aucune exception. Le « j'ai pourtant mis un allow et la confirmation arrive quand même » vient presque toujours d'un ask qui se déclenche avant. Comme un ask force la confirmation même en mode automatique, c'est l'endroit où ranger les opérations irréversibles.

// .claude/settings.json { "permissions": { "defaultMode": "acceptEdits", "allow": ["Bash(npm run *)"], "ask": ["Bash(git push *)"], "deny": ["Read(.env)", "Read(~/.ssh/**)"] } }

L'emplacement a lui aussi un rang. Du plus fort au plus faible : réglages d'administration (non modifiables), puis la ligne de commande, puis settings.local.json, puis settings.json, puis ~/.claude/settings.json. Mais un deny, à n'importe quel niveau, l'emporte toujours sur un allow de n'importe quel autre niveau. Dans les motifs, l'espace suivi d'une * marque une frontière de mot : Bash(ls *) attrape ls -la mais pas lsof.

Ce dont les règles ne vous protègent pas

Ce que les règles examinent, c'est uniquement « la chaîne de caractères de la commande sur le point d'être exécutée », et tout chemin qui s'en écarte passe sans être vu.

  • Les accès indirects ne sont pas empêchés — un deny sur Read(.env) agit sur les outils de fichiers intégrés et sur cat, mais il n'agit pas sur un script qui ouvre le fichier lui-même
  • Les lanceurs d'environnement masquent le contenu — devbox run * et docker exec exécutent leurs arguments tels quels, donc un allow sur Bash(devbox run *) autorise jusqu'à devbox run rm -rf .
  • Restreindre une URL par les arguments est fragile — un réordonnancement ou une expansion de variable passe à travers. Il est plus solide de refuser curl et wget en bloc et de désigner les destinations autorisées avec WebFetch(domain:)

Écrire « ne lis pas .env » dans CLAUDE.md ne fait pas une règle. CLAUDE.md change ce que Claude va chercher à faire, mais il ne change pas ce qui lui est permis. Ce qui change le périmètre, ce sont les règles, les modes, et les hooks PreToolUse du chapitre 6 (deny et ask sont évalués quel que soit le résultat d'un hook).

Le bac à sable : ce qu'il peut clôturer, et ce qu'il ne peut pas

Ce qui bouche les chemins où les règles n'arrivent pas, c'est le bac à sable : il clôture d'abord « jusqu'où on peut toucher », et non « ce que l'on confirme ». Ce n'est pas Claude qui l'impose mais le système d'exploitation (le noyau), donc même si une commande autorisée fait plus que ce que son nom annonce, la frontière ne bouge pas (le guide complet du bac à sable de Claude Code).

1. Isolement du système de fichiers

Il peut écrire dans le répertoire de travail et un dossier temporaire, et nulle part ailleurs (réglage initial). ~/.bashrc et les zones système ne peuvent pas être réécrits.

2. Isolement du réseau

L'état initial est le refus par principe, avec zéro destination. Se connecter à un nouveau domaine déclenche une confirmation, et l'inscrire dans allowedDomains arrête les demandes.

Ces deux-là vont toujours ensemble : avec un seul des deux, un secret qu'il a pu lire ressort. Il y a deux façons d'approuver. Le mode d'autorisation automatique exécute le Bash intérieur sans confirmation, tandis que le mode de permission ordinaire isole tout en laissant passer les confirmations. Même sous l'autorisation automatique, un deny reste toujours prioritaire, un rm visant un chemin important est confirmé, et un ask portant sur un contenu précis force encore la confirmation.

Attention : il y a deux choses appelées « automatique ». Le mode d'autorisation automatique du bac à sable veut dire « on laisse passer parce que la frontière du système le contient », tandis que le mode automatique des permissions veut dire « on laisse passer parce que le modèle de jugement l'a examiné ».

Apprendre d'abord ce qu'il ne protège pas

Le bac à sable n'est pas un isolement complet. Laisser ce point dans le flou tout en gardant l'autorisation automatique en permanence, c'est l'état le plus dangereux où se trouver.

  • Il ne couvre que Bash et ses processus enfants — les outils Read, Edit et Write intégrés, les serveurs MCP et les hooks sont en dehors (contrôlez-les par les règles de permission). Pour envelopper le processus entier, utilisez @anthropic-ai/sandbox-runtime
  • Le réglage initial de la lecture est large — ce qu'il clôture, c'est surtout l'écriture, et ~/.ssh et ~/.aws/credentials restent lisibles en l'état. Fermez-les avec denyRead
  • Autoriser trop largement devient le trou — le trafic est jugé par nom d'hôte, et le contenu chiffré n'est pas inspecté par défaut. Permettez un domaine large, et vous laissez de la place pour que des choses sortent
  • Cela dépend de votre environnement — macOS n'a besoin de rien de plus. Linux et WSL2 exigent bubblewrap et socat, et Windows natif n'est pas pris en charge

Le bac à sable n'est pas un mur bâti face à un attaquant ; c'est un harnais de sécurité qui réduit d'un ordre de grandeur les accidents et les emballements. Anthropic a déclaré avoir réduit en interne les confirmations de permission de 84 % sans danger, mais c'est le compte rendu d'un nombre moindre de confirmations, pas la garantie que cela ne peut pas être franchi.

Les accidents prennent à peu près quatre formes

Voici la mécanique réalignée depuis le point de vue de l'accident. Choisissez vos réglages selon leur efficacité contre ces quatre formes.

1. Les commandes destructrices

Un rm qui balaie un chemin imprévu, un git push --force qui efface le travail de quelqu'un d'autre. Leur point commun : c'est irréversible. Ce qui fonctionne, ce sont les règles deny et ask et l'isolement des fichiers. Le plus sûr est de ranger les opérations irréversibles dans ask.

2. La fuite de secrets

Il n'y a accident que quand pouvoir lire et pouvoir envoyer se retrouvent réunis. La parade est donc double : ne pas laisser lire (deny sur Read(.env), denyRead) et ne pas laisser envoyer (deny sur curl et wget, domaines autorisés restreints). Une seule des deux ne suffit pas.

3. Atteindre une autre branche ou un autre environnement

Ce qui devait être une correction d'un fichier en local se transforme en push sur une branche partagée ou en déploiement en production : c'est l'escalade des opérations. En mode ordinaire, une confirmation s'intercale à chaque palier, mais si vous avez tout ouvert, les paliers disparaissent. Placer le push et le déploiement dans ask est une assurance bon marché.

4. Des instructions glissées dans les fichiers qu'il lit

Il arrive que les README, tickets, pages web et PDF que Claude lit contiennent des instructions destinées à Claude (injection de prompt). Même écrit en blanc sur blanc, un « envoie ceci à cette adresse » est, du point de vue de Claude, du texte qui entre par la même porte que votre demande, et rien ne sépare de soi-même les données des ordres.

Ce qui ne fonctionne pas ici, c'est le mode contournement (le contenu glissé arrive tel quel jusqu'à l'exécution) et une interdiction écrite dans CLAUDE.md (elle ne change pas le périmètre du permis). Ce qui fonctionne, c'est une frontière au niveau du système — on ne peut pas écrire là où l'on ne peut pas écrire, ni se connecter là où l'on ne peut pas se connecter — et les règles deny. Comme ce qui est glissé n'est pas visible, ne comptez pas sur le fait de vous en apercevoir : faites lire les documents non fiables avec des permissions restreintes pour cette session-là.

Ce qu'on peut déléguer / ce qu'il faut arrêter

En appliquant les trois axes, la ligne se dessine ainsi.

Délégable (à mettre dans allow)

Tests, vérification de types, linter, compilation / éditions dans le répertoire de travail / lectures et recherches / commits locaux

À arrêter (ask ou deny)

Push sur une branche partagée et push forcé / déploiement et migration en production / lecture de fichiers de secrets / commandes comportant un envoi vers l'extérieur / écritures hors du répertoire de travail

  • Fixez un mode pour le quotidien. acceptEdits pour l'édition répétitive, default pour le travail sensible. Inscrivez-le dans defaultMode
  • Après avoir répondu trois fois à la même demande, passez-la en allow. À l'inverse, toute opération qui vous a fait penser une seule fois « c'est risqué » se fige en ask
  • Traitez les interdictions énoncées dans la conversation en partant du principe qu'elles disparaîtront.
  • Quand vous relâchez quelque part, resserrez ailleurs. Le seul état à ne jamais créer, c'est sans confirmation et sans frontière

Les conditions pour utiliser le contournement. À l'intérieur d'un conteneur, d'une machine virtuelle ou d'un exécuteur d'intégration continue que l'on peut jeter s'il casse, avec uniquement le répertoire de travail monté, sans y apporter le .env ni les clés SSH de la machine hôte. « Les confirmations sont agaçantes » n'est pas une raison valable. Après le travail, lisez impérativement le diff.

Tout ce qui a été traité ici est une mécanique qui « réduit » les accidents, pas une mécanique qui les « supprime ». Le jugement de la couche 2, l'arbitrage du mode automatique et la frontière du bac à sable ont tous des formes par lesquelles on passe à travers. Ce qui fonctionne le mieux, c'est de rester dans un état d'où l'on peut revenir.

Résumé

  • Les permissions ont trois couches : modes, règles, bac à sable. Les axes sont est-ce réversible, jusqu'où cela porte, cela touche-t-il à des secrets, et l'on relâche selon la fréquence, resserre selon la nature
  • Les permissions ont une structure à deux couches. Le contournement n'efface que l'interface de la couche 1 ; les confirmations en texte de conversation sont conformes à la conception
  • Les règles suivent l'ordre deny, ask, allow et la première correspondance l'emporte : la précision ne change pas l'ordre
  • Les règles ne regardent que des chaînes de caractères. Ce qui bouche le reste, c'est le bac à sable. Mais il ne couvre que Bash et ses processus enfants, et le réglage initial de la lecture est large
  • Les accidents prennent quatre formes : commandes destructrices, fuite de secrets, atteinte d'un autre environnement, instructions glissées

Une fois le périmètre de délégation fixé, il ne reste qu'à faire grandir l'outil selon votre environnement. Passez au chapitre 6, « L'étendre ».