Permissions Claude Code : sécuriser settings.json simplement

Vous demandez simplement à Claude Code de lancer les tests, mais une fenêtre d’autorisation apparaît à chaque commande. En autorisant tout Bash pour gagner du temps, vous ouvrez aussi la porte à un force push ou à une suppression destructive.

Il n’est pas nécessaire de choisir entre des confirmations permanentes et un accès illimité. Un bon point de départ consiste à autoriser automatiquement la lecture et les tests, à demander confirmation pour les modifications et les actions externes, puis à bloquer les secrets et les commandes destructives. Ces trois niveaux se configurent dans settings.json.

À retenir

Les règles sont évaluées dans l’ordre deny → ask → allow. Une règle allow plus précise ne l’emporte pas sur une règle deny ou ask correspondante.
Les lectures dans le projet ne demandent déjà pas d’autorisation. Placez seulement les tests vérifiés dans allow, les modifications, accès externes et pushs dans ask, puis les secrets et opérations destructives dans deny.
Bash(git *) est trop large pour la plupart des dépôts. Cette règle couvre aussi git reset --hard et git push --force.
Read(.env) n’empêche pas tous les processus enfants d’ouvrir ce fichier. Pour une isolation imposée par le système d’exploitation, ajoutez la sandbox.
Après toute modification, /permissions et /status indiquent les règles et les sources de configuration réellement actives.

Ce que Claude Code peut faire et ce qu’une personne doit décider

À confier à Claude Code	Validation humaine	À bloquer systématiquement
Recherche de fichiers, lecture du diff, tests	Modification de fichiers, commit, push, ajout de dépendances	Lecture de secrets, force push, hard reset, suppression en masse
`Read`, `Grep`, `git diff`	`Edit`, `git commit`, `npm install`	`.env`, `git push --force`, `git reset --hard`, `rm -rf`

Une opération difficile à annuler, qui envoie des données à l’extérieur ou qui touche aux identifiants doit rester dans ask ou deny.

Commencer avec ce settings.json

Créez .claude/settings.json à la racine du dépôt. La configuration suivante constitue une base prudente à partager avec une équipe.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Bash(npm test *)",
      "Bash(npm run lint *)"
    ],
    "ask": [
      "Edit",
      "WebFetch",
      "Bash(git add *)",
      "Bash(git commit *)",
      "Bash(git push *)",
      "Bash(git clean *)",
      "Bash(git restore *)",
      "Bash(npm install *)",
      "Bash(npm uninstall *)"
    ],
    "deny": [
      "Read(.env)",
      "Read(.env.*)",
      "Read(**/secrets/**)",
      "Edit(.env)",
      "Edit(.env.*)",
      "Edit(**/secrets/**)",
      "Bash(git push --force *)",
      "Bash(git reset --hard *)",
      "Bash(rm -rf *)",
      "Bash(rm *)",
      "PowerShell(Remove-Item *)"
    ]
  }
}

Cette base suppose que vous avez relu les scripts de package.json. Dans un dépôt inconnu, laissez allow vide jusqu’à ce que vous sachiez ce que lance réellement le test. Bash(npm test *) couvre npm test et ses variantes avec arguments.

Où placer settings.json

Portée	Emplacement	Usage
User	`~/.claude/settings.json`	Vos règles par défaut pour tous les projets
Project	`.claude/settings.json`	Les règles d’équipe versionnées avec Git
Local	`.claude/settings.local.json`	Vos réglages sur cette machine ; ne pas les committer
Managed	Configuration distribuée par un administrateur	Les règles d’organisation non modifiables par les utilisateurs

L’ordre de priorité est Managed, ligne de commande, Local, Project, puis User. Les tableaux comme permissions.allow sont concaténés entre les sources, pas remplacés en bloc. Une règle deny correspondante reste évaluée avant ask et allow. Placez les protections communes dans Project et les politiques non négociables dans Managed.

Comprendre allow, ask et deny

