Configuration des autorisations de Claude Code

Claude Code utilise un système de permissions en couches pour équilibrer fonctionnalité et sécurité, en prenant en charge des règles de permissions fines, des modes de permission et des politiques de bac à sable pour contrôler ce que Claude peut accéder et exécuter. Des permissions correctement configurées permettent à l'IA d'accomplir des tâches efficacement tout en évitant que des opérations accidentelles endommagent le code ou divulguent des fichiers sensibles.

À partir de Claude Code v1.1.1, la nouvelle méthode de configuration des permissions est recommandée. L'anciennetoolsLa configuration booléenne est toujours prise en charge, mais il est recommandé de migrer vers la nouvelle syntaxe des règles de permission.

Aperçu du système de permissions

Le système de permissions de Claude Code classe les opérations en trois types, avec des politiques de permissions par défaut différentes pour chaque type :

Type d'outil Exemple Approbation requise Comportement autorisé en permanence
Opérations en lecture seule Lecture de fichiers, recherche Grep non Sans objet
Commandes Bash Exécution de commandes shell Oui Permanent pour chaque répertoire de projet et commande
Modifications de fichiers Modifier/écrire des fichiers Oui Jusqu'à la fin de la session

Trois actions de permission

Chaque règle de permission se résout finalement en l'une des trois actions suivantes :

Action Effet Scénario applicable
"allow" S'exécute automatiquement sans approbation Opérations à faible risque et à haute fréquence telles que git status, npm run build
"ask" Affiche une invite d'approbation, vous permettant de décider d'autoriser ou non Opérations présentant un certain risque, telles que l'écriture de fichiers, l'exécution de commandes dangereuses
"deny" Bloqué directement, non exécuté et sans invite Opérations dangereuses clairement non autorisées, telles que git push, rm -rf

Priorité des règles : refuser → demander → autoriser.La première règle correspondante l'emporte, donc les règles de refus ont toujours la priorité sur l'autorisation et la demande.

Modes de permission

Les modes de permission contrôlent si Claude demande à l'utilisateur avant d'effectuer des actions. Différentes tâches nécessitent différents niveaux d'autonomie.

1. Six modes disponibles

Mode Description Idéal pour
default Comportement standard : demande l’autorisation lors de la première utilisation de chaque outil Intégration, travaux sensibles nécessitant une supervision complète
acceptEdits Accepter automatiquement les autorisations de modification de fichiers pour la session, sauf pour les répertoires protégés Itération sur du code en cours de revue
plan Mode Plan : Claude peut analyser mais ne peut pas modifier les fichiers ni exécuter de commandes Exploration de bases de code, planification de refactorisations
auto Approuver automatiquement les appels d’outils avec des contrôles de sécurité en arrière-plan (aperçu de recherche) Tâches de longue durée, réduction de la fatigue liée aux invites
dontAsk Rejeter automatiquement les appels d’outils, sauf s’ils sont pré-approuvés via des règles d’autorisation Environnements verrouillés, pipelines CI
bypassPermissions Ignorer les demandes d’autorisation, mais les écritures dans les répertoires protégés demandent toujours confirmation Uniquement des conteneurs et des VM isolés

Note sur les répertoires protégés :Quel que soit le mode, les écritures dans.git、.vscode、.idea、.huskyet.claudene seront jamais automatiquement approuvées, sauf pour.claude/commands、.claude/agentset.claude/skills。

2. Changer de mode d'autorisation

Changer pendant une session :appuyez surShift+TabParcourir les modesdefault → acceptEdits → plan → auto

Spécifier le mode au démarrage :

claude --permission-mode plan
claude --permission-mode bypassPermissions

Définir comme mode par défaut (settings.json) :

Exemple

{
  "permissions": {
    "defaultMode": "acceptEdits"
  }
}

Syntaxe des règles d'autorisation

1. Format de base

Les règles d'autorisation suivent le formatToolouTool(specifier)：

