Guide complet des permissions Claude Code | settings.json, Hooks et Allowlist expliqués

Claude Code dispose de capacités extrêmement puissantes d’opérations sur les fichiers et d’exécution de commandes. Les permissions permettent de contrôler cette puissance en toute sécurité. Dépassez l’état « ça marche à peu près » et concevez un Claude Code qui fonctionne exactement comme prévu.

Cet article explique en détail, avec du code fonctionnel, tous les paramètres de .claude/settings.json, les schémas d’implémentation des Hooks et la conception des permissions selon les environnements.

Vue d’ensemble des permissions

Les permissions Claude Code sont contrôlées à 3 niveaux.

Niveau	Clé	Comportement
Autoriser	`allow`	S’exécute automatiquement sans boîte de dialogue de confirmation
Demander	`ask`	Nécessite l’approbation de l’utilisateur à chaque fois
Refuser	`deny`	Ne peut pas s’exécuter du tout (rejeté avec une erreur)

Les paramètres se gèrent officiellement avec settings.json. Utilisez ~/.claude/settings.json pour les paramètres utilisateur, .claude/settings.json pour les règles partagées par l’équipe et .claude/settings.local.json pour les surcharges personnelles. ~/.claude.json peut encore contenir certains états comme MCP, mais les règles de permission doivent être traitées comme de la configuration settings.json.

Priorité (de la plus haute à la plus basse) :
Managed settings
    > Arguments de ligne de commande
        > Local .claude/settings.local.json
            > Project .claude/settings.json
                > User ~/.claude/settings.json

Les permission rules fusionnent entre scopes et s'évaluent dans l'ordre deny -> ask -> allow

Structure de base de settings.json

{
  "permissions": {
    "allow": [
      "Read(**)",
      "Glob(**)",
      "Grep(**)",
      "Bash(npm run *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push --force*)"
    ],
    "ask": [
      "Write(**)",
      "Edit(**)",
      "Bash(git commit*)"
    ]
  },
  "hooks": {
    "PreToolUse": [],
    "PostToolUse": []
  }
}

Noms d’outils et syntaxe des motifs

Les permissions sont écrites au format « NomOutil(motif d’argument) ».

Liste des principaux outils

Nom de l’outil	Description
`Read`	Lecture de fichiers
`Write`	Création de nouveaux fichiers
`Edit`	Modification partielle de fichiers existants
`Bash`	Exécution de commandes shell
`Glob`	Recherche par motif de fichiers
`Grep`	Recherche de contenu
`WebFetch`	Récupération d’URL
`Agent`	Lancement d’un sous-agent

Syntaxe des motifs

"Read(**)"          // Autoriser la lecture de tous les fichiers
"Read(src/**)"      // Autoriser uniquement sous src/
"Read(*.md)"        // Autoriser uniquement les fichiers .md
"Bash(npm run *)"   // Autoriser uniquement les commandes commençant par npm run
"Bash(git *)"       // Autoriser toutes les commandes git
"Bash(rm -rf *)"    // Refuser rm -rf

** correspond à tous les chemins y compris les répertoires ; * correspond à un seul segment.

Schémas pratiques

Schéma 1 : Développement solo (relativement permissif)

{
  "permissions": {
    "allow": [
      "Read(**)",
      "Glob(**)",
      "Grep(**)",
      "Bash(npm *)",
      "Bash(git log*)",
      "Bash(git diff*)",
      "Bash(git status*)",
      "Bash(git add*)",
      "Bash(node *)",
      "Bash(echo *)",
      "Bash(cat *)",
      "Bash(ls *)"
    ],
    "deny": [
      "Bash(rm -rf /)",
      "Bash(rm -rf ~*)",
      "Bash(git push --force *main*)",
      "Bash(git push --force *master*)"
    ],
    "ask": [
      "Write(**)",
      "Edit(**)",
      "Bash(git commit*)",
      "Bash(git push*)",
      "Bash(rm *)"
    ]
  }
}

Schéma 2 : Développement en équipe (axé sur la sécurité)

