Aller au contenu principal

Permissions & modes de permission

Intermédiaire
What you'll learn
  • Ce que signifient les trois verdicts de permission (allow / ask / deny)
  • Comment les règles de permission associent un outil et un pattern
  • Les six modes de permission et quand utiliser chacun
  • Comment le mode auto remplace les invites par un classificateur de sécurité
  • Comment bâtir une liste d'autorisations de départ saine qui réduit les invites sans perdre en sécurité
  • Où stocker les règles de permission du projet vs personnelles

Les permissions décident ce que Claude Code peut faire sans s'arrêter pour vous demander. Réglez-les bien et vous obtenez de la fluidité sans perdre le contrôle ; réglez-les mal et soit vous approuvez tout machinalement, soit vous croulez sous les invites.

Les trois verdicts​

Chaque action potentielle se résout à l'un de :

Appuyez sur Entrée ou Espace pour retourner la carte. Utilisez les flèches gauche et droite pour naviguer entre les cartes.Terme affiché.
1 / 3

Les règles associent généralement un outil et un pattern, p. ex. autoriser Bash(npm run test:*) ou refuser Read(./.env).

Autoriser un outil + pattern

Bash(npm run test:*)

Refuser un outil + pattern

Read(./.env)

Modes de permission​

Un mode fixe la posture globale d'une session. Il y en a six. Faites défiler les plus courants avec Shift+Tab, ou définissez permissions.defaultMode dans les paramètres.

ModeS'exécute sans demanderÀ utiliser quand
default (affiché comme Manual)Lectures uniquementTravail quotidien, changements sensibles
acceptEditsLectures, éditions de fichiers, commandes de système de fichiers courantesUne session d'édition de confiance et bien délimitée
planLectures uniquement ; propose, n'édite jamaisTâches grandes/risquées — voir Plan Mode
autoTout, filtré par un classificateur de sécuritéTâches longues où la fatigue des invites est le vrai risque
dontAskUniquement les outils préapprouvés ; tout le reste est refuséCI et scripts verrouillés
bypassPermissionsTout, sans aucune vérificationBacs à sable/conteneurs uniquement — jamais sur une machine avec des secrets

Mode auto​

auto est le juste milieu entre demander pour tout et désactiver la sécurité. Au lieu de vous demander, un modèle classificateur distinct examine chaque action avant son exécution et bloque tout ce qui va au-delà de ce que vous avez demandé, touche à une infrastructure qu'il ne reconnaît pas, ou semble dicté par du contenu hostile que Claude vient de lire. Les règles ask explicites continuent de s'arrêter et de vous demander.

Il bloque des choses comme curl | bash, les force push, les déploiements et migrations en production, et l'envoi de secrets vers des endpoints externes — tout en laissant passer directement le travail de routine (éditions locales, installation de dépendances déclarées, HTTP en lecture seule, push sur votre propre branche). S'il bloque la même action de façon répétée, le mode auto se met en pause et vous rend la main sur les invites.

Le mode auto n'est pas une garantie de sécurité — il réduit les invites, il ne supprime pas la nécessité de relire les opérations sensibles. Sa disponibilité dépend de votre plan, de votre modèle et (sur Team/Enterprise) d'un réglage administrateur.

Watch out
  • bypassPermissions a sa place dans un bac à sable. Tourner avec toutes les invites désactivées sur votre vraie machine, c'est ainsi qu'un agent finit par toucher quelque chose qu'il ne devrait pas. Réservez-le aux environnements jetables — si ce que vous voulez vraiment, c'est moins d'invites, utilisez plutôt le mode auto. Voir Renforcer les exécutions autonomes à /docs/security/hardening-autonomous-runs.

Une liste d'autorisations de départ saine​

Le but : préautoriser les choses sûres et répétitives ; garder les choses destructives sur ask ou deny.

Guided walkthrough1 of 3
  1. Lire des fichiers, lancer vos commandes de test/lint/build, git status/diff.

Stockez les règles du projet dans settings.json (partagées) et les surcharges personnelles dans settings.local.json.

Pro tip
  • Laissez-le apprendre de vos invites : approuvez la même commande sûre quelques fois et vous saurez exactement quoi ajouter à votre liste d'autorisations — transformant des invites répétées en une règle unique.
Key takeaways
  • Trois verdicts : allow (sans invite), ask (défaut — pause et confirmation), deny (jamais).
  • Les règles associent un outil et un pattern, comme Bash(npm run test:*) ou Read(./.env).
  • Six modes fixent la posture de session : default (Manual), acceptEdits, plan, auto, dontAsk, bypassPermissions.
  • Le mode auto filtre chaque action via un classificateur de sécurité au lieu de vous demander — c'est l'outil contre la fatigue des invites, pas bypassPermissions.
  • Bâtissez une liste d'autorisations : autorisez le sûr + répétitif, demandez pour le risque moyen, refusez le destructif.
  • Les règles partagées vont dans settings.json ; les surcharges personnelles dans settings.local.json.

Testez-vous

0/5
  1. Que fait le verdict par défaut 'ask' pour une action qui n'est ni explicitement autorisée ni refusée ?
  2. Quel mode de permission n'est sûr QUE dans les bacs à sable ou les conteneurs, jamais sur une machine avec des secrets ?
  3. Vous voulez beaucoup moins d'invites de permission sur une tâche longue, mais vous voulez tout de même un filet de sécurité. Quel mode ?
  4. Où faut-il stocker les règles de permission partagées du projet par rapport aux surcharges personnelles ?
  5. Lequel de ceux-ci appartient à la liste 'deny' dans une liste d'autorisations de départ saine ?

La suite​