Exemple

{
  "permissions": {
    "allow": ["Bash", "WebFetch", "Read"],
    "deny": ["Edit"]
  }
}

2. Correspondance à toutes les utilisations d'outils

Les règles sans spécificateurs correspondent à toutes les utilisations de cet outil :

Règle Effet
Bash Correspond à toutes les commandes Bash
WebFetch Correspond à toutes les requêtes de récupération réseau
Read Correspond à toutes les lectures de fichiers
Edit Correspond à toutes les modifications de fichiers

Bash(*)Équivalent àBash, les deux ont le même effet.

3. Contrôle granulaire avec spécificateurs

Exemple

{
  "permissions": {
    "allow": [
      "Bash(npm run build)",     // Correspond aux commandes exactes
      "Read(./.env)",             // Correspond à la lecture du fichier .env dans le répertoire courant
      "WebFetch(domain:example.com)"  // Fait correspondre les requêtes fetch à example.com
    ]
  }
}

4. Motifs génériques

Les règles Bash prennent en charge les motifs glob avec*caractères génériques ; les caractères génériques peuvent apparaître n'importe où dans la commande :

Exemple

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",         // Correspond à npm run build, npm run test, etc.
      "Bash(git commit *)",      // Correspond à git commit -m "message", etc.
      "Bash(git * main)",        // Correspond à git checkout main, git merge main, etc.
      "Bash(* --version)",       // Correspond à toute commande avec un argument --version
      "Bash(* --help *)"         // Correspond à toute commande avec un argument --help
    ],
    "deny": [
      "Bash(git push *)"         // Bloque toutes les opérations git push
    ]
  }
}

Notez l'espace avant les caractères génériques :Bash(ls *)matchesls -lamais ne correspond paslsof；Bash(ls*)correspond aux deux.

Règles d'autorisation spécifiques aux outils

1. Commandes Bash

Règle Exemples de correspondance
Bash(npm run build) seulementnpm run build
Bash(npm run test *) npm run test、npm run test --coverage
Bash(npm *) Toute commande commençant par npm
Bash(* install) Toute commande se terminant par install
Bash(git * main) git checkout main、git merge main

Limitation importante :Les motifs d'autorisation Bash qui tentent de contraindre les arguments de commande peuvent être fragiles. Les options avant l'URL, les différents protocoles, les redirections, les variables, les espaces supplémentaires peuvent tous provoquer des non-correspondances. Il est recommandé d'utiliser l'outil WebFetch avecdomain:des autorisations pour le filtrage d'URL.

2. Read and Edit (opérations sur les fichiers)

Les chemins de fichiers prennent en charge plusieurs modèles de préfixe de chemin :

