Permissions et sécurité - Tutoriel

Ce tutoriel vous guide pas à pas pour configurer les permissions et sécuriser Claude Code sur votre machine. Vous apprendrez à choisir le bon mode de permission, définir des règles allow/deny, activer le sandboxing et vous protéger contre les prompt injections. Durée totale : environ 25 minutes.

Les permissions et la sécurité de Claude Code constituent le socle de toute utilisation fiable de cet agent IA en ligne de commande. Claude Code propose several permission mechanisms, un système de sandboxing natif et des règles granulaires dans settings.json pour contrôler chaque action. many incidents liés aux agents IA proviennent d'une mauvaise configuration des permissions.

Quels sont les prérequis avant de configurer les permissions ?

Avant de commencer, vérifiez que votre environnement remplit ces conditions. Vous aurez besoin de Claude Code installé sur votre machine. Si vous passez par npm, il vous faut aussi Node.js. L'installation native (curl ... | bash) n'a, elle, pas besoin de Node.js.

• Node.js 18 ou supérieur installé, uniquement si vous installez via npm (node -v)
• Claude Code installé dans sa dernière version (claude --version)
• Un terminal avec accès au shell (zsh, bash)
• Un éditeur de texte pour modifier settings.json
• Environ 25 minutes devant vous

Si vous n'avez pas encore installé Claude Code, consultez le tutoriel d'installation et premier lancement qui couvre chaque étape en détail.

# Vérifiez vos versions
node -v # v18.x.x ou supérieur attendu (seulement pour l'installation npm)
claude --version # la dernière version attendu

En pratique, la grande majorité des erreurs de configuration viennent d'une version obsolète de Claude Code. Mettez à jour avant de continuer si votre version est inférieure à 2.1.

✅ Vérification : les deux commandes ci-dessus renvoient des versions compatibles.

À retenir : un environnement à jour est la première couche de sécurité de Claude Code.

Comment choisir le bon mode de permission ? (~5 min)

Claude Code offre 6 modes de permission via le flag --permission-mode qui déterminent le niveau d'autonomie de l'agent. Chaque mode représente un compromis entre productivité et contrôle. Sélectionnez le mode adapté à votre contexte.

En session, Shift+Tab ou Alt+M permet de cycler entre les modes sans redémarrer.

Le mode auto est une research preview. Il requiert Claude Code v2.1.83 ou supérieur, le modèle Opus 4.6+ ou Sonnet 4.6, et l'API Anthropic par défaut (sur Bedrock, Vertex ou Foundry, il faut l'activer explicitement via la variable d'environnement CLAUDE_CODE_ENABLE_AUTO_MODE=1, avec Opus 4.7 ou Opus 4.8). Il est accessible sur tous les plans, mais un administrateur doit l'activer sur les plans Team et Enterprise.

Étape 1 : Lancez Claude Code en mode Normal

Ouvrez votre terminal et démarrez Claude Code sans option supplémentaire.

claude

Le mode Normal est le mode par défaut. Claude Code vous demandera confirmation avant chaque opération de fichier ou commande shell. En pratique, ce mode convient à la majorité des développeurs au quotidien.

✅ Vérification : Claude Code démarre et affiche le prompt interactif.

Étape 2 : Pré-approuvez uniquement les outils de lecture via --allowedTools

Lancez Claude Code en pré-approuvant uniquement les outils de lecture via --allowedTools (n'utilisez pas --dangerously-skip-permissions).

claude --allowedTools "Read,Glob,Grep"

Ce mode autorise automatiquement les outils de lecture (Read, Glob, Grep) sans vous demander confirmation. Les opérations d'écriture restent soumises à validation.

✅ Vérification : Claude Code lit des fichiers sans afficher de prompt de confirmation.

Étape 3 : Activez le mode Plan pour les opérations sensibles

Appuyez sur Shift+Tab en session pour activer le mode Plan.

En mode Plan, Claude Code analyse votre demande, génère un plan d'action détaillé et attend votre approbation explicite avant toute modification. Le mode Plan est l'un des modes de permission (--permission-mode plan) : Claude Code lit les fichiers et exécute des commandes en lecture seule pour explorer, propose un plan, et n'effectue aucune modification de fichier avant votre validation. Les règles de permission allow/ask/deny continuent de s'appliquer comme en mode default.

Vérification : Claude Code affiche un plan structuré et attend votre validation avant d'agir.

Pour explorer les interactions de base avec Claude Code, le tutoriel sur vos premières conversations vous montre comment formuler des demandes efficaces.

À retenir : le mode Normal suffit pour le développement quotidien ; réservez le mode Bypass aux pipelines CI/CD automatisés et verrouillés.

Comment configurer les règles allow/deny dans settings.json ? (~5 min)

Le fichier settings.json de Claude Code permet de définir des règles granulaires pour autoriser ou bloquer des outils et des commandes spécifiques. Localisez d'abord ce fichier sur votre machine.

Où trouver settings.json ?

Le fichier se trouve dans le répertoire de configuration de Claude Code. Ouvrez-le avec votre éditeur préféré.

# Chemin par défaut sur macOS/Linux
cat ~/.claude/settings.json

Si le fichier n'existe pas, créez-le avec la structure minimale suivante :

{
 "permissions": {
 "allow": [],
 "deny": []
 }
}

Comment écrire des règles allow ?

Les règles allow définissent les outils que Claude Code peut utiliser sans demander confirmation. Chaque règle cible un outil ou une commande spécifique.

{
 "permissions": {
 "allow": [
 "Read",
 "Glob",
 "Grep",
 "Bash(git status)",
 "Bash(git diff)",
 "Bash(npm test)"
 ]
 }
}

Dans cet exemple, vous autorisez la lecture de fichiers, la recherche par motifs et trois commandes bash spécifiques. Claude Code exécutera ces actions sans confirmation. En pratique, cette configuration fait gagner un temps significatif sur les sessions de développement.

Comment écrire des règles deny ?

Les règles deny bloquent des outils ou commandes, même si l'utilisateur tente de les autoriser manuellement. Elles sont prioritaires sur les règles allow.

{
 "permissions": {
 "allow": ["Read", "Glob"],
 "deny": [
 "Bash(rm -rf *)",
 "Bash(git push --force *)",
 "Bash(curl *)",
 "Write(~/.ssh/*)"
 ]
 }
}

⚠️ Si vous voyez "Permission denied" sur une commande légitime : vérifiez que votre règle deny n'utilise pas un wildcard trop large. La syntaxe Bash(git*) bloque toutes les commandes git, y compris git status.

Le guide des erreurs courantes de permissions détaille les 10 messages d'erreur les plus fréquents et leurs solutions.

À retenir : les règles deny sont toujours prioritaires sur allow. Utilisez-les pour créer une liste noire de commandes dangereuses.

Comment activer le sandboxing avec Seatbelt et bubblewrap ? (~5 min)

Le sandboxing est une couche de sécurité système qui isole Claude Code du reste de votre machine. Le sandboxing restreint l'accès aux fichiers et aux appels système au niveau du noyau, indépendamment des permissions applicatives.

Qu'est-ce que Seatbelt (macOS) ?

Seatbelt est le framework de sandboxing natif de macOS. Une fois le sandbox de Claude Code activé, il s'appuie sur Seatbelt pour limiter les processus enfants à un ensemble restreint de répertoires et d'opérations réseau.

# Activez le sandbox pour le projet courant, puis consultez ses réglages
/sandbox

Le sandbox de Claude Code n'est pas actif par défaut. Activez-le pour le projet courant via la commande /sandbox, ou pour tous vos projets en ajoutant "sandbox": { "enabled": true } dans ~/.claude/settings.json. Sur macOS, il s'appuie ensuite sur le framework Seatbelt intégré (rien à installer). Une fois activé, il limite l'accès en écriture au répertoire de travail courant et à ses sous-répertoires uniquement. Pour autoriser l'écriture ailleurs (par exemple /tmp/build), ajoutez le chemin à sandbox.filesystem.allowWrite. Concrètement, un processus sandboxé ne peut pas écrire dans /etc, /usr ou votre répertoire personnel hors du projet.

Comment configurer bubblewrap sur Linux ?

Sur Linux et WSL2, le sandbox de Claude Code utilise bubblewrap (bwrap) et requiert aussi socat. Installez les deux paquets si ce n'est pas déjà fait.

# Debian/Ubuntu
sudo apt-get install bubblewrap socat

# Fedora
sudo dnf install bubblewrap socat

Vérifiez la disponibilité des dépendances via l'onglet Dependencies de la commande /sandbox, qui confirme la présence de bubblewrap, socat, ripgrep et seccomp. Un filtre seccomp optionnel est fourni par le paquet @anthropic-ai/sandbox-runtime.

Une fois le sandbox activé (sandbox.enabled: true ou /sandbox), Claude Code utilise bubblewrap pour isoler les commandes bash sur Linux. Le sandbox restreint l'écriture au répertoire de travail au niveau OS, mais ce n'est pas une isolation complète : la lecture reste autorisée par défaut sur le reste du disque (ajoutez ~/.aws, ~/.ssh à denyRead) et le filtrage réseau n'inspecte pas le TLS. Pour approfondir la configuration sécurisée de votre environnement, consultez les astuces de permissions et sécurité.

✅ Vérification : lancez la commande /sandbox dans une session et consultez l'onglet Config pour voir les réglages résolus, ou l'onglet Dependencies pour vérifier que bubblewrap, socat, ripgrep et seccomp sont disponibles.

⚠️ Si le sandbox reste inactif : vérifiez que bubblewrap et socat sont installés et que votre noyau Linux autorise bubblewrap à créer des user namespaces (sysctl kernel.apparmor_restrict_unprivileged_userns sur Ubuntu 24.04+ ; si la valeur vaut 1, ajoutez un profil AppArmor pour bwrap).

À retenir : le sandboxing ajoute une protection au niveau OS. Même si une règle allow est trop permissive, le sandbox restreint les écritures hors du répertoire de travail.

Comment se protéger contre les prompt injections ? (~5 min)

Une prompt injection est une technique où du contenu malveillant dans un fichier ou une réponse d'API tente de détourner le comportement de l'agent IA. Claude Code intègre plusieurs protections contre ce vecteur d'attaque.

Quels sont les types de prompt injection ?

Comment Claude Code détecte les injections ?

En mode auto, un classifieur évalue chaque appel d'outil avant son exécution et bloque les actions qui dépassent votre demande ou semblent guidées par du contenu hostile. Les résultats d'outils sont retirés du contexte du classifieur, et un probe côté serveur distinct scanne les résultats d'outils entrants pour signaler les contenus suspects avant que Claude ne les lise. Ce n'est pas une garantie : ne comptez pas sur une détection automatique pour bloquer une injection, utilisez des règles deny et un hook PreToolUse.

Configurez une protection supplémentaire en ajoutant ces règles dans votre settings.json :

{
 "permissions": {
 "deny": [
 "Bash(curl *)",
 "Bash(wget *)",
 "Bash(nc *)",
 "Write(*.env)",
 "Write(*credentials*)"
 ]
 }
}

Ces règles empêchent Claude Code d'exécuter des requêtes réseau sortantes ou d'écrire dans des fichiers sensibles comme .env. En pratique, la majorité des prompt injections réussies exploitent l'accès réseau pour exfiltrer des données.

Pour comprendre comment les serveurs MCP interagissent avec les permissions, explorez le tutoriel MCP : Model Context Protocol qui couvre la surface d'attaque MCP.

⚠️ Avant de valider une action déclenchée à partir de contenu externe (fichier lu, réponse d'API, sortie MCP) : examinez le fichier source et le contenu concerné. Ne vous reposez pas sur une détection automatique pour bloquer une injection.

À retenir : combinez les règles deny avec le sandboxing pour une défense en profondeur contre les prompt injections.

Comment structurer un settings.json complet et sécurisé ? (~3 min)

Voici un exemple complet de settings.json qui combine toutes les protections couvertes dans ce tutoriel. Copiez cette configuration et adaptez-la à vos besoins.

{
 "permissions": {
 "allow": [
 "Read",
 "Glob",
 "Grep",
 "Bash(git status)",
 "Bash(git diff)",
 "Bash(git log *)",
 "Bash(npm test)",
 "Bash(npm run lint)",
 "Bash(node --version)"
 ],
 "deny": [
 "Bash(rm -rf *)",
 "Bash(git push --force *)",
 "Bash(curl *)",
 "Bash(wget *)",
 "Bash(nc *)",
 "Write(~/.ssh/*)",
 "Write(*.env)",
 "Write(*credentials*)",
 "Write(*secret*)"
 ]
 }
}

Cette configuration autorise 9 commandes de lecture et de test tout en bloquant 9 patterns dangereux. Enregistrez le fichier et relancez Claude Code pour appliquer les changements.

# Validez la syntaxe JSON avant de relancer
python3 -c "import json; json.load(open('$HOME/.claude/settings.json'))"
claude

✅ Vérification : lancez claude et testez une commande autorisée (git status) puis une commande bloquée (curl example.com). La première s'exécute, la seconde est refusée.

Pour maîtriser les commandes slash qui interagissent avec ces permissions, consultez le tutoriel sur les commandes slash essentielles. Le démarrage rapide permissions et sécurité offre une version condensée de cette configuration.

À retenir : un settings.json bien structuré est votre première ligne de défense. Versionnez-le dans votre dépôt pour le partager avec votre équipe.

Comment auditer et vérifier votre configuration de sécurité ? (~3 min)

Une configuration de sécurité n'a de valeur que si vous la vérifiez régulièrement. Exécutez ces commandes pour auditer votre installation.

# 1. Vérifiez la version installée
claude --version

# 2. Affichez le diagnostic complet
claude doctor # diagnostic complet de l'installation et de la configuration

# 3. Listez les permissions actives
cat ~/.claude/settings.json

Checklist de sécurité

1. Vérifiez que le sandboxing est actif via la commande /sandbox (onglet Config)
2. Confirmez que les règles deny couvrent rm -rf, push --force et les commandes réseau
3. Contrôlez que settings.json ne contient pas de wildcard trop permissif dans allow
4. Testez une commande bloquée pour confirmer que les règles s'appliquent
5. Validez que les fichiers .env et credentials sont protégés en écriture

En pratique, une vérification de sécurité complète prend moins de 3 minutes et devrait être effectuée après chaque mise à jour de Claude Code. Le guide de gestion du contexte explique comment les fichiers CLAUDE.md peuvent renforcer vos instructions de sécurité.

Pour une vue d'ensemble de tous les aspects de sécurité, consultez la page permissions et sécurité de Claude Code qui centralise les concepts abordés ici.

À retenir : auditez votre settings.json à chaque mise à jour de Claude Code. Les nouvelles versions peuvent introduire de nouveaux outils nécessitant des règles.

Comment aller plus loin avec la sécurité de Claude Code ?

Vous maîtrisez maintenant les modes de permission, les règles allow/deny, le sandboxing et la protection contre les prompt injections. Voici les prochaines étapes pour renforcer votre usage de Claude Code.

Formations SFEIR Institute

Pour approfondir ces concepts avec des labs pratiques, la formation Claude Code de SFEIR Institute couvre en 1 jour l'ensemble des mécanismes de sécurité avec des exercices sur machine. Vous y configurerez un settings.json durci et testerez les limites du sandboxing en conditions réelles.

Si vous souhaitez intégrer Claude Code dans un workflow de développement complet et sécurisé, la formation Développeur Augmenté par l'IA sur 2 jours aborde les bonnes pratiques de sécurité dans le contexte d'une chaîne CI/CD avec plusieurs agents IA.

Pour les développeurs déjà expérimentés, la formation Développeur Augmenté par l'IA – Avancé en 1 jour traite des configurations multi-projets, des règles de permissions avancées et de l'audit automatisé.

Ressources complémentaires

• Explorez le tutoriel d'intégration Git pour sécuriser vos opérations Git avec Claude Code
• Consultez les erreurs courantes de permissions pour diagnostiquer rapidement les problèmes de configuration
• Testez les commandes slash de sécurité avec le tutoriel des commandes slash

À retenir : la sécurité de Claude Code repose sur trois couches (modes de permission, règles settings.json et sandboxing OS) qui se complètent mutuellement.