Les permissions

Le principe

Une permission, c'est l'accord que Claude doit obtenir avant d'agir sur ta machine : modifier un fichier, lancer une commande, pousser du code. Lire ton code ne demande rien.

Le problème pratique est connu. En mode manuel, Claude demande confirmation pour chaque commande, même banale. Typecheck ? Confirmation. Lint ? Confirmation. Après 50 clics en une heure, tu valides sans lire, ce qui revient à ne plus rien contrôler. Anthropic l'a mesuré : les utilisateurs de Claude Code approuvent 97 % des demandes de permission.

Deux réponses existent : laisser un classifieur trier à ta place (l'auto mode), et écrire tes propres règles (allowlist et deny list). Les deux se combinent.

Les modes de permission

Le plan mode est détaillé au chapitre 5. La doc liste deux autres modes, moins visibles :

• acceptEdits : Claude crée et modifie les fichiers du projet sans demander, ainsi que quelques commandes de fichiers courantes (mkdir, touch, mv, cp, rm, sed) dans ton dossier de travail. Le reste des commandes demande toujours. Pratique si tu préfères relire les changements après coup dans git diff.
• dontAsk : tout ce qui demanderait une confirmation est refusé d'office. Seuls passent les lectures et ce que tu as pré-autorisé. Il n'apparaît pas dans Shift+Tab, on le lance avec claude --permission-mode dontAsk. Il est fait pour la CI et les scripts, où personne n'est là pour répondre.

Shift+Tab fait défiler manuel, accept edits, plan, puis auto quand il est disponible. Changer de mode ne casse pas le cache (la partie de la conversation déjà traitée, que le modèle relit pour presque rien). Seule exception : le réglage de modèle opusplan, qui change de modèle en entrant et en sortant du plan mode.

L'auto mode

Depuis le 14 août 2026, c'est le mode de départ des nouvelles sessions Pro, Max et Team. Depuis fin septembre 2026 (v2.1.283), c'est aussi le cas sur tous les plans et fournisseurs, pour les sessions interactives dans le terminal et dans VS Code, tant que tu n'as pas fixé un autre mode toi-même. Il faut un modèle récent : Opus 4.6 ou plus récent, Sonnet 4.6 ou plus récent, Haiku 5.5, ou un modèle Fable.

Ce qu'il laisse passer, ce qu'il bloque

Ce qui passe sans te déranger : les opérations sur les fichiers de ton dossier de travail, l'installation des dépendances déclarées dans tes fichiers de lock, les requêtes HTTP en lecture, un push sur une branche du repo où tu travailles.

Ce qui est bloqué par défaut, entre autres : curl | bash, les déploiements et migrations en production, le force push, git reset --hard, terraform destroy, l'envoi de données sensibles vers l'extérieur, la suppression de fichiers qui existaient avant la session. claude auto-mode defaults affiche la liste complète.

Tes allow rules continuent de s'appliquer avant le classifieur. Sauf celles assez larges pour lancer n'importe quel code, comme Bash(python:*) : l'auto mode les met de côté tant qu'il est actif.

Quand il bloque

Une action bloquée apparaît dans /permissions, onglet Recently denied. Appuie sur r pour la relancer avec ton accord manuel.

Un "vas-y, je confirme" tapé dans le chat ne débloque rien. Pour que le classifieur prenne ton accord en compte, ton message doit nommer l'action précise et sa cible : "force-push la branche feature/login" lève le blocage, "tu peux force-push" ne le lève pas. Et cet accord ne vaut que pour cette action-là. Certaines règles ne cèdent jamais à un accord écrit (plus bas, hard_deny).

Si le classifieur bloque 3 fois de suite, ou 20 fois sur la session, l'auto mode se met en pause et Claude Code recommence à te demander. Ces seuils ne se règlent pas.

Le régler

• /permissions, onglet Auto mode : pour voir et ajuster ce que le classifieur laisse passer, sans ouvrir de fichier. Les changements sont enregistrés dans ~/.claude/settings.json.
• La section autoMode de ~/.claude/settings.json accepte trois listes de règles écrites en langage courant : allow (exceptions à autoriser), soft_deny (blocages qu'un accord explicite peut lever) et hard_deny (blocages absolus). Ajoute toujours "$defaults" dans la liste, sinon tu remplaces les règles intégrées au lieu de les compléter.
• claude auto-mode critique relit tes règles perso et signale celles qui sont floues ou redondantes. claude auto-mode reset remet tout à zéro si tu t'es perdu.

{
  "autoMode": {
    "allow": [
      "$defaults",
      "Lancer les migrations Supabase sur la base locale est autorisé"
    ],
    "hard_deny": ["$defaults", "Ne jamais lancer supabase db reset"]
  }
}

Le classifieur ne lit pas autoMode dans les fichiers du projet (.claude/settings.json ou .claude/settings.local.json). C'est voulu : un repo cloné pourrait sinon s'auto-autoriser. Même chose pour le mode par défaut : "defaultMode": "auto" ne marche que dans ~/.claude/settings.json.

{
  "permissions": {
    "defaultMode": "auto"
  }
}

Ton CLAUDE.md, lui, est lu par le classifieur. Une consigne comme "ne jamais force push" y oriente à la fois Claude et le classifieur.

Pré-autoriser les commandes sûres

En mode manuel, ou pour que l'auto mode n'ait même pas à se poser la question, liste les commandes répétitives et sans risque.

Le raccourci : /fewer-permission-prompts

Lance /fewer-permission-prompts. Claude parcourt tes sessions passées, repère les commandes en lecture seule que tu valides tout le temps, et propose une allowlist classée par priorité dans le .claude/settings.json du projet. Tu relis, tu valides.

À la main

Crée .claude/settings.local.json à la racine de ton projet (version perso, non partagée avec l'équipe). C'est aussi là que Claude Code enregistre tes "Oui, et ne plus demander" :

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(npx supabase *)",
      "Bash(npx vitest *)",
      "Bash(git add *)",
      "Bash(git commit *)"
    ]
  }
}