Règle	Signification
`Read`	Couvre toutes les lectures intégrées ; un allow global est normalement inutile dans le projet
`Bash(npm test)`	Correspond exactement à `npm test`
`Bash(npm test *)`	Correspond à `npm test`, avec ou sans arguments supplémentaires
`Bash(ls*)`	Correspond à `ls -la`, mais aussi à `lsof` : la règle est plus large qu’elle n’en a l’air
`Read(//Users/me/secrets/**)`	Cible un chemin absolu du système de fichiers
`Edit(/src/*/.ts)`	Dans Project, cible les fichiers sous `src` à la racine du dépôt
`WebFetch(domain:docs.anthropic.com)`	Cible les requêtes WebFetch vers ce domaine

Bash(git *) inclut aussi git push origin main et git reset --hard. Autorisez séparément les commandes sûres plutôt que toute la famille Git.

Pourquoi Read et Edit ne suffisent pas à protéger les secrets

Les chemins des règles Read et Edit suivent la syntaxe de gitignore.

Motif	Point d’ancrage	Exemple
`//path`	Racine du système de fichiers	`Read(//Users/me/secrets/**)`
`~/path`	Dossier personnel	`Read(~/.ssh/**)`
`/path`	Emplacement associé à la source de configuration	Dans Project, `Edit(/src/**)` cible `src` dans le dépôt
`path` ou `./path`	Répertoire de travail courant	`Read(.env)`

Dans une règle Read ou Edit, un seul slash initial ne représente pas un chemin absolu du système de fichiers. Surtout, ces règles couvrent les outils de fichiers intégrés à Claude Code et les commandes de fichiers reconnues. Elles n’empêchent pas un processus Node.js ou Python quelconque d’ouvrir directement un fichier.

Si le dépôt contient des identifiants, combinez ces règles avec le guide des validations et de la sandbox Claude Code afin que le système d’exploitation limite aussi les processus enfants.

Trois cas d’usage

Use case 1 : automatiser uniquement les tests d’un projet personnel

Entrée : code source, tests et diff Git. Sortie : proposition de correction et résultats des tests. Décision humaine : modifications, nouvelles dépendances, commit et push.

Commencez avec la configuration de base et conservez les modifications dans ask. Ne déplacez une commande vers allow qu’après l’avoir vue s’exécuter plusieurs fois sans modifier d’état externe.

Use case 2 : partager les opérations interdites dans une équipe

Entrée : commandes nécessaires et opérations que l’équipe refuse d’automatiser. Sortie : politique de permissions suivie dans Git. Décision humaine : ajout de règles deny et travaux de maintenance exceptionnels.

Conservez dans Project les interdictions portant sur .env, le force push, le hard reset et la suppression récursive. Déplacez dans Managed les règles que les membres de l’équipe ne doivent pas pouvoir modifier.

Use case 3 : examiner un dépôt de production sans le modifier

Entrée : journaux d’incident et historique Git. Sortie : causes probables et plan de correction. Décision humaine : modification, déploiement et communication externe.

Démarrez la session en Plan mode :

claude --permission-mode plan

Si une écriture devient nécessaire, passez d’abord dans un worktree isolé ou un environnement jetable avant de l’approuver.

Quatre erreurs concrètes à éviter

Erreur	Cause	Correction
Autoriser `Bash(git *)`	Le motif couvre aussi push et hard reset	N’autorisez que les commandes dont les effets ont été vérifiés
Ajouter `allow: Bash(aws s3 ls)` sous `deny: Bash(aws *)`	Deny gagne avant ask et allow ; la précision ne crée pas d’exception	Réduisez le deny ou séparez l’opération sûre derrière une autre commande
Considérer `Read(.env)` comme une isolation système	Un processus Node.js ou Python arbitraire n’est pas entièrement bloqué	Ajoutez `denyRead` ou les règles credentials de la sandbox
Supprimer un allow Local sans effet	Les tableaux s’additionnent entre User, Project et Local	Consultez la source dans `/permissions` et les niveaux dans `/status`

Les échecs de sécurité Claude Code détaillent les incidents ; les bonnes pratiques de sécurité couvrent la vérification complète du déploiement.

Choisir un permission mode

