🎯

Ce chapitre t'explique comment fonctionne le système de permissions de Claude Code, ce qu'il peut faire seul et ce qui nécessite ton accord. Tu gardes toujours le contrôle. Temps de lecture : 5 minutes.

Claude demande toujours avant d'agir

Claude Code ne fera jamais quelque chose de risqué sans te demander explicitement. C'est une règle de sécurité fondamentale.

Mais il y a un problème pratique : par défaut, il demande confirmation pour chaque commande, même les plus banales. Lancer un typecheck ? Confirmation. Lancer le lint ? Confirmation. Lire un fichier ? Confirmation. Après 50 confirmations en 1 heure, tu deviens fou.

La solution : pré-autoriser les commandes sûres tout en gardant la validation pour les actions risquées.

Les 3 niveaux de risque

🟢

Sûr, automatique

Claude fait ça librement, sans rien te demander :

Lire des fichiers
Naviguer dans le code
Analyser le projet
Chercher des patterns dans le code

🟡

Modéré, demande confirmation

Claude te montre ce qu'il va faire et attend ton OK :

Modifier des fichiers
Installer des packages
Exécuter des commandes (tests, build, migrations)
Créer de nouveaux fichiers

🔴

Risqué, toujours demandé

Claude explique en détail et attend ta validation explicite :

Pousser du code sur GitHub (git push)
Supprimer des fichiers ou des branches
Actions irréversibles (reset de base de données, etc.)
Commandes inconnues ou inhabituelles

Pré-autoriser les commandes sûres

Pour éviter de cliquer "Oui" 50 fois par session, crée un fichier de configuration qui autorise automatiquement les commandes répétitives et sans risque.

Créer le fichier

Crée le fichier .claude/settings.local.json à la racine de ton projet :

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

💡

Syntaxe wildcard : utilise * comme joker. Bash(npm run *) autorise npm run dev, npm run build, npm run test, etc. en une seule règle. Pas besoin de lister chaque variante.

Ce que ça autorise

Commande	Pourquoi c'est sûr
`npm run typecheck`	Vérifie les types, ne modifie rien
`npm run lint`	Vérifie le style, ne modifie rien
`npm run test`	Lance les tests, ne modifie rien
`npm run build`	Compile l'app, ne modifie pas le code source
`npx supabase`	Commandes Supabase locales
`git status/diff/log`	Lecture seule de l'état Git
`git add/commit`	Sauvegarde locale (pas de push)

Ce qui continue de demander confirmation

git push (envoyer du code en ligne)
npm install (ajouter des dépendances)
Suppression de fichiers
Commandes inconnues

Le mode trust

Si tu es en session de développement intensif et que tu fais totalement confiance à Claude, tu peux passer en mode "trust" depuis l'interface. Claude ne demandera plus de confirmation pour rien.

⚠️

Attention : le mode trust est puissant mais risqué. Utilise-le seulement quand tu sais exactement ce que Claude va faire (ex: exécuter un plan que tu as validé). Ne le laisse pas activé en permanence.

L'expérience au quotidien

Avec un fichier de permissions bien configuré, voici ce que ça donne en pratique :

Claude écrit du code → tu vois les fichiers se modifier en temps réel dans VS Code
Claude lance typecheck → passe automatiquement, pas de confirmation
Claude lance lint → passe automatiquement
Claude veut installer un package → te demande "Installer framer-motion ?" → tu valides
Claude veut commiter → passe automatiquement avec le bon message
Claude veut pusher → te demande "Pousser sur la branche feat/streak ?" → tu valides

Le résultat : tu ne cliques que sur les décisions qui comptent vraiment.

Le filet de sécurité : la deny list

Plus puissant que l'allowlist : la deny list (liste noire). Elle bloque des commandes dangereuses même en mode trust total. C'est ton garde-fou ultime.

Dans ton ~/.claude/settings.json (global, pour tous les 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*)"
    ]
  }
}

🛡️

