Permissions Claude Code

Problème : Claude Code qui demande une permission pour chaque modification de fichier et chaque commande te coupe dans ton élan et fait perdre du temps.

Gain rapide : appuie sur Shift+Tab pour faire défiler les modes de permission à la volée :

# Press Shift+Tab to cycle:
normal → auto-accept edits → plan mode → normal

Tu peux rebinder ça si Shift+Tab entre en conflit avec ton terminal. Tu contrôles maintenant le flux sans toucher un fichier de config. Adapte le mode à la tâche et le cycle d'interruptions s'arrête.

Tous les modes de permission

Claude Code embarque cinq modes de permission, chacun conçu pour un type de travail différent. Trois modes principaux défilent via Shift+Tab, et deux autres vivent dans la config.

Mode Normal (default)

Le mode normal demande confirmation avant toute opération potentiellement dangereuse. Tu vois des dialogues de confirmation pour :

• Les modifications et changements de fichiers
• L'exécution de commandes terminal
• Les opérations système
• Les changements de répertoire

La sécurité avant la vitesse. Utilise-le pour :

• Le code de production
• Les codebases que tu ne connais pas bien
• L'apprentissage de nouvelles techniques
• Les opérations à haut risque

Mode Auto-Accept (acceptEdits)

Le mode auto-accept supprime les invites de permission pour les modifications de fichiers pour le reste de la session. Claude exécute les opérations approuvées directement.

Active-le en appuyant sur Shift+Tab jusqu'à ce que l'UI affiche "auto-accept edit on".

Idéal pour :

• Les grosses sessions de refactoring
• Travailler selon un plan bien défini
• La recherche et le travail de documentation
• Les modifications répétitives sur de nombreux fichiers

Mode Plan (plan)

Le mode plan verrouille Claude sur des opérations en lecture seule. Claude peut analyser librement, mais rien ne change sur le disque.

Parfait pour :

• L'exploration initiale du codebase
• L'analyse d'architecture
• La planification de fonctionnalités complexes
• Les sessions de code review

Mode Don't Ask (dontAsk)

Le mode Don't Ask refuse automatiquement toute utilisation d'outil sauf si l'outil est déjà pré-approuvé via /permissions ou une règle permissions.allow. Pas d'invites. Tout ce qui n'est pas sur la liste blanche est silencieusement refusé.

Idéal pour :

• Les pipelines CI/CD sans humain pour confirmer
• Les environnements verrouillés avec un ensemble connu d'opérations autorisées
• Faire tourner Claude avec une politique de permission stricte et pré-construite

Mode Bypass Permissions (bypassPermissions)

Le mode bypass saute chaque vérification de permission. Claude exécute n'importe quel outil sans demander.

# CLI flag equivalent:
claude --dangerously-skip-permissions

Active ça uniquement dans des environnements entièrement isolés comme des conteneurs, VMs ou runners CI éphémères où Claude ne peut pas causer de dommages durables. L'intérêt du mode est l'automatisation dans des endroits où l'environnement lui-même est la frontière de sécurité.

Attention : les admins peuvent désactiver ce mode entièrement en mettant disableBypassPermissionsMode sur "disable" dans les settings gérés. Si ton organisation le bloque, ni le setting ni le flag CLI ne fonctionneront.

Définir un mode par défaut persistant

Plutôt que de faire défiler les modes à chaque session, fixe ton mode par défaut dans settings.json :

{
  "defaultMode": "acceptEdits"
}

Valeurs valides : default, acceptEdits, plan, dontAsk, bypassPermissions. La préférence persiste entre les sessions pour que tu démarres toujours où tu veux.

Gérer les permissions avec /permissions

Plutôt que d'éditer manuellement les fichiers JSON, la commande /permissions intégrée ouvre une vue interactive :

# Launch the interactive permissions UI
/permissions

De là tu peux :

• Voir quels outils sont actuellement autorisés et refusés
• Accorder l'accès à des outils ou patterns spécifiques
• Bloquer les outils que tu veux interdire
• Voir de quel fichier de settings vient chaque règle
• Faire des modifications sans redémarrer Claude Code

