Claude Code Permissions : modes Deny, Allow et Ask expliqués

Pourquoi les permissions sont importantes

Contrairement aux assistants basés sur le chat, Claude Code est un outil agentique. Il ne se contente pas de suggérer — il agit. Sans garde-fous :

• →Une requête mal comprise pourrait supprimer des fichiers
• →Les tests pourraient s'exécuter contre la production
• →Les identifiants pourraient être journalisés ou exposés
• →Des commandes destructrices pourraient s'exécuter silencieusement

Le système de permissions empêche ces scénarios tout en préservant la capacité de Claude à vous aider.

Les trois modes de permission

Claude Code fonctionne dans l'un de ces trois modes pour chaque outil ou commande :

Mode Ask (par défaut)

Le mode Ask est l'option interactive la plus sûre. Claude vous montre ce qu'il veut faire et attend votre approbation :

Claude wants to run: npm install lodash

[y] Accept  [n] Reject  [e] Edit  [Esc] Cancel

Vous pouvez :

• →Accepter (y) : Exécuter la commande
• →Rejeter (n) : Ignorer cette action
• →Éditer (e) : Modifier la commande avant exécution
• →Annuler (Esc) : Annuler entièrement

Mode Allow

Le mode Allow autorise des opérations spécifiques sans demande :

# Autoriser toutes les commandes npm
claude config add permissions.allow "Bash(npm:*)"

# Autoriser les opérations git
claude config add permissions.allow "Bash(git:*)"

# Autoriser la lecture de fichiers
claude config add permissions.allow "Read(*)"

Claude exécute les commandes autorisées immédiatement — aucune confirmation nécessaire.

Mode Deny

Le mode Deny bloque complètement les opérations :

# Bloquer l'accès à la base de données de production
claude config add permissions.deny "Bash(psql:*prod*)"

# Bloquer rm avec le flag -rf
claude config add permissions.deny "Bash(rm:-rf*)"

# Bloquer curl vers des URL externes
claude config add permissions.deny "Bash(curl:*)"

Même si Claude essaie d'exécuter une commande refusée, elle échoue immédiatement.

Ordre de priorité des permissions

Quand plusieurs règles s'appliquent, Claude les évalue dans cet ordre :

1. →Deny — Vérifié en premier. Si une règle deny correspond, l'action est bloquée.
2. →Allow — Vérifié en second. Si une règle allow correspond, l'action est autorisée.
3. →Ask — Par défaut. Si aucune règle ne correspond, on demande à l'utilisateur.

Exemple :

# Autoriser toutes les commandes git
claude config add permissions.allow "Bash(git:*)"

# Mais interdire le force push
claude config add permissions.deny "Bash(git:push --force*)"
claude config add permissions.deny "Bash(git:push -f*)"

Résultat : La plupart des commandes git s'exécutent librement, mais les force pushes sont bloqués.

Types d'outils et patterns de permission

Outils intégrés

Syntaxe des patterns

Les patterns utilisent un matching de style glob :

Exemples :

# Autoriser la lecture de tout fichier
"Read(*)"

# Autoriser la lecture du dossier src uniquement
"Read(src/**)"

# Autoriser npm et yarn
"Bash({npm,yarn}:*)"

# Autoriser git sauf certaines commandes spécifiques
"Bash(git:*)" + deny "Bash(git:push --force*)"

Configurer les permissions

Configuration interactive

> /permissions

Ouvre un menu interactif :

Current Permission Mode: ask

Allowed:
  - Bash(npm:*)
  - Bash(git:*)
  - Read(*)

Denied:
  - Bash(rm:-rf*)
  - Bash(sudo:*)

[a] Add rule  [r] Remove rule  [m] Change mode  [Esc] Exit

Configuration en ligne de commande

# Ajouter des règles allow
claude config add permissions.allow "Bash(npm:*)"
claude config add permissions.allow "Bash(git:*)"

# Ajouter des règles deny
claude config add permissions.deny "Bash(rm:-rf*)"

# Voir les permissions actuelles
claude config show permissions

# Supprimer une règle
claude config remove permissions.allow "Bash(npm:*)"

Fichier de paramètres

Les permissions se trouvent dans ~/.claude/settings.json :

{
  "permissions": {
    "mode": "ask",
    "allow": [
      "Bash(npm:*)",
      "Bash(git:*)",
      "Read(*)",
      "Edit(src/**)"
    ],
    "deny": [
      "Bash(rm:-rf*)",
      "Bash(sudo:*)",
      "Bash(curl:*)"
    ]
  }
}

Permissions au niveau du projet

Ajoutez des permissions au fichier .claude/settings.json de votre projet :