Ces commandes sont bloquées quoi qu'il arrive, même si tu es en mode trust, même si Claude pense que c'est nécessaire. rm -rf peut supprimer ton projet entier. supabase db reset détruit toutes les données et credentials. git push --force peut écraser le travail de ton équipe. Mieux vaut prévenir que guérir.

La différence allow vs deny :

allow (.claude/settings.local.json projet) : commandes autorisées sans confirmation
deny (~/.claude/settings.json global) : commandes interdites partout, même en mode trust

Hooks 101

Un hook, c'est un script ou une commande shell que Claude Code déclenche automatiquement quand un évènement précis se produit dans l'éditeur. Tu configures l'évènement, tu configures le script, et ça tourne tout seul en arrière-plan. Pas besoin de demander à Claude de penser à le faire.

Les 5 évènements qui déclenchent un hook

PreToolUse : avant que Claude utilise un outil (ex: bloquer une commande avant qu'elle tourne)
PostToolUse : après qu'un outil ait fini (ex: formater un fichier après un Edit)
UserPromptSubmit : chaque fois que tu envoies un message à Claude
SessionStart : au lancement de Claude Code (ex: charger du contexte)
Stop : quand Claude termine sa réponse

Exemple 1 : Prettier automatique après chaque Edit

À chaque fois que Claude modifie ou crée un fichier, on le formate direct avec Prettier. Zéro fichier mal indenté qui passe en review.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "npx prettier --write \"$CLAUDE_FILE_PATH\""
          }
        ]
      }
    ]
  }
}

Exemple 2 : Charger ton index perso au lancement

Au démarrage de chaque session, Claude lit ton fichier d'index (notes, règles projet, ce que tu veux). Ça évite de lui répéter le contexte à chaque fois.

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

Où mettre la config

~/.claude/settings.json : hooks appliqués à tous tes projets (config perso globale)
.claude/settings.json à la racine d'un projet : hooks spécifiques à ce projet (ex: linter custom, règles d'équipe)

⚠️

Note de sécurité : les hooks tournent avec tes permissions système complètes. Un script qui fait rm, qui envoie une requête réseau ou qui lit des fichiers sensibles s'exécutera sans rien te demander. Avant de copier un hook trouvé sur un repo GitHub ou un blog, lis chaque ligne. Si tu n'es pas sûr de ce qu'il fait, ne le colle pas.

💡

À retenir : configure l'allowlist une seule fois par projet et la deny list une seule fois globalement. Tu élimines 90% des confirmations inutiles tout en bloquant les commandes dangereuses. C'est l'équilibre parfait entre fluidité et sécurité.

🎯

Claude demande toujours avant d'agir

Claude Code ne fera jamais quelque chose de risqué sans te demander explicitement. C'est une règle de sécurité fondamentale.

La solution : pré-autoriser les commandes sûres tout en gardant la validation pour les actions risquées.

Les 3 niveaux de risque

🟢

Sûr, automatique

Claude fait ça librement, sans rien te demander :

Lire des fichiers
Naviguer dans le code
Analyser le projet
Chercher des patterns dans le code

🟡

Modéré, demande confirmation

Claude te montre ce qu'il va faire et attend ton OK :

Modifier des fichiers
Installer des packages
Exécuter des commandes (tests, build, migrations)
Créer de nouveaux fichiers

🔴

Risqué, toujours demandé

Claude explique en détail et attend ta validation explicite :

Pousser du code sur GitHub (git push)
Supprimer des fichiers ou des branches
Actions irréversibles (reset de base de données, etc.)
Commandes inconnues ou inhabituelles

Pré-autoriser les commandes sûres

Pour éviter de cliquer "Oui" 50 fois par session, crée un fichier de configuration qui autorise automatiquement les commandes répétitives et sans risque.

Créer le fichier

Crée le fichier .claude/settings.local.json à la racine de ton projet :

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

💡

Syntaxe wildcard : utilise * comme joker. Bash(npm run *) autorise npm run dev, npm run build, npm run test, etc. en une seule règle. Pas besoin de lister chaque variante.

Ce que ça autorise

