Structuré avec Claude

Permissions & sécurité

Dans la page Setup, on a vu les trois niveaux de config — global, projet, settings.local. Les permissions suivent exactement cette même hiérarchie. Commençons par ce qui presse le plus : protéger ce que Claude ne doit pas toucher.

Claude Code a accès à ton filesystem par défaut. Cette page explique comment contrôler précisément ce qu’il peut lire, modifier et exécuter.

Protéger ses fichiers sensibles

La première chose à faire sur tout projet : empêcher Claude de lire tes secrets.

Crée ou modifie .claude/settings.json à la racine du projet :

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(./config/credentials.json)"
    ]
  }
}

Ces règles excluent les fichiers des recherches et bloquent toute lecture par les outils built-in de Claude.

Note : L’ancienne config ignorePatterns est dépréciée. Utilise permissions.deny avec des règles Read().

📁 projet/
├── src/                      ✓ accessible
├── README.md                 ✓ accessible
├── .env                      ✗ bloqué
├── .env.local                ✗ bloqué
├── secrets/                  ✗ bloqué
└── config/
    └── credentials.json      ✗ bloqué

Le système de permissions

Chaque action que Claude tente passe par un système de règles en trois niveaux, évalués dans cet ordre :

Priorité	Règle	Effet
1 (gagne toujours)	deny	Bloqué, sans demande
2	ask	Demande confirmation à chaque fois
3	allow	Exécuté sans prompt

100%

Types d’outils et approbation par défaut

Type d’outil	Exemples	Approbation requise par défaut
Lecture seule	Read, Grep, Glob	Non
Exécution bash	Commandes shell	Oui
Modification fichiers	Edit, Write	Oui

Syntaxe des règles

Les règles s’écrivent Outil ou Outil(specifier) :

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)",
      "WebFetch(domain:github.com)"
    ],
    "deny": [
      "Bash(git push *)",
      "Read(./.env)"
    ]
  }
}

Les patterns supportent * (un segment de chemin) et ** (récursif), comme gitignore.

Les modes de permission

Le defaultMode contrôle le comportement global. À configurer dans .claude/settings.json :

Mode	Description
default	Demande à la première utilisation de chaque outil
acceptEdits	Accepte automatiquement les modifications de fichiers
plan	Claude analyse mais ne modifie rien ni n’exécute de commandes
dontAsk	Refuse tout sauf ce qui est pré-approuvé
bypassPermissions	Ignore les prompts de permission

⚠️ bypassPermissions : à utiliser uniquement dans des environnements isolés (containers, VMs). Les admins peuvent le désactiver avec disableBypassPermissionsMode: "disable" dans les managed settings.

Le mode plan est particulièrement utile quand tu veux que Claude analyse du code critique sans risque de modification accidentelle.

Hiérarchie des settings

Quand plusieurs niveaux de config définissent des règles, la priorité s’applique ainsi — le niveau le plus haut gagne :

Priorité	Source	Portée
1 — gagne toujours	Managed settings (IT/MDM)	Tous les utilisateurs de la machine
2	Arguments CLI (--allowedTools, --disallowedTools)	Session en cours
3	.claude/settings.local.json	Toi, ce projet (non commité)
4	.claude/settings.json	Toute l’équipe (versionné)
5 — perd toujours	~/.claude/settings.json	Toi, tous tes projets

Règle clé : si un outil est en deny à n’importe quel niveau, aucun niveau inférieur ne peut le ré-autoriser.

Fichier à ne jamais commiter : .claude/settings.local.json (Claude Code l’ajoute automatiquement au .gitignore).

Deux couches de sécurité

Les permissions et le sandboxing sont complémentaires, pas interchangeables :

100%

Exemple concret : une règle "Read(./.env)" en deny bloque le tool Read de Claude — mais pas cat .env exécuté dans un bash. Le sandboxing, lui, bloque aussi les commandes shell.

Pour une sécurité maximale : utilise les deux.

Bonnes pratiques

• Ne jamais commiter .claude/settings.local.json — contient tes surcharges locales
• Versionner .claude/settings.json — partage les règles deny avec ton équipe
• Utiliser le mode plan sur du code critique ou en code review
• Auditer tes règles actives avec /permissions dans le chat
• Préférer WebFetch à curl quand tu veux filtrer par domaine — les règles bash sont fragiles sur les URLs

---

Pour aller plus loin : documentation officielle sandboxing — isolation OS-level pour les commandes bash.