{
  "permissions": {
    "allow": [
      "Bash(npm:*)",
      "Bash(pytest:*)"
    ],
    "deny": [
      "Bash(npm:publish*)"
    ]
  }
}

Les permissions du projet se fusionnent avec les permissions utilisateur. Les règles deny de l'une ou l'autre source prennent la priorité.

Niveaux de confiance

Pour une configuration rapide, utilisez les niveaux de confiance :

Par défaut (tout demander)

claude config set permissions.mode "ask"

Toutes les opérations nécessitent une confirmation.

Acceptation automatique des modifications

claude config set permissions.mode "auto-edit"

Les modifications de fichiers sont automatiquement acceptées ; les autres opérations demandent toujours.

Tout automatique

claude config set permissions.mode "auto"

Toutes les opérations sûres se déroulent automatiquement. Seules les commandes potentiellement dangereuses demandent confirmation.

Mode sandbox

claude --sandbox

S'exécute dans un environnement isolé :

• →Système de fichiers restreint au projet
• →Réseau limité à localhost
• →Pas d'accès aux commandes système

Voir Claude Code Best Practices : sécurité, performance et équipes pour les détails du sandbox.

Permissions basées sur la session

Accordez des permissions temporaires pour des sessions spécifiques :

Confiance de session

Quand Claude demande une action, vous pouvez accorder une permission pour toute la session :

Claude wants to run: npm test

[y] Yes  [Y] Yes, allow all npm commands this session
[n] No   [Esc] Cancel

Appuyer sur Y (majuscule) ajoute une règle allow temporaire pour la session.

Ignorer les permissions de manière dangereuse

Pour une exécution entièrement autonome (CI/CD, automatisation) :

claude --dangerously-skip-permissions

Avertissement : Cela contourne toutes les vérifications de permissions. À n'utiliser que dans :

• →Les environnements sandboxés
• →Les pipelines CI/CD
• →Les contextes entièrement contrôlés

Voir Claude Code GitHub Actions : automatisation CI/CD propulsée par l'IA.

Configurations de permissions courantes

Développeur web

{
  "permissions": {
    "allow": [
      "Read(*)",
      "Edit(src/**)",
      "Edit(public/**)",
      "Bash(npm:*)",
      "Bash(yarn:*)",
      "Bash(pnpm:*)",
      "Bash(git:*)",
      "Bash(eslint:*)",
      "Bash(prettier:*)"
    ],
    "deny": [
      "Bash(rm:-rf*)",
      "Bash(npm:publish*)",
      "Edit(.env*)"
    ]
  }
}

Data scientist Python

{
  "permissions": {
    "allow": [
      "Read(*)",
      "Edit(src/**)",
      "Edit(notebooks/**)",
      "Bash(python:*)",
      "Bash(pip:*)",
      "Bash(pytest:*)",
      "Bash(jupyter:*)"
    ],
    "deny": [
      "Bash(rm:-rf*)",
      "Edit(.env*)",
      "Bash(pip:install --user*)"
    ]
  }
}

Ingénieur DevOps

{
  "permissions": {
    "allow": [
      "Read(*)",
      "Edit(terraform/**)",
      "Edit(ansible/**)",
      "Bash(terraform:*)",
      "Bash(ansible:*)",
      "Bash(kubectl:get*)",
      "Bash(kubectl:describe*)"
    ],
    "deny": [
      "Bash(kubectl:delete*)",
      "Bash(terraform:destroy*)",
      "Bash(rm:-rf*)",
      "Edit(**/secrets/**)"
    ]
  }
}

Automatisation CI/CD

{
  "permissions": {
    "allow": [
      "Read(*)",
      "Edit(*)",
      "Bash(npm:*)",
      "Bash(git:*)",
      "Bash(gh:*)"
    ],
    "deny": [
      "Bash(rm:-rf /)",
      "Bash(sudo:*)"
    ]
  }
}

Utilisé avec --dangerously-skip-permissions dans des environnements CI contrôlés.

Bonnes pratiques de sécurité

1. Commencez de manière restrictive

Commencez avec le mode ask par défaut. N'ajoutez des règles allow que pour les opérations auxquelles vous faites entièrement confiance :

# Commencez ici
claude config set permissions.mode "ask"

# Ajoutez des autorisations spécifiques selon les besoins
claude config add permissions.allow "Bash(npm:install)"
claude config add permissions.allow "Bash(npm:test)"

2. Refusez toujours les commandes destructrices

claude config add permissions.deny "Bash(rm:-rf*)"
claude config add permissions.deny "Bash(sudo:*)"
claude config add permissions.deny "Bash(chmod:777*)"
claude config add permissions.deny "Bash(dd:*)"

3. Protégez les fichiers sensibles