Syntaxe des règles de permission

Les règles suivent le format Outil ou Outil(spécificateur). Elles vivent dans l'objet permissions de ton settings.json :

{
  "permissions": {
    "allow": ["Bash(npm run *)"],
    "deny": ["Bash(rm *)"],
    "ask": ["Bash(git push *)"]
  }
}

Trois types de règles pilotent le comportement :

• Les règles Allow laissent Claude utiliser l'outil sans demander
• Les règles Ask demandent une confirmation à chaque utilisation
• Les règles Deny bloquent l'outil entièrement

Les règles s'évaluent dans l'ordre : deny d'abord, puis ask, puis allow. La première règle correspondante gagne, donc un deny bat toujours un allow.

Correspondre toutes les utilisations d'un outil

Utilise juste le nom de l'outil pour couvrir chaque invocation :

Bash(*) est identique à Bash et correspond à toutes les commandes Bash.

Patterns wildcard Bash

Les règles Bash prennent des patterns glob avec *. Les wildcards peuvent se placer n'importe où dans la règle :

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)",
      "Bash(git * main)",
      "Bash(* --version)",
      "Bash(* --help *)"
    ],
    "deny": ["Bash(git push *)"]
  }
}

Sémantique de frontière de mot : l'espace devant * compte. Bash(ls *) correspond à ls -la mais pas à lsof. Bash(ls*) correspond aux deux.

Conscience des opérateurs shell : Claude Code connaît les opérateurs shell. Une règle comme Bash(safe-cmd *) ne correspondra pas à safe-cmd && malicious-cmd. Ça stoppe l'exploitation par chaînage de commandes.

