Aller au contenu principal

Permissions et 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 à un motif
  • Les six modes de permission et quand utiliser chacun
  • Pourquoi le mode auto est désormais le mode de démarrage des sessions interactives — et comment s'en désinscrire
  • Comment le mode auto remplace les confirmations par un classifieur de sécurité
  • Comment construire une allowlist de départ raisonnable qui réduit les confirmations sans perdre en sécurité
  • Où stocker les règles de permission du projet et les règles personnelles

Les permissions décident de ce que Claude Code peut faire sans s'arrêter pour vous demander. Bien réglées, elles vous donnent de la fluidité sans perte de contrôle ; mal réglées, vous validez tout à l'aveugle ou vous croulez sous les confirmations.

Les trois verdicts​

Chaque action possible aboutit à l'un de ces verdicts :

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 à un motif, par exemple allow Bash(npm run test:*) ou deny Read(./.env).

Autoriser un outil + un motif

Bash(npm run test:*)

Refuser un outil + un motif

Read(./.env)

Modes de permission​

Un mode définit la posture générale d'une session. Il y en a six. Parcourez les plus courants avec Shift+Tab, ou définissez permissions.defaultMode dans les paramètres.

ModeS'exécute sans demanderÀ utiliser quand
default (affiché Manual)Lectures uniquementTravail quotidien, modifications sensibles
acceptEditsLectures, modifications de fichiers, commandes courantes du système de fichiersUne session d'édition de confiance et bien délimitée
planLectures, plus les commandes approuvées par le classifieur quand le mode auto est disponible ; ne modifie jamais votre code sourceTâches importantes ou risquées — voir Plan Mode
auto (le mode de démarrage des sessions interactives depuis la v2.1.283)Tout, filtré par un classifieur de sécuritéLongues tâches où la lassitude des confirmations est le vrai risque
dontAskLectures de fichiers dans vos répertoires de travail et outils pré-approuvés ; tout ce qui demanderait une confirmation est refuséCI et scripts verrouillés
bypassPermissionsTout, sans aucun contrôleBacs à sable/conteneurs uniquement — jamais sur une machine contenant des secrets

Le mode auto est désormais le mode par défaut de Claude Code​

Depuis Claude Code v2.1.283, auto est le mode de démarrage intégré des sessions interactives en terminal et dans VS Code sur tous les forfaits et chez tous les fournisseurs. Dans les versions antérieures, il n'était le mode par défaut des nouvelles sessions que sur les forfaits Pro, Max et Team, à partir du 14 août 2026. Justification d'Anthropic (issue de ses propres tests auprès de plus de 1 000 utilisateurs payants) : le classifieur a intercepté 89 % des actions nuisibles contre 13,6 % pour la revue manuelle — car, par habitude, les utilisateurs acceptaient environ 97 % des confirmations manuelles sans les lire.

Deux exceptions préservent l'intention :

  • Si vous avez défini permissions.defaultMode dans vos paramètres utilisateur, il reste en place, sauf si vous acceptez une invite de basculement ponctuelle dans l'application.
  • Si votre organisation gère le mode par défaut (paramètres gérés Team/Enterprise), rien ne change automatiquement.

Vous pouvez toujours changer de mode en cours de session avec Shift+Tab. Un changement connexe déjà en vigueur sur ces forfaits : les appels au classifieur effectués par le mode auto ne comptent plus dans vos limites d'utilisation.

Activer tôt (avant le 14 août) — définir auto comme mode par défaut

~/.claude/settings.json
{
"permissions": {
  "defaultMode": "auto"
}
}

Garder l'ancien comportement avec confirmations après le 14 août

~/.claude/settings.json
{
"permissions": {
  "defaultMode": "default"
}
}

Comment fonctionne réellement le mode auto​

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

Il bloque notamment curl | bash, les force push, les déploiements et migrations en production, rm -rf sur des variables non résolues, la falsification de la transcription, les commandes git destructrices qui écartent un travail non commité, et l'envoi de secrets vers des points de terminaison externes — tout en laissant passer le travail courant (modifications locales, installation de dépendances déclarées, HTTP en lecture seule, push sur votre propre branche). Si la même action est bloquée à répétition, le mode auto se met en pause et vous redonne la main sur les confirmations.

Le mode auto n'est pas une garantie de sécurité — il réduit les confirmations, mais ne supprime pas la nécessité de relire les opérations sensibles. Sa disponibilité dépend de votre forfait, du modèle et (sur Team/Enterprise) d'un réglage administrateur. Si vous travaillez vraiment sans surveillance (cron, sessions cloud, CI), associez-le à Hardening Autonomous Runs — auto n'est toujours pas bypassPermissions.

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

Une allowlist de départ raisonnable​

L'objectif : pré-autoriser ce qui est sûr et répétitif ; garder ce qui est destructeur en 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é) et vos surcharges personnelles dans settings.local.json.

Pro tip
  • Laissez-le apprendre de vos confirmations : approuvez la même commande sûre quelques fois et vous saurez exactement quoi ajouter à votre allowlist — pour transformer des confirmations répétées en une règle posée une fois pour toutes.
Key takeaways
  • Trois verdicts : allow (sans confirmation), ask (par défaut — pause et confirmation), deny (jamais).
  • Les règles associent un outil à un motif, comme Bash(npm run test:*) ou Read(./.env).
  • Six modes définissent la posture de la session : default (Manual), acceptEdits, plan, auto, dontAsk, bypassPermissions.
  • Depuis la v2.1.283, auto est le mode de démarrage des sessions interactives en terminal et dans VS Code sur tous les forfaits ; un defaultMode que vous avez défini reste en place, et les modes par défaut gérés par l'organisation ne sont pas touchés.
  • Le mode auto filtre chaque action avec un classifieur de sécurité au lieu de vous solliciter — c'est l'outil contre la lassitude des confirmations, pas bypassPermissions.
  • Construisez une allowlist : allow pour ce qui est sûr et répétitif, ask pour le risque moyen, deny pour le destructeur.
  • Les règles partagées vont dans settings.json ; les surcharges personnelles dans settings.local.json.

Testez-vous

0/6
  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 des bacs à sable ou des conteneurs, jamais sur une machine contenant des secrets ?
  3. Vous voulez beaucoup moins de confirmations sur une longue tâche, tout en gardant un filet de sécurité. Quel mode ?
  4. Où stocker les règles de permission partagées du projet par rapport aux surcharges personnelles ?
  5. Lequel de ces éléments a sa place dans la liste 'deny' d'une allowlist de départ raisonnable ?
  6. Le 14 août 2026, que se passe-t-il sur un forfait Pro si vous aviez déjà défini permissions.defaultMode sur 'default' dans vos paramètres utilisateur ?

Suite​