# Interdire l'édition des fichiers d'environnement
claude config add permissions.deny "Edit(.env*)"
claude config add permissions.deny "Edit(**/.env*)"

# Interdire la lecture des identifiants
claude config add permissions.deny "Read(**/credentials*)"
claude config add permissions.deny "Read(**/*.pem)"

4. Restreignez l'accès à la production

# Bloquer les commandes de base de données de production
claude config add permissions.deny "Bash(psql:*prod*)"
claude config add permissions.deny "Bash(mysql:*production*)"

# Bloquer les déploiements en production
claude config add permissions.deny "Bash(kubectl:*--context=prod*)"
claude config add permissions.deny "Bash(ssh:*prod*)"

5. Utilisez des règles spécifiques au projet

Les projets d'équipe devraient définir les permissions dans .claude/settings.json :

{
  "permissions": {
    "deny": [
      "Bash(npm:publish*)",
      "Bash(git:push --force*)",
      "Edit(.env*)"
    ]
  }
}

Commitez ceci dans le contrôle de version pour que tous les membres de l'équipe partagent les mêmes règles de sécurité.

Hooks pour le contrôle des permissions

Les hooks fournissent une couche supplémentaire de contrôle. Créez une validation personnalisée :

// .claude/settings.json
{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "command": "python .claude/hooks/validate-command.py"
      }
    ]
  }
}

Le script du hook reçoit les détails de la commande et peut bloquer l'exécution :

# .claude/hooks/validate-command.py
import json
import sys

input_data = json.loads(sys.stdin.read())
command = input_data.get("tool_input", {}).get("command", "")

# Block any command targeting /etc
if "/etc" in command:
    result = {
        "decision": "block",
        "reason": "Commands targeting /etc are not allowed"
    }
else:
    result = {"decision": "proceed"}

print(json.dumps(result))

En savoir plus : Claude Code Hooks : automatisez votre workflow de développement

Débogage des permissions

Voir les règles appliquées

claude config show permissions

Tester un pattern

Vérifiez si une commande spécifique serait autorisée :

claude permissions check "Bash(npm:publish)"

Sortie :

Command: Bash(npm:publish)
Result: DENIED

Matching rule:
  deny: Bash(npm:publish*)
  Source: ~/.claude/settings.json

Voir les logs de permissions

Activez la journalisation verbeuse :

claude --verbose

Affiche les vérifications de permissions en temps réel :

[PERMISSION] Checking: Bash(npm:test)
[PERMISSION] Rule matched: allow Bash(npm:*)
[PERMISSION] Decision: ALLOW

Permissions en automatisation

GitHub Actions

- name: Run Claude Code
  run: |
    claude --dangerously-skip-permissions -p "Fix failing tests"
  env:
    ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}

Voir Claude Code GitHub Actions : automatisation CI/CD propulsée par l'IA.

Mode headless

claude --print --dangerously-skip-permissions -p "Analyze this codebase"

Voir Claude Code headless et programmatique : SDK et automatisation.

Permissions des outils MCP

Les serveurs MCP ajoutent des outils personnalisés. Contrôlez-les avec des patterns :

# Autoriser tous les outils du serveur filesystem
claude config add permissions.allow "mcp__filesystem__*"

# Interdire les opérations destructrices du filesystem
claude config add permissions.deny "mcp__filesystem__delete_file"

# Autoriser des opérations GitHub spécifiques
claude config add permissions.allow "mcp__github__get_pull_request"
claude config add permissions.deny "mcp__github__merge_pull_request"

En savoir plus : Model Context Protocol (MCP) pour Claude Code : guide complet

Points clés à retenir

1. →

   Mode Ask par défaut : Commencez supervisé et accordez les permissions de manière incrémentale.

2. →

   Deny avant Allow : Les règles deny prennent toujours la priorité, fournissant des blocages stricts sur les opérations dangereuses.

3. →

   Utilisez les patterns avec sagesse : Les patterns glob offrent de la flexibilité — soyez spécifique pour éviter les autorisations excessives.

4. →

   Protégez les données sensibles : Refusez toujours l'accès aux identifiants, fichiers d'environnement et systèmes de production.

5. →

   Commitez les permissions du projet : Partagez les règles de sécurité via .claude/settings.json dans le contrôle de version.

Maîtrisez la sécurité et l'éthique de l'IA

Les permissions ne sont qu'un aspect de l'utilisation responsable de l'IA. Apprenez les principes plus larges dans notre module de sécurité.

Dans notre Module 8 — Sécurité et éthique, vous apprendrez :

• →Les principes de sécurité IA et les bonnes pratiques
• →La divulgation responsable et la gestion des risques
• →Les considérations éthiques dans le développement IA
• →La construction de la confiance par la transparence

→ Explorer le Module 8 : Sécurité et éthique