{
  "permissions": {
    "allow": [
      "Read(**)",
      "Glob(**)",
      "Grep(**)",
      "Bash(npm run lint)",
      "Bash(npm run test)",
      "Bash(npm run typecheck)",
      "Bash(git log*)",
      "Bash(git diff*)",
      "Bash(git status*)",
      "Bash(git branch*)"
    ],
    "deny": [
      "Bash(rm -rf*)",
      "Bash(git push --force*)",
      "Bash(git push -f*)",
      "Bash(git reset --hard*)",
      "Bash(git rebase *main*)",
      "Bash(git rebase *master*)",
      "Bash(DROP *)",
      "Bash(TRUNCATE *)",
      "Bash(curl * | bash)",
      "Bash(wget * | sh)"
    ],
    "ask": [
      "Write(**)",
      "Edit(**)",
      "Bash(git commit*)",
      "Bash(git push*)",
      "Bash(git add*)",
      "Bash(npm install*)",
      "Bash(*deploy*)"
    ]
  }
}

Schéma 3 : Environnement de production (lecture seule)

{
  "permissions": {
    "allow": [
      "Read(**)",
      "Glob(**)",
      "Grep(**)",
      "Bash(git log*)",
      "Bash(git diff*)",
      "Bash(git status*)",
      "Bash(git show*)",
      "Bash(cat *)",
      "Bash(ls *)",
      "Bash(ps *)",
      "Bash(df *)",
      "Bash(top *)"
    ],
    "deny": [
      "Write(**)",
      "Edit(**)",
      "Bash(git push*)",
      "Bash(git commit*)",
      "Bash(git reset*)",
      "Bash(rm *)",
      "Bash(mv *)",
      "Bash(*deploy*)",
      "Bash(*restart*)",
      "Bash(*kill *)"
    ],
    "ask": []
  }
}

Pour un travail de production ou proche de la production, placez cette configuration comme .claude/settings.json actif et démarrez avec claude --permission-mode plan ou un dontAsk préapprouvé. Cela reste plus proche du modèle officiel de scopes et de permission modes que l’échange d’un fichier alternatif via variable d’environnement.

Schéma 4 : Génération de contenu uniquement (le schéma utilisé sur ce site)

{
  "permissions": {
    "allow": [
      "Read(**)",
      "Glob(**)",
      "Grep(**)",
      "Write(site/src/content/**)",
      "Write(content/**)",
      "Edit(site/src/content/**)",
      "Edit(content/**)",
      "Bash(git log*)",
      "Bash(git diff*)",
      "Bash(git status*)",
      "Bash(node scripts/*)",
      "Bash(QIITA_TOKEN=* node scripts/qiita-publish.mjs)"
    ],
    "deny": [
      "Bash(rm -rf*)",
      "Bash(git push --force*)",
      "Edit(.env*)",
      "Read(.env*)"
    ],
    "ask": [
      "Bash(git add*)",
      "Bash(git commit*)",
      "Bash(git push*)",
      "Bash(bash scripts/deploy.sh*)"
    ]
  }
}

