Accueil › Claude Code › Permissions

Claude Code Permissions : le guide complet pour sécuriser votre agent

Le système de permissions de Claude Code contrôle chaque action que l’agent exécute sur votre machine. Il repose sur quatre modes de permission, des règles allow/deny granulaires dans settings.json, et un sandboxing natif au niveau du système d’exploitation. Bien configuré, il réduit les invites de permission de 84% tout en protégeant contre les injections de prompts.

Pourquoi les permissions sont critiques

Claude Code n’est pas un outil de complétion de code. C’est un agent autonome qui tourne dans votre terminal avec les mêmes droits que votre utilisateur système. Il peut lire des fichiers, exécuter des commandes shell, modifier votre code, committer dans Git et accéder au réseau via des requêtes web ou des outils MCP.

Sans configuration de permissions, vous prenez trois risques concrets. L’injection de commande : un prompt malveillant (par exemple dans un fichier que Claude lit) pourrait le convaincre d’exécuter des commandes destructives. L’exfiltration de données : Claude pourrait lire des fichiers sensibles (.env, clés SSH, credentials AWS) et les exposer dans ses réponses. La modification non souhaitée : Claude pourrait modifier ou supprimer des fichiers en dehors du périmètre prévu, surtout quand il essaie d' »aider » en nettoyant ce qu’il perçoit comme des fichiers temporaires.

Le système de permissions résout ces problèmes en créant des barrières explicites entre ce que Claude peut faire automatiquement, ce qu’il doit demander, et ce qu’il ne peut jamais faire.

Les quatre modes de permission

Claude Code propose quatre modes qui déterminent le niveau d’autonomie de l’agent. Vous pouvez les cycler pendant une session avec Shift+Tab ou définir un mode par défaut dans votre settings.json.

Mode Normal (par défaut)

Le mode Normal demande votre approbation pour chaque action qui pourrait modifier votre système : écriture de fichiers, commandes Bash (sauf les commandes sûres comme echo ou cat), et outils MCP. Les lectures de fichiers sont autorisées par défaut.

C’est le mode recommandé pour 90% de l’utilisation quotidienne. La friction est réelle (vous cliquez beaucoup sur « approve »), mais c’est le seul mode où vous gardez une visibilité complète sur chaque action.

Mode Auto-accept (acceptEdits)

Ce mode auto-approuve les opérations sur les fichiers (lecture et écriture) pour que Claude puisse éditer du code sans interruption. Les autres outils (commandes Bash non liées au filesystem, outils MCP) passent toujours par le flux de permissions standard.

Utilisez-le quand vous faites confiance aux modifications de Claude et que vous voulez itérer plus vite, par exemple pendant le prototypage ou quand vous travaillez dans un répertoire isolé.

Mode Plan

En mode Plan, Claude analyse le code et crée des plans mais ne peut pas exécuter de modifications. Il peut utiliser l’outil AskUserQuestion pour clarifier les besoins avant de finaliser son plan. C’est l’équivalent d’un mode lecture seule avec recommandations.

Utilisez-le pour les revues de code, quand vous voulez approuver les changements avant leur exécution, ou quand vous explorez une codebase inconnue.

Mode Bypass (dangerously-skip-permissions)

Le mode Bypass désactive toutes les vérifications de permissions. Claude exécute n’importe quel outil sans demander confirmation. Les écritures dans .git, .claude, .vscode et .idea demandent toujours confirmation pour éviter la corruption accidentelle de l’état du dépôt.

Règles allow, ask et deny

Structure de base

Les règles vivent dans l’objet permissions de votre fichier settings.json. Trois types de règles sont disponibles.

allow : approuve automatiquement les outils correspondants, sans demander confirmation. Idéal pour les commandes sûres et fréquentes.

ask : force une confirmation même si une règle allow correspondante existe. Utile pour les actions que vous voulez vérifier avant exécution, comme git push.

deny : bloque complètement l’outil correspondant. Une règle deny l’emporte toujours sur une règle allow, quel que soit le niveau de configuration.

{
  "permissions": {
    "allow": [
      "Bash(npm run build)",
      "Bash(npm test *)",
      "Bash(npx eslint *)",
      "Bash(git status)",
      "Bash(git diff *)",
      "Read(*)"
    ],
    "ask": [
      "Bash(git push *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(curl *)",
      "Bash(wget *)",
      "Read(./.env)",
      "Read(./secrets/**)"
    ]
  }
}