Mode	Adapté à	Limite à connaître
`default`	Un dépôt que vous découvrez	Demande une autorisation lorsque c’est nécessaire
`acceptEdits`	Un développement dont le périmètre de modification est compris	Les modifications de fichiers et les opérations courantes sur le système de fichiers peuvent être approuvées automatiquement
`plan`	Analyse, conception et diagnostic en lecture seule	Ne modifie pas les fichiers source
`auto`	Essai des contrôles de sécurité en arrière-plan	Approuve automatiquement les appels jugés conformes à la demande ; vérifiez le comportement de la version utilisée
`dontAsk`	Tâche sans surveillance limitée aux opérations préapprouvées	Refuse les outils non autorisés au lieu d’afficher une demande
`bypassPermissions`	Conteneur ou machine virtuelle jetable	À proscrire sur un poste normal ou un serveur de production

Lorsque la sandbox est activée, sandbox.autoAllowBashIfSandboxed vaut true par défaut. Les commandes Bash exécutées dans la sandbox peuvent donc s’exécuter sans la demande générale portant sur tout Bash. Les règles ask ciblées comme Bash(git push *) continuent à demander confirmation, les règles deny explicites restent actives et le Plan mode conserve ses propres restrictions.

Pitfall : compenser une autorisation trop large avec un seul hook

Autoriser tout Bash en comptant sur un hook PreToolUse pour reconnaître chaque variante dangereuse transforme ce hook en unique barrière de sécurité. Un hook non chargé ou un motif incomplet expose alors une surface de commandes très large.

Cause : le périmètre autorisé est vaste et le contrôle dynamique constitue la seule protection.

Correction : écrivez d’abord des règles deny explicites et des règles allow étroites. Utilisez les hooks comme couche supplémentaire uniquement lorsque la décision dépend réellement du contexte d’exécution. Le résultat allow d’un hook ne remplace pas une règle deny ou ask correspondante.

Contrôle de configuration prêt à copier

Le script suivant vérifie que .claude/settings.json contient du JSON valide et quatre règles deny minimales.

// scripts/check-claude-permissions.mjs
import { readFileSync } from "node:fs";

const path = ".claude/settings.json";
const settings = JSON.parse(readFileSync(path, "utf8"));
const deny = new Set(settings.permissions?.deny ?? []);
const required = [
  "Read(.env)",
  "Edit(.env)",
  "Bash(git push --force *)",
  "Bash(git reset --hard *)",
  "Bash(rm *)",
  "PowerShell(Remove-Item *)",
];

const missing = required.filter((rule) => !deny.has(rule));
if (missing.length > 0) {
  console.error(`Règles deny manquantes : ${missing.join(", ")}`);
  process.exit(1);
}

console.log("Contrôle minimal des permissions : OK");

node scripts/check-claude-permissions.mjs

Ce contrôle ne prouve pas que toute la configuration est sûre. Il sert uniquement de garde-fou CI lorsqu’une règle deny minimale disparaît.

Si les règles semblent ne pas fonctionner

Ouvrez /permissions et examinez chaque règle ainsi que son fichier source.
Lancez /status pour vérifier les niveaux de configuration chargés.
Contrôlez les espaces et les ancres, par exemple Bash(ls *) contre Bash(ls*), ou /path contre //path.
Vérifiez l’approbation automatique de la sandbox et les règles deny ou ask provenant d’une source prioritaire.
Replacez dans .claude/settings.json les règles à partager, au lieu de les laisser sous forme d’options CLI temporaires.

Résumé

Créez .claude/settings.json, collez la configuration et inspectez-la avec /permissions. Placez seulement les tests vérifiés dans allow, les modifications et actions externes dans ask, les secrets et opérations destructives dans deny.

Pour réutiliser ces modèles de permissions avec d’autres règles de développement, consultez les guides produits Claude Code.

Sources officielles

Ce qui a réellement été testé

Le 22 juillet 2026, le bloc JSON des dix langues a été analysé avec JSON.parse, puis le contrôle Node.js a été exécuté dans un projet temporaire. Avec les six règles deny requises, le code de sortie était 0 ; sans Bash(git reset --hard *), il était 1 et citait la règle manquante. Ce test détecte une dérive de configuration, sans prouver la sécurité de la politique. Vérifiez /permissions et /status dans votre environnement.