Préfixe de motif Signification Exemple
//path Chemin absolu (depuis la racine du système de fichiers) Read(//Users/alice/secrets/**)Correspondances/Users/alice/secrets/**
~/path Chemin du répertoire personnel Read(~/Documents/*.pdf)Correspondances/Users/alice/Documents/*.pdf
/path Relatif à la racine du projet Edit(/src/**/*.ts)Correspondances<project root>/src/**/*.ts
pathou./path Relatif au répertoire courant Read(*.env)Correspondances<cwd>/*.env

Exemple

{
  "permissions": {
    "allow": [
      "Edit(/docs/**)",          // Autoriser la modification des fichiers dans le répertoire docs du projet
      "Read(~/.zshrc)",         // Autoriser la lecture de .zshrc dans le répertoire personnel
      "Edit(//tmp/scratch.txt)", // Autoriser la modification de fichiers temporaires à des chemins absolus
      "Read(src/**)"            // Autoriser la lecture des fichiers dans le sous-répertoire src du répertoire courant
    ],
    "deny": [
      "Read(*.env)",            // Bloquer la lecture des fichiers .env (empêcher la fuite de secrets)
      "Edit(//etc/**)"          // Bloquer la modification des fichiers du répertoire système
    ]
  }
}

Remarque :Les règles de refus Read et Edit ne s'appliquent pas dans les sous-processus Bashcat .env. Pour obtenir une application au niveau du système d'exploitation, activez le bac à sable.

3. WebFetch (Requêtes réseau)

Exemple

{
  "permissions": {
    "allow": [
      "WebFetch(domain:github.com)",    // Autoriser l'accès à GitHub
      "WebFetch(domain:api.example.com)" // Autoriser l'accès aux API internes
    ],
    "deny": [
      "WebFetch(domain:untrusted.com)"  // Bloquer l'accès aux domaines non fiables
    ]
  }
}

4. MCP (Model Context Protocol)

Exemple

{
  "permissions": {
    "allow": [
      "mcp__puppeteer",                      // Autoriser tous les outils fournis par le serveur puppeteer
      "mcp__puppeteer__*"                    // Autoriser tous les outils du serveur puppeteer
    ],
    "deny": [
      "mcp__puppeteer__puppeteer_navigate"  // Bloquer des outils spécifiques
    ]
  }
}

5. Agent (Sous-agent)

Exemple

{
  "permissions": {
    "allow": [
      "Agent(Explore)",           // Autoriser l'utilisation du sous-agent Explore
      "Agent(Plan)"               // Autoriser l'utilisation du sous-agent Plan
    ],
    "deny": [
      "Agent(my-custom-agent)"    // Bloquer les sous-agents personnalisés
    ]
  }
}

Configuration du répertoire de travail

Par défaut, Claude Code n'autorise l'accès qu'au répertoire de travail au démarrage et à ses sous-répertoires. Si vous devez accéder à des chemins en dehors du répertoire du projet, vous devez le configurer explicitement.

1. Méthodes d'accès étendues

  • Au démarrage :Utilisez--add-dir <path>Arguments CLI
  • Pendant une session :Utilisez/add-dircommandes
  • Configuration persistante :Ajoutez à settings.jsonadditionalDirectories

Exemple

{
  "additionalDirectories": [
    "~/projects/personal/**",    // Autoriser l'accès aux répertoires de projets personnels
    "~/projects/work/**",        // Autoriser l'accès aux répertoires du projet work
    "~/dotfiles/**"               // Autoriser l'accès aux répertoires de fichiers de configuration
  ]
}

2. Exceptions

Le contenu suivant reste accessible après avoir défini des répertoires supplémentaires, sans nécessiter de configuration supplémentaire :

  • .claude/skills/Skills dans (avec rechargement en direct)
  • .claude/settings.jsonParamètres du plugin dans (uniquementenabledPluginsetextraKnownMarketplaces）
  • Fichiers CLAUDE.md et.claude/rules/(uniquement lorsqueCLAUDE_CODE_ADDITIONAL_DIRECTORIES_CLAUDE_MD=1est défini)

Mode Auto

Le Mode Auto est un nouveau mécanisme introduit dans Claude Code qui remplace l'approbation manuelle par un classificateur piloté par modèle, contrôlant le risque autant que possible tout en garantissant l'efficacité.

1. Conditions disponibles

  • Uniquement pour les forfaits Team, Enterprise et API
  • Nécessite Claude Sonnet 4.6 ou Claude Opus 4.6
  • Non disponible sur Haiku, les modèles claude-3 ou les fournisseurs tiers
  • Les administrateurs doivent l'activer dans les paramètres d'administration de Claude Code

2. Comment ça fonctionne

Avant l'exécution de chaque opération, un modèle classificateur distinct examine la conversation et décide si l'opération correspond à la demande de l'utilisateur.

Couches de défense :

  1. Les sondes côté serveur analysent les résultats d'outils entrants
  2. Le classificateur ne voit jamais les résultats d'outils, ce qui empêche des instructions injectées d'influencer les décisions

Ordre d'évaluation des opérations :

  1. Les opérations qui correspondent aux règles d'autorisation ou de refus sont résolues immédiatement
  2. Les opérations en lecture seule et les modifications de fichiers dans le répertoire de travail sont approuvées automatiquement (sauf pour les répertoires protégés)
  3. Tout le reste est envoyé au classificateur
  4. Si le classificateur bloque, Claude reçoit la raison et tente des méthodes alternatives

3. Comportement par défaut du classificateur

Type d'opération Comportement
Bloqué par défaut
Téléchargement et exécution de code curl | bashwait
Envoi de données sensibles vers des points de terminaison externes Risque de fuite de données
Déploiements et migrations de production Modifications de l'environnement de production
Suppressions à grande échelle sur le stockage cloud Risque de perte de données
Octroi d'autorisations IAM ou de dépôt Risque d'élévation de privilèges
Modification de l'infrastructure partagée Affecte d'autres utilisateurs
Destruction irréversible de fichiers Fichiers qui existaient avant le début de la session
Opérations destructrices sur le contrôle de source Push forcés, push directs vers main
Autorisation par défaut
Opérations sur les fichiers locaux dans le répertoire de travail Dans le périmètre de sécurité
Installer les dépendances déclarées Dépendances déjà présentes dans package.json
Lire .env et envoyer les identifiants Envoyer vers les API correspondantes
Requêtes HTTP en lecture seule Requêtes GET
Pousser vers la branche démarrée Opérations sécurisées sur les branches

4. Configuration du mode automatique

Exemple

{
  "autoMode": {
    "environment": [
      "Contrôle de code source : github.example.com/acme-corp et tous les dépôts qu'il contient",
      "Compartiments cloud approuvés : s3://acme-build-artifacts, gs://acme-ml-datasets",
      "Domaines internes approuvés : *.corp.example.com, api.internal.example.com",
      "Principaux services internes : Jenkins sur ci.example.com, Artifactory sur artifacts.example.com"
    ],
    "allow": [
      "Le déploiement vers le namespace staging est autorisé",
      "L’écriture dans s3://acme-scratch/ est autorisée"
    ],
    "soft_deny": [
      "Ne jamais exécuter de migrations de base de données en dehors de la CLI migrations",
      "Ne jamais modifier les fichiers sous infra/terraform/prod/ : les changements de l’infrastructure de production passent par le workflow de revue"
    ]
  }
}

5. Mécanisme de repli

Si le classificateur bloque des opérations 3 fois d’affilée, ou 20 fois au total dans une session, le mode automatique se met en pause et Claude Code revient à demander une confirmation pour chaque opération.

/permissions  # 在 "最近拒绝" 选项卡查看被拒绝的操作

Relation entre le bac à sable et les permissions

Le bac à sable et les permissions sont des couches de sécurité complémentaires qui fonctionnent ensemble :

Aspect Permissions Bac à sable
Cible de contrôle Contrôle les outils que Claude Code peut utiliser Restreint le système de fichiers et le contenu réseau accessibles aux commandes Bash
Moment de l'évaluation Évalué avant l'exécution de tout outil S'applique uniquement aux commandes Bash et à leurs sous-processus
Portée d'application Tous les outils : Bash, Read, Edit, WebFetch, MCP, etc. Uniquement les commandes Bash

1. Activation du bac à sable

/sandbox

Exécutez/sandboxla commande pour activer le bac à sable ; un menu s'ouvrira pour sélectionner le mode bac à sable.

2. Configuration du bac à sable

Exemple

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowWrite": ["~/.kube", "/tmp/build"],    // Autoriser l'écriture vers ces chemins
      "denyWrite": ["~/important/**"],            // Bloquer l'écriture dans les répertoires importants
      "denyRead": ["~/"]                           // Bloquer la lecture du répertoire personnel
    },
    "network": {
      "httpProxyPort": 8080,                       // Port du proxy HTTP
      "socksProxyPort": 8081                       // Port du proxy SOCKS
    }
  }
}

Défense en profondeur :Les permissions et le bac à sable doivent être activés simultanément. Les règles de refus de permission empêchent Claude de tenter d'accéder à des ressources restreintes, tandis que les restrictions du bac à sable empêchent les commandes Bash d'atteindre des ressources au-delà des limites définies.

Étendre les permissions avec des hooks

Les hooks PreToolUse s'exécutent avant les invites de permission et peuvent :

  • Refuser les appels d'outils
  • Forcer une invite
  • Ignorer l'invite et laisser l'appel continuer

Exemple

#!/bin/bash
# Exemple de hook PreToolUse : intercepter les commandes dangereuses
COMMAND=$(cat | jq -r '.tool_input.command // empty')

if echo "$COMMAND" | grep -qE 'rm\s+(-[rf]+\s+)*(\/|~|\.\.\/)'; then
    echo "BLOQUÉ : rm sur un chemin sensible"
    exit 2  # Le code de sortie 2 bloque l'appel d'outil
fi
exit 0  # Autoriser à continuer

Important :Ignorer l'invite ne contourne pas les règles d'autorisation. Les règles « deny » et « ask » sont toujours évaluées après que le hook a renvoyé "allow". Lorsqu'un hook bloquant se termine avec le code de sortie 2, il arrête l'appel d'outil avant que les règles d'autorisation soient évaluées.

Définition de la priorité

Les paramètres de Claude Code prennent effet dans l'ordre de priorité suivant (du plus élevé au plus faible) :

  1. Paramètres gérés- Ne peuvent être remplacés par aucun autre niveau (contrôle administrateur)
  2. Arguments de ligne de commande- Remplacement temporaire pour la session
  3. Paramètres du projet local (.claude/settings.local.json)
  4. Paramètres du projet partagés (.claude/settings.json)
  5. Paramètres utilisateur (~/.claude/settings.json)

Règles clés :Si un outil est refusé à un niveau quelconque, aucun autre niveau ne peut l'autoriser.

Exemples de configuration pratiques

Exemple 1 : Mode conservateur (toutes les opérations nécessitent une approbation)

Convient à ceux qui débutent avec Claude Code ou qui travaillent sur des projets importants :

Exemple

{
  "permissions": {
    "defaultMode": "default"
  }
}

Exemple 2 : Configuration de développement courante (opérations de lecture autorisées, exécution de commandes nécessitant une approbation)

Adapté au développement quotidien : autoriser Claude à lire et rechercher librement le code, mais exiger une confirmation lors de la modification de fichiers et de l'exécution de commandes :

Exemple

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": [
      "Bash(git status *)",      // Voir git status
      "Bash(git log *)",         // Voir git log
      "Bash(git diff *)",       // Voir git diff
      "Bash(npm run *)",         // Exécuter les scripts npm
      "Bash(npm test *)",        // Exécuter les tests
      "Bash(ls *)",              // Lister les répertoires
      "Bash(grep *)"             // Rechercher du contenu
    ],
    "deny": [
      "Bash(rm *)",              // Supprimer des fichiers : bloquer directement
      "Bash(git push *)",        // Pousser le code : bloquer directement
      "Bash(mkdir / *)",         // Créer des répertoires système : bloquer directement
      "Edit(*.env)"              // Bloquer l'édition des fichiers .env
    ]
  }
}

Exemple 3 : Configuration d'environnement verrouillé (seules les opérations préapprouvées sont autorisées)

Convient aux pipelines CI ou aux environnements nécessitant un contrôle strict :

Exemple

{
  "permissions": {
    "defaultMode": "dontAsk",
    "allow": [
      "Read(*)",                  // Autoriser la lecture de tous les fichiers
      "Bash(npm run build *)",    // Autoriser les commandes de build
      "Bash(npm test *)"          // Autoriser l'exécution des tests
    ],
    "deny": [
      "Edit(*)",                  // Interdire toutes les modifications de fichiers
      "Bash(git *)",              // Interdire toutes les opérations git
      "Bash(curl *)",             // Interdire les requêtes réseau
      "Bash(ssh *)"               // Interdire les connexions SSH
    ]
  }
}

Exemple 4 : Autoriser l'accès multi-projets

Lorsque Claude doit travailler sur plusieurs répertoires de projet :

Exemple

{
  "permissions": {
    "allow": [
      "Edit(/src/**)",            // Izinkan mengedit direktori src
      "Edit(/docs/**)"            // Izinkan mengedit direktori dokumentasi
    ],
    "deny": [
      "Edit(/docs/**/*.md)"       // Larang mengedit file dokumentasi (hanya baca)
    ]
  },
  "additionalDirectories": [
    "~/projects/personal/**",     // Izinkan akses ke proyek pribadi
    "~/work/**",         // Izinkan akses ke proyek kerja
    "~/dotfiles/**"               // Izinkan akses ke file konfigurasi
  ]
}