L’évaluation suit un ordre strict : deny d’abord, puis ask, puis allow. La première règle correspondante gagne. Cette hiérarchie vous permet de créer des politiques de type « autoriser tout sauf » en combinant des allows larges avec des denys ciblés.

Types d’outils et syntaxe

Chaque règle suit le format Outil ou Outil(spécificateur). Voici les outils disponibles et leur syntaxe.

Bash : commandes shell. Supporte les patterns glob avec *. L’espace avant * compte : Bash(ls *) matche ls -la mais pas lsof, tandis que Bash(ls*) matche les deux. Claude Code comprend les opérateurs shell : une règle comme Bash(safe-cmd *) ne matchera pas safe-cmd && malicious-cmd.

Read et Edit : accès aux fichiers. Utilisent une syntaxe similaire à .gitignore pour les chemins. Un pattern comme /src/**/*.ts est relatif à la racine du projet. Pour un chemin absolu, utilisez le préfixe double slash : //Users/alice/file. Sur Windows, les chemins sont normalisés en POSIX (C:Usersalice devient /c/Users/alice).

WebFetch : requêtes réseau. Autorisez des domaines spécifiques, par exemple WebFetch(domain:docs.anthropic.com) pour laisser Claude consulter la documentation sans demander.

MCP : outils de serveurs MCP connectés. Vous pouvez autoriser ou bloquer des outils MCP spécifiques.

Skill : invocation de skills. Skill(commit) pour un match exact, Skill(review-pr *) pour un match par préfixe.

Configurations types

Configuration développeur solo (équilibrée) :

{
  "permissions": {
    "allow": [
      "Bash(npm *)",
      "Bash(npx *)",
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(git add *)",
      "Bash(git commit *)",
      "Bash(ls *)",
      "Bash(mkdir *)",
      "Bash(cat *)",
      "Bash(find *)",
      "Bash(grep *)",
      "Bash(rg *)",
      "Read(*)",
      "Edit(*)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(git checkout *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(curl *)",
      "Bash(wget *)",
      "Read(**/.env)",
      "Read(**/.env.*)",
      "Read(**/secrets/**)"
    ]
  }
}

Configuration équipe (stricte, à versionner) :

{
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)",
      "Bash(npm run build)",
      "Bash(git status)",
      "Bash(git diff *)"
    ],
    "deny": [
      "Bash(rm *)",
      "Bash(curl *)",
      "Bash(wget *)",
      "Bash(nc *)",
      "Bash(docker *)",
      "Read(**/.env)",
      "Read(**/.env.*)",
      "Read(**/secrets/**)",
      "Read(**/.ssh/**)",
      "Read(**/credentials/**)"
    ]
  }
}

La hiérarchie des fichiers de configuration

Claude Code gère les permissions via plusieurs fichiers qui se superposent. Comprendre leur hiérarchie est essentiel pour éviter les surprises.

Les niveaux de configuration

Du plus prioritaire au moins prioritaire :

1. Managed settings (administrateur) : fichiers système qui ne peuvent être surchargés par aucun autre niveau, y compris les arguments en ligne de commande. Nécessitent des privilèges administrateur pour être modifiés. Utilisés par les organisations pour appliquer des politiques de sécurité obligatoires.

2. Arguments en ligne de commande : surcharges temporaires pour la session (--allowedTools, --disallowedTools).

3. Local project settings (.claude/settings.local.json) : vos ajustements personnels pour le projet en cours. Ce fichier est ignoré par Git, donc il ne sera pas partagé avec votre équipe.

4. Project settings (.claude/settings.json) : la configuration partagée du projet, versionnée dans Git. Toute l’équipe hérite de ces règles.

5. User settings (~/.claude/settings.json) : vos préférences globales personnelles, appliquées à tous les projets.

La règle fondamentale : si un outil est denied à n’importe quel niveau, aucun autre niveau ne peut l’autoriser. Un deny dans les managed settings ne peut pas être surchargé par --allowedTools. Un deny dans les project settings bloque même si vos user settings l’autorisent.

La commande /permissions

Tapez /permissions dans Claude Code pour voir et gérer toutes les règles de permission via une interface interactive. Cette UI liste toutes les règles et indique de quel fichier settings.json elles proviennent. Vous pouvez ajouter ou retirer des outils de l’allowlist directement depuis cette interface, par exemple ajouter Edit pour toujours autoriser les modifications de fichiers, ou Bash(git commit:*) pour les commits Git.

Vous pouvez aussi ajouter des permissions à la volée : quand Claude demande une approbation pendant une session, sélectionnez « Always allow » pour ajouter automatiquement la commande à votre allowlist.