La clé est de restreindre les écritures à un répertoire spécifique, comme avec Write(site/src/content/**).

Hooks : Exécuter des processus avant et après les permissions

Les Hooks sont un mécanisme qui exécute automatiquement des commandes avant et après l’exécution des outils. Ils peuvent être utilisés pour des vérifications de sécurité et du formatage automatique.

PreToolUse : Hook avant l’exécution

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash(git add*)",
        "hooks": [{
          "type": "command",
          "command": "git diff --cached --name-only | grep -E '^\\.env' && echo '🚨 Ajout de .env détecté !' && exit 1 || exit 0"
        }]
      },
      {
        "matcher": "Bash(git commit*)",
        "hooks": [{
          "type": "command",
          "command": "node scripts/secret-scan.mjs"
        }]
      },
      {
        "matcher": "Bash(rm*)",
        "hooks": [{
          "type": "command",
          "command": "echo '⚠️ Commande de suppression détectée. Exécution dans 5 secondes. Ctrl+C pour annuler.' && sleep 5"
        }]
      }
    ]
  }
}

Si une commande hook retourne le code de sortie 1, l’exécution de l’outil est bloquée. C’est le point le plus important.

PostToolUse : Hook après l’exécution

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [{
          "type": "command",
          "command": "npx tsc --noEmit 2>&1 | head -20 || true"
        }]
      },
      {
        "matcher": "Bash(git commit*)",
        "hooks": [{
          "type": "command",
          "command": "git log --oneline -3"
        }]
      }
    ]
  }
}

PostToolUse est utilisé pour les vérifications post-exécution et les effets secondaires — par exemple, exécuter automatiquement des vérifications de types après des modifications de fichiers ou afficher les 3 dernières entrées du journal après un commit.

Collection de recettes de Hooks pratiques

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash(npm install*)",
        "hooks": [{
          "type": "command",
          "command": "echo '📦 Ajout de paquet. Veuillez vérifier package.json.'"
        }]
      },
      {
        "matcher": "Bash(*deploy*)",
        "hooks": [{
          "type": "command",
          "command": "read -p '🚀 Sur le point de déployer. Continuer ? [y/N] ' ans && [ \"$ans\" = 'y' ] || exit 1"
        }]
      }
    ],
    "PostToolUse": [
      {
        "matcher": "Write(*.ts)|Edit(*.ts)",
        "hooks": [{
          "type": "command",
          "command": "npx eslint --fix $CLAUDE_TOOL_INPUT_FILE_PATH 2>/dev/null || true"
        }]
      }
    ]
  }
}

Modes de permission : Niveau de permission au démarrage

Vous pouvez également spécifier le mode lors du lancement de la commande claude.

# Mode normal (suit settings.json)
claude

# Approuver automatiquement toutes les opérations (dangereux ! uniquement pour les environnements de confiance)
claude --dangerously-skip-permissions

# Ignorer uniquement des opérations spécifiques
claude --allowedTools "Read,Grep,Glob"

# Mode non interactif (utilisé en CI/CD)
claude -p "Exécuter les tests et rapporter les résultats" --dangerously-skip-permissions

--dangerously-skip-permissions ne doit être utilisé que pour l’automatisation CI/CD ou des scripts d’automatisation parfaitement maîtrisés, et évité dans l’utilisation interactive quotidienne.

2026: Permission budget sûr et revue d’équipe

Ici, permission budget n’est pas un nom de fonctionnalité officiel. C’est la limite opérationnelle de ce que vous autorisez automatiquement pendant la première semaine. Au 1er juin 2026, la documentation officielle décrit les permission rules comme évaluées dans l’ordre deny -> ask -> allow. Les hooks PreToolUse ajoutent des contrôles à l’exécution, mais ne remplacent pas une règle deny ou ask déjà correspondante. Le premier budget doit donc privilégier la possibilité de revenir en arrière plutôt que la vitesse.

Un budget de départ sûr reste étroit. Dans allow, gardez seulement la lecture et la vérification: Read, Glob, Grep, git status, git diff, git log, npm run lint et npm run test. Dans ask, mettez les opérations qui changent l’intention: Edit, Write, git add, git commit, git push, npm install et le déploiement. Dans deny, placez l’irréversible ou le sensible: .env, secrets/**, rm -rf, git reset --hard, git push --force, curl | bash, wget | sh et les commandes sur bases de production. bypassPermissions doit rester dans des conteneurs, VMs ou devcontainers jetables.

En équipe, relisez .claude/settings.json comme du code applicatif. Chaque PR doit répondre à trois questions: chaque allow est-il sûr en exécution répétée, chaque ask représente-t-il une vraie confirmation humaine, et deny couvre-t-il secrets, force push, suppressions et production? Dans une organisation administrée, les server-managed settings permettent de mettre disableBypassPermissionsMode et disableAutoMode à "disable", puis d’utiliser allowManagedPermissionRulesOnly pour bloquer les règles locales ou de projet.

Un échec dangereux consiste à autoriser largement Bash(git *) ou Bash(node *) tout en croyant que Read(.env*) protège les secrets. La documentation officielle précise que les règles deny de Read et Edit s’appliquent aux outils fichier de Claude Code et à certaines commandes reconnues, mais pas aux sous-processus arbitraires, par exemple un script Node ou Python qui ouvre un fichier directement. Pour protéger des secrets, évitez les Bash trop larges et combinez sandbox, droits du système d’exploitation et contrôles PreToolUse.

Préparez le rollback avant l’incident. Si une édition indésirable arrive, ouvrez /permissions pour voir la règle active et sa source, inspectez git diff, puis revenez avec git restore -p afin de garder les bons hunks. Pour les fichiers non suivis, lancez git clean -n avant toute suppression. Si un secret a pu être lu ou entrer dans le transcript, corriger .claude/settings.json ne suffit pas: il faut faire tourner le token.

Pour transformer cet article en politique de dépôt, commencez par permission budget loop et permission audit checklist. Pour des modèles et supports prêts à l’emploi, comparez les produits Claude Code. Pour un déploiement d’équipe, une revue de permissions et un onboarding sûr, la consultation est plus propre que deviner seul la politique.

Priorité et écrasement des fichiers de configuration

Lorsque plusieurs fichiers de configuration existent :

~/.claude/settings.json     ← User (partagé entre projets)
.claude/settings.json       ← Project (géré avec git)
.claude/settings.local.json ← Local (personnel, dans gitignore)
managed-settings.json       ← Managed (politique d'organisation, priorité maximale)

Les permission rules fusionnent et deny est toujours évalué avant allow

Écrivez les paramètres additionnels personnels dans .claude/settings.local.json et ajoutez-le à gitignore. Pour éviter que les listes deny de l’équipe soient écrasées par des paramètres personnels, la conception sécurisée consiste à écrire les règles deny uniquement dans settings.json.

# Ajouter à .gitignore
.claude/settings.local.json

Les 5 pièges les plus courants

1. Se tromper dans les motifs génériques

// ❌ Ceci ne correspond qu'à la commande unique "git"
"Bash(git)"

// ✅ Correspond aussi à git suivi d'arguments
"Bash(git *)"
"Bash(git*)"  // Fonctionne aussi sans espace, mais * explicite est plus sûr

2. Oublier que deny a la priorité sur ask

// Avec cette configuration, Bash(rm -rf /tmp/test) est intercepté par deny et bloqué
// Il n'atteint jamais ask
{
  "deny": ["Bash(rm -rf*)"],
  "ask": ["Bash(rm*)"]  // ← rm -rf est traité par deny
}

3. Ne pas faire attention aux codes de sortie des hooks

# Si la commande du hook PreToolUse retourne toujours exit 0,
# les échecs de scan ne bloqueront pas l'exécution

# ❌ Passe même en cas d'erreur
"command": "node scan.mjs"

# ✅ Contrôler explicitement le code de sortie
"command": "node scan.mjs || exit 1"

4. Ajouter accidentellement settings.json à .gitignore

Certaines équipes ajoutent accidentellement settings.json—qu’elles veulent partager—à .gitignore. L’approche correcte est la configuration du projet sous git, seulement settings.local.json dans gitignore.

5. Oublier de changer manuellement la configuration de production

# ❌ Travailler en production avec la configuration quotidienne

# ✅ Démarrer en plan mode et garder le .claude/settings.json du worktree sûr pour la production
claude --permission-mode plan

Enregistrer un alias le rend plus difficile à oublier :

# ~/.bashrc or ~/.zshrc
alias claude-prod='claude --permission-mode plan'

Débogage de la configuration

Quand on ne comprend pas « pourquoi cette commande est-elle bloquée » :

# Vérifier la configuration actuelle
claude --print-settings 2>/dev/null || cat .claude/settings.json

# Vérifier quelle règle correspond (mode verbose)
claude --verbose -p "Exécuter git push"

Résumé : Bonnes pratiques pour la conception des permissions

1. Commencer par deny
   → Lister les commandes à ne jamais exécuter
   → rm -rf, git push --force, DROP TABLE sont indispensables

2. Ensuite configurer ask
   → Opérations d'écriture et de déploiement nécessitant confirmation

3. Allow pour tout le reste
   → Opérations de lecture et CI : tout en allow pour l'efficacité

4. Automatiser la sécurité avec les Hooks
   → Scan pré-commit, vérification de types automatique après modifications

5. Préparer des fichiers de configuration spécifiques aux environnements
   → settings.json (développement), settings.production.json (production)

Avec des permissions correctement configurées, vous cesserez de cliquer mécaniquement sur les boutons d’approbation et pourrez vous concentrer uniquement sur les opérations qui nécessitent vraiment une vérification. Consacrer 30 minutes à cette conception initiale sécurisera des centaines d’heures de travail futur.