Contoh 5: Menggunakan Sandbox untuk Membatasi Operasi Bash

Mengaktifkan sandbox memberikan perlindungan tambahan tingkat OS:

Exemple

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowWrite": ["/tmp/build", "~/projects/myapp/**"],
      "denyRead": ["~/secrets/**"]
    },
    "network": {
      "httpProxyPort": 8080
    }
  },
  "permissions": {
    "allow": [
      "Bash(*)",                  // Izinkan semua perintah di dalam sandbox
      "WebFetch(domain:api.github.com)"
    ],
    "deny": [
      "WebFetch(domain:untrusted.com)"
    ]
  }
}

Paramètres gérés (configuration administrateur)

Les administrateurs peuvent déployer des paramètres gérés qui ne peuvent pas être écrasés par les paramètres utilisateur ou de projet.

Paramètre Description
allowManagedHooksOnly Empêcher le chargement des hooks utilisateur, de projet et de plugin
allowManagedMcpServersOnly Respecter uniquement les serveurs MCP provenant des paramètres gérés
allowManagedPermissionRulesOnly Empêcher les paramètres utilisateur et de projet de définir des règles d'autorisation
sandbox.filesystem.allowManagedReadPathsOnly Respecter uniquement les chemins de lecture provenant des paramètres gérés
sandbox.network.allowManagedDomainsOnly Respecter uniquement les domaines autorisés provenant des paramètres gérés
permissions.disableBypassPermissionsMode Définir sur "disable" pour empêcher l'utilisation du mode bypassPermissions
permissions.disableAutoMode Définir sur "disable" pour empêcher l'utilisation du mode auto

Bonnes pratiques de sécurité

  1. Commencez par des restrictions: Commencez par le moindre privilège et étendez selon les besoins
  2. Utilisez le sandboxing: Les sandboxes offrent une protection supplémentaire au niveau du système d’exploitation et doivent être activées en complément
  3. Protégez les fichiers sensibles: Utilisezdenyrègles pour bloquer l’accès.env, fichiers clés, etc.
  4. Restreignez l’accès réseau: Autorisez uniquement l’accès aux domaines nécessaires pour éviter toute fuite de données
  5. Évitez bypassPermissions: À utiliser uniquement dans des environnements isolés (conteneurs, VM)
  6. Utilisez soft_deny du mode auto: Fournit des conseils de sécurité sans être trop restrictif
  7. Passez régulièrement en revue les configurations: Passez en revue les tentatives de violation du sandbox et les opérations refusées

Avertissement de sécurité :bypassPermissionsCe mode ne fournit pas de protection contre l’injection de prompt ou les actions non intentionnelles. Pour une alternative plus sûre qui conserve les contrôles de sécurité en arrière-plan, utilisez le mode auto.

Autres extensions