Attention : les patterns Bash qui tentent de contraindre les arguments de commande sont fragiles. Une règle comme Bash(curl http://github.com/ *) est censée limiter curl aux URL GitHub, mais elle ne captera pas les variations (options avant l'URL, protocoles différents, expansion de variables). Pour un vrai filtrage d'URL, bloque les outils réseau Bash et utilise WebFetch avec des règles de domaine.

Patterns Read et Edit

Les règles Read et Edit utilisent des patterns de chemin style gitignore, quatre types :

Important : un pattern comme /Users/alice/file n'est pas un chemin absolu. Il se résout par rapport à ton fichier settings. Utilise //Users/alice/file pour un vrai chemin absolu.

Dans les patterns gitignore, * correspond aux fichiers dans un seul répertoire tandis que ** correspond récursivement. Pour autoriser tout accès aux fichiers, enlève les parenthèses entièrement : Read, Edit ou Write.

Règles de domaine WebFetch

Contrôle depuis quels domaines Claude peut faire des requêtes :

{
  "permissions": {
    "allow": ["WebFetch(domain:docs.anthropic.com)"],
    "deny": ["WebFetch(domain:internal.company.com)"]
  }
}

Patterns d'outils MCP

Contrôle l'accès aux serveurs MCP au niveau serveur ou outil :

Règles de Task (sous-agent)

Contrôle quels sous-agents Claude peut spawner avec Task(NomAgent) :

{
  "permissions": {
    "deny": ["Task(Explore)"]
  }
}

Les noms d'agents incluent Explore, Plan et Verify. Le flag CLI --disallowedTools peut aussi désactiver des agents spécifiques au démarrage.

Étendre les permissions avec les hooks

Les hooks PreToolUse tournent avant le système de permissions et peuvent approuver, refuser ou réécrire les appels d'outils au runtime. Ça te donne un contrôle programmatique par-dessus les règles statiques.

Comment les permissions fonctionnent avec le sandboxing

Permissions et sandboxing s'empilent comme deux couches de sécurité complémentaires (défense en profondeur) :

• Les permissions contrôlent quels outils Claude peut utiliser et quels fichiers ou domaines il peut toucher. Elles s'appliquent à chaque outil (Bash, Read, Edit, WebFetch, MCP et le reste).
• Le sandboxing ajoute une application au niveau OS par-dessus, limitant ce que les commandes Bash peuvent atteindre au niveau du filesystem et du réseau. Il s'applique uniquement aux commandes Bash et leurs processus enfants.

Utilise les deux ensemble pour la posture la plus solide :

• Les règles deny de permission empêchent Claude d'essayer d'accéder à des ressources restreintes
• Les restrictions sandbox gardent les commandes Bash dans des limites définies, même quand une injection de prompt contourne la prise de décision de Claude
• Les restrictions filesystem dans le sandbox utilisent les règles deny Read et Edit (pas de config sandbox séparée)
• Les restrictions réseau mélangent les règles de permission WebFetch avec la liste allowedDomains du sandbox

Active le sandboxing avec la commande /sandbox. Sur macOS il fonctionne directement via Seatbelt. Sur Linux et WSL2, installe d'abord bubblewrap et socat.

Settings de permission gérés

Pour les orgs qui ont besoin d'un contrôle central, les admins peuvent livrer des fichiers de settings gérés que les utilisateurs et projets ne peuvent pas outrepasser :

Emplacements des fichiers de settings gérés :

• macOS : /Library/Application Support/ClaudeCode/managed-settings.json
• Linux/WSL : /etc/claude-code/managed-settings.json
• Windows : C:\Program Files\ClaudeCode\managed-settings.json

Ce sont des chemins système (pas des répertoires home utilisateur) et ils nécessitent des privilèges admin. Ils utilisent le même format que les fichiers settings normaux mais ont la priorité la plus haute dans la hiérarchie des settings.

Stratégies par scénario de développement

Début du développement (utilise le mode Normal)

Tu démarres un nouveau projet ou explores du code inconnu :

• Garde chaque permission manuelle
• Revois chaque changement suggéré
• Observe comment Claude aborde le problème
• Construis la confiance dans les décisions de l'IA

Développement actif (utilise Auto-Accept)

Dans une session de coding intensive :

• Active auto-accept pour les types de fichiers de confiance
• Autorise les commandes courantes (npm, git status)
• Garde les invites pour les opérations système
• Profite d'un workflow sans interruption

Code Review (utilise le mode Plan)

Quand tu analyses un codebase existant :

• Bascule en mode plan pour la sécurité
• Laisse Claude explorer sans toucher les fichiers
• Produis analyse et recommandations
• Change de mode seulement quand tu es prêt à implémenter

Pièges courants des permissions

Sur-permissioning : évite le mode bypassPermissions sauf si tu es dans un conteneur ou une VM entièrement isolés. Le mode dontAsk avec des règles allow explicites est l'option "mains libres" plus sûre.

Sous-permissioning : cliquer "Allow" pour la centième fois anéantit l'intérêt. Utilise /permissions pour pré-approuver les opérations répétitives, ou bascule vers acceptEdits pendant le développement actif.

Confusion de mode : vérifie ton mode courant avant de commencer le travail. L'indicateur vit dans l'UI. Définis defaultMode dans settings.json si tu veux toujours le même mode de démarrage.

Permissions globales : n'autorise pas toutes les commandes Bash. Utilise des patterns spécifiques comme Bash(npm run *) pour garder le périmètre serré. Et rappelle-toi : les règles deny battent toujours les règles allow.

Patterns d'arguments fragiles : ne compte pas sur les règles Bash pour restreindre les arguments de commande (comme fixer curl à certaines URL). Utilise les règles de domaine WebFetch pour un vrai filtrage d'URL.

La suite

Cinq modes de permission pour cinq types de travail. default pour la sécurité, acceptEdits pour la productivité, plan pour l'exploration, dontAsk pour l'automatisation, et bypassPermissions pour les environnements isolés. Choisis le mode qui correspond à la tâche, et empile le sandboxing par-dessus pour la défense en profondeur.

Lectures complémentaires :

• Automatise les appels de permission avec les hooks et le Permission Hook
• Raccourcis clavier personnalisés pour un changement de mode plus rapide
• Feedback loops pour une itération plus rapide
• Todo workflows pour le suivi des tâches
• Intégration git pour le contrôle de version
• Bases de configuration pour settings.json et une configuration plus poussée