Sandboxing : l’isolation au niveau OS

Permissions vs Sandbox

Les permissions et le sandboxing sont deux couches de sécurité complémentaires qui forment une défense en profondeur.

Les permissions contrôlent quels outils Claude peut utiliser et quels fichiers ou domaines il peut accéder. Elles s’appliquent à tous les outils (Bash, Read, Edit, WebFetch, MCP, etc.).

Le sandboxing fournit une isolation au niveau du système d’exploitation qui restreint l’accès du filesystem et du réseau pour les commandes Bash et leurs processus enfants. C’est la couche qui protège même en cas d’injection de prompt réussie.

La distinction clé : une règle Read(./.env) dans les deny bloque l’outil Read de Claude, mais ne bloque pas cat .env exécuté via Bash. Le sandbox, lui, bloque tous les processus d’accéder au fichier, quel que soit le chemin d’exécution. C’est pourquoi Anthropic recommande d’utiliser les deux ensemble.

Activer le sandboxing

Lancez /sandbox dans Claude Code pour activer le sandboxing. La réduction des invites de permission peut atteindre 84% selon Anthropic, car Claude peut travailler librement à l’intérieur des limites définies.

macOS : utilise Seatbelt, le framework de sandboxing natif d’Apple. Claude Code génère automatiquement un profil .sb qui restreint l’accès aux fichiers, au réseau et aux processus. Fonctionne sans configuration supplémentaire.

Linux : utilise bubblewrap (bwrap) pour la conteneurisation. Prérequis : bubblewrap et socat installés, user namespaces activés (par défaut sur la plupart des distributions). Installation : sudo apt install bubblewrap socat (Debian/Ubuntu) ou sudo dnf install bubblewrap socat (Fedora).

Windows : pas de support natif du sandboxing. Deux options : utiliser WSL 2 (avec bubblewrap installé dans la distribution WSL) ou Docker. WSL 1 ne supporte pas le sandboxing.

Comportement par défaut du sandbox

Une fois activé, le sandbox impose deux types d’isolation.

Isolation du filesystem. Les commandes Bash ne peuvent lire et écrire que dans le répertoire de travail courant. Toute opération d’écriture en dehors (y compris echo >, touch, mkdir, cp) échoue avec une erreur « Read-only file system ». Pour autoriser l’écriture dans des répertoires supplémentaires, utilisez des règles Edit dans vos allow.

Isolation réseau. Les requêtes réseau sont routées via des sockets Unix domain vers un serveur proxy qui tourne en dehors du sandbox. Ce proxy applique les restrictions de domaines autorisés et demande confirmation pour les nouveaux domaines. Sur Linux, le namespace réseau est retiré du container bubblewrap, garantissant que tout le trafic passe par les proxies.

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "allowedDomains": [
      "registry.npmjs.org",
      "github.com",
      "api.anthropic.com"
    ]
  },
  "permissions": {
    "allow": [
      "Edit(/home/user/project/**)"
    ],
    "deny": [
      "Read(**/.env)",
      "Read(**/.ssh/**)"
    ]
  }
}

Hooks de permissions

Les hooks offrent un contrôle programmatique des permissions au-delà des règles statiques. Un hook PreToolUse s’exécute avant l’invite de permission et peut prendre trois décisions : deny (bloquer l’appel), force prompt (forcer la confirmation), ou skip prompt (laisser passer).

Le skip de prompt ne contourne pas les règles de permission. Les deny et ask restent évalués après qu’un hook retourne « allow ». Cela préserve la priorité du deny décrite plus haut, y compris les deny dans les managed settings.

Exemple pratique : un hook qui exécute ESLint après chaque modification de fichier pour s’assurer que Claude ne committe que du code propre.

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit",
        "command": "npx eslint --fix $FILE_PATH"
      }
    ]
  }
}

Contrairement aux instructions dans CLAUDE.md qui sont « consultatives » (Claude peut les ignorer), les hooks sont déterministes et garantissent que l’action se produit à chaque fois.

Managed settings pour les organisations

Pour les équipes sur les plans Team et Enterprise, les managed settings permettent de déployer des configurations de sécurité que personne ne peut surcharger.

Ces fichiers sont placés dans des répertoires système (pas les répertoires home utilisateur) et nécessitent des privilèges administrateur pour être modifiés. Ils suivent le même format que les fichiers settings.json normaux mais prennent la priorité la plus haute dans la hiérarchie.