Commande	Pourquoi c'est sûr
`npm run typecheck`	Vérifie les types, ne modifie rien
`npm run lint`	Vérifie le style, ne modifie rien
`npm run test`	Lance les tests, ne modifie rien
`npm run build`	Compile l'app, ne modifie pas le code source
`npx supabase`	Commandes Supabase locales
`git status/diff/log`	Lecture seule de l'état Git
`git add/commit`	Sauvegarde locale (pas de push)

Ce qui continue de demander confirmation

git push (envoyer du code en ligne)
npm install (ajouter des dépendances)
Suppression de fichiers
Commandes inconnues

Le mode trust

Si tu es en session de développement intensif et que tu fais totalement confiance à Claude, tu peux passer en mode "trust" depuis l'interface. Claude ne demandera plus de confirmation pour rien.

⚠️

L'expérience au quotidien

Avec un fichier de permissions bien configuré, voici ce que ça donne en pratique :

Claude écrit du code → tu vois les fichiers se modifier en temps réel dans VS Code
Claude lance typecheck → passe automatiquement, pas de confirmation
Claude lance lint → passe automatiquement
Claude veut installer un package → te demande "Installer framer-motion ?" → tu valides
Claude veut commiter → passe automatiquement avec le bon message
Claude veut pusher → te demande "Pousser sur la branche feat/streak ?" → tu valides

Le résultat : tu ne cliques que sur les décisions qui comptent vraiment.

Le filet de sécurité : la deny list

Plus puissant que l'allowlist : la deny list (liste noire). Elle bloque des commandes dangereuses même en mode trust total. C'est ton garde-fou ultime.

Dans ton ~/.claude/settings.json (global, pour tous les 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*)"
    ]
  }
}

🛡️

La différence allow vs deny :

allow (.claude/settings.local.json projet) : commandes autorisées sans confirmation
deny (~/.claude/settings.json global) : commandes interdites partout, même en mode trust

Hooks 101

Les 5 évènements qui déclenchent un hook

PreToolUse : avant que Claude utilise un outil (ex: bloquer une commande avant qu'elle tourne)
PostToolUse : après qu'un outil ait fini (ex: formater un fichier après un Edit)
UserPromptSubmit : chaque fois que tu envoies un message à Claude
SessionStart : au lancement de Claude Code (ex: charger du contexte)
Stop : quand Claude termine sa réponse

Exemple 1 : Prettier automatique après chaque Edit

À chaque fois que Claude modifie ou crée un fichier, on le formate direct avec Prettier. Zéro fichier mal indenté qui passe en review.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "npx prettier --write \"$CLAUDE_FILE_PATH\""
          }
        ]
      }
    ]
  }
}

Exemple 2 : Charger ton index perso au lancement

Au démarrage de chaque session, Claude lit ton fichier d'index (notes, règles projet, ce que tu veux). Ça évite de lui répéter le contexte à chaque fois.

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

Où mettre la config

~/.claude/settings.json : hooks appliqués à tous tes projets (config perso globale)
.claude/settings.json à la racine d'un projet : hooks spécifiques à ce projet (ex: linter custom, règles d'équipe)

⚠️

💡

Les permissions

Claude demande toujours avant d'agir

Les 3 niveaux de risque

Pré-autoriser les commandes sûres

Créer le fichier

Ce que ça autorise

Ce qui continue de demander confirmation

Le mode trust

L'expérience au quotidien

Le filet de sécurité : la deny list

Hooks 101

Les 5 évènements qui déclenchent un hook

Exemple 1 : Prettier automatique après chaque Edit

Exemple 2 : Charger ton index perso au lancement

Où mettre la config

Les permissions

Claude demande toujours avant d'agir

Les 3 niveaux de risque

Pré-autoriser les commandes sûres

Créer le fichier

Ce que ça autorise

Ce qui continue de demander confirmation

Le mode trust

L'expérience au quotidien

Le filet de sécurité : la deny list

Hooks 101

Les 5 évènements qui déclenchent un hook

Exemple 1 : Prettier automatique après chaque Edit

Exemple 2 : Charger ton index perso au lancement

Où mettre la config