Inutile d'ajouter git status, git diff ou git log, ni ls, cat, grep : Claude Code les reconnaît comme commandes en lecture seule et les lance sans demander, dans tous les modes.

Ce qui continue de demander confirmation en mode manuel : git push, npm install, les suppressions de fichiers et toute commande inconnue.

La deny list

La deny list bloque des commandes dans tous les modes, même en bypass, même si Claude pense que c'est nécessaire. Mets-la dans ~/.claude/settings.json (global, pour tous tes projets) :

{
  "permissions": {
    "deny": [
      "Bash(rm -rf *)",
      "Bash(sudo *)",
      "Bash(supabase db reset *)",
      "Bash(git push --force *)",
      "Bash(git push -f *)",
      "Bash(git reset --hard *)",
      "Bash(git clean -f *)"
    ]
  }
}

Une limite à connaître : une règle Bash compare le texte de la commande telle que Claude l'écrit. Bash(rm *) arrête rm -rf build/, pas /bin/rm -rf build/ ni bash -c 'rm -rf build/'. Elle attrape le cas courant, rien de plus.

Allow vs deny :

• allow (.claude/settings.local.json du projet) : commandes autorisées sans confirmation
• deny (~/.claude/settings.json global) : commandes interdites partout, dans tous les modes

Le bypass

Le bypass (lancé avec claude --dangerously-skip-permissions) supprime presque toute demande. La deny list bloque toujours. Quelques cas te redemandent quand même : tes règles ask, et une suppression qui vise / ou ton dossier perso (rm -rf ~).

Hooks 101

Les événements les plus utiles

Ce ne sont pas tous les événements : la doc officielle des hooks tient la liste complète. Un hook peut aussi appeler directement un outil MCP (type mcp_tool) au lieu d'une commande shell.

Exemple 1 : Prettier automatique après chaque Edit

Claude Code passe au hook les détails de l'action en JSON sur l'entrée standard. Pour un Edit ou un Write, le chemin absolu du fichier est dans tool_input.file_path. Ici, jq (à installer si tu ne l'as pas) l'extrait, puis Prettier formate le fichier. Le -I {} de xargs garde le chemin intact s'il contient des espaces.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.file_path' | xargs -I {} npx prettier --write {}"
          }
        ]
      }
    ]
  }
}

Exemple 2 : charger ton index perso au lancement

Au démarrage de chaque session, le hook affiche ton fichier d'index (notes, règles projet), et Claude Code ajoute ce texte au contexte. Tu n'as plus à lui répéter le contexte.

{
  "hooks": {
    "SessionStart": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "cat ~/Claude\\ OS/brain/INDEX.md"
          }
        ]
      }
    ]
  }
}

Attention au coût : tout ce que ce hook affiche entre dans le contexte de chaque session. Un index de 30 lignes, oui. Un fichier de 2 000 lignes, non. Le chapitre 19 explique pourquoi.

Où mettre la config

• ~/.claude/settings.json : hooks appliqués à tous tes projets
• .claude/settings.json à la racine d'un projet : hooks propres à ce projet (linter custom, règles d'équipe)

Sources

• Modes de permission, documentation Claude Code
• Configurer l'auto mode
• Règles de permission
• Hooks, documentation Claude Code
• Auto mode par défaut, annonce Anthropic du 7 août 2026