Cas d’usage typiques pour les managed settings : bloquer le mode Bypass pour toute l’organisation, interdire l’accès aux fichiers .env et credentials, restreindre les domaines réseau autorisés, et imposer des timeouts de session.

{
  "permissions": {
    "deny": [
      "Read(**/.env)",
      "Read(**/.env.*)",
      "Read(**/.ssh/**)",
      "Read(**/credentials/**)",
      "Bash(curl *)",
      "Bash(wget *)",
      "Bash(nc *)"
    ]
  },
  "disableBypassPermissionsMode": "disable"
}

Protection contre les injections de prompts

L’injection de prompt est le risque de sécurité le plus sérieux avec les agents de code IA. Un contenu malveillant dans un fichier, une réponse API ou un CLAUDE.md d’un dépôt externe peut manipuler Claude pour exécuter des actions non souhaitées.

Couches de défense

Claude Code intègre plusieurs couches de défense. Le système de permissions lui-même est la première ligne : même si un prompt injecté demande à Claude d’exécuter rm -rf /, le mode Normal exige votre confirmation. Les deny rules bloquent les commandes quel que soit le contenu du prompt.

Claude Code affiche un avertissement quand le résultat d’un outil semble contenir une tentative d’injection. Lisez attentivement ces avertissements et rejetez l’action si le contenu semble suspect.

Le sandboxing est la couche ultime : même si une injection réussit à bypasser les permissions de Claude, le sandbox empêche l’accès aux ressources en dehors des limites définies au niveau OS. Un Claude compromis ne peut pas voler vos clés SSH ou contacter un serveur externe.

Bonnes pratiques

Quand vous clonez un dépôt inconnu, vérifiez toujours le contenu du CLAUDE.md et du .claude/settings.json avant de lancer Claude Code. Ces fichiers peuvent contenir des instructions cachées conçues pour manipuler l’agent.

Bloquez systématiquement les commandes réseau sortantes (curl, wget, nc) dans vos deny rules. En mode Normal, elles demandent confirmation. En mode Auto-accept, elles s’exécutent sans demander. Mettez-les toujours en deny global.

Désactivez l’accès réseau dans le sandbox ("networkAccess": false) pour tout projet manipulant des données confidentielles ou des secrets API.

Permissions en CI/CD

Le contexte CI/CD a des besoins spécifiques. Vous voulez que Claude fonctionne de manière autonome (pas de confirmation manuelle) tout en restant dans un périmètre strict.

L’approche Docker

L’option la plus sûre pour les pipelines automatisés : exécutez Claude Code dans un container Docker avec le flag --dangerously-skip-permissions. Le container lui-même fournit l’isolation, pas les permissions de Claude.

docker run --rm -it 
  -v $(pwd):/workspace 
  -e ANTHROPIC_API_KEY=$ANTHROPIC_API_KEY 
  claude-code:latest 
  claude --dangerously-skip-permissions 
  -p "Exécute les tests et corrige les échecs"

Le double sandboxing (Docker + sandbox natif de Claude Code) réduit la surface d’attaque de manière significative par rapport à une exécution sans isolation.

L’approche GitHub Actions

Pour les workflows GitHub Actions, restreignez les outils via --allowedTools :

- uses: anthropics/claude-code-action@v1
  with:
    anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
    claude_args: >-
      --allowedTools 'Read,Write,Bash(npm test),Bash(npm run lint)'
      --max-turns 5
      --max-budget-usd 3.00
  timeout-minutes: 15

Dépannage courant

Ma règle allow ne fonctionne pas

La cause la plus probable est une règle deny conflictuelle à un niveau supérieur. Vérifiez la hiérarchie : managed settings > arguments CLI > local project > project > user. Utilisez /permissions pour voir toutes les règles actives et identifier les conflits.

Ma règle deny est ignorée via Bash

Les règles Read et Edit deny bloquent les outils intégrés de Claude (Read, Edit, Grep, Glob, LS), mais elles ne bloquent pas les commandes Bash qui lisent le même fichier. Read(./.env) deny bloque l’outil Read mais pas cat .env via Bash. La solution : activez le sandboxing pour une isolation au niveau OS, ou ajoutez des deny Bash spécifiques.

Le sandbox ne démarre pas

Sur Linux, vérifiez que bubblewrap et socat sont installés. Vérifiez que les user namespaces sont activés (sysctl kernel.unprivileged_userns_clone doit retourner 1). Si vous êtes dans un container Docker, le sandbox standard peut ne pas fonctionner à cause des namespaces manquants. Utilisez /doctor pour diagnostiquer les problèmes.

Questions fréquentes