Permissions et sécurité - Démarrage rapide

Configurez les permissions et le sandboxing de Claude Code en moins de 5 minutes grâce à ce guide de démarrage rapide. Vous apprendrez à choisir le bon mode de permission, définir des règles allow/deny dans settings.json, et activer la protection contre les injections de prompt.

la sécurité des permissions Claude Code est un ensemble de mécanismes (modes de permission, règles allow/deny et sandboxing) qui protègent votre environnement de développement contre les exécutions non autorisées. many incidents liés aux agents IA proviennent d'une mauvaise configuration des permissions. Ce guide vous permet de sécuriser votre installation en 5 étapes concrètes, sans théorie superflue.

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

Avant de commencer, vérifiez que vous disposez de ces éléments :

• Claude Code installé (guide d'installation pas à pas)
• Node.js 18 ou supérieur (uniquement si vous installez via npm)
• Un terminal avec accès au répertoire ~/.claude/
• 5 minutes devant vous

Lancez cette commande pour confirmer votre version :

claude --version

Le numéro affiché doit être supérieur ou égal à 2.1.0. Si ce n'est pas le cas, consultez le démarrage rapide de l'installation pour mettre à jour.

À retenir : le sandboxing ne dépend pas de la version de Node.js. Il repose sur les primitives du système d'exploitation (Seatbelt sur macOS, bubblewrap + socat sur Linux/WSL2).

Comment choisir le bon mode de permission ?

Claude Code propose 6 modes de permission via le flag --permission-mode. Chaque mode définit le niveau d'autonomie accordé à l'agent. En pratique, la grande majorité des développeurs utilisent le mode default au quotidien.

Lancez Claude Code dans le mode souhaité avec --permission-mode :

# Mode default (défaut)
claude

# Mode acceptEdits - pour le développement courant
claude --permission-mode acceptEdits

# Mode plan - analyse avant action
claude --permission-mode plan

# En session, utilisez Shift+Tab ou Alt+M pour cycler entre les modes

Le mode default est recommandé si vous découvrez l'outil. Il vous demande confirmation avant chaque action sensible, ce qui vous permet de comprendre le comportement de l'agent. En session, utilisez Shift+Tab ou Alt+M pour cycler entre les modes de permission. Consultez le tutoriel des premières conversations pour voir ces modes en action.

À retenir : démarrez en mode default pour apprendre, utilisez Shift+Tab/Alt+M pour cycler entre les modes, puis passez en acceptEdits une fois à l'aise.

Comment configurer les règles allow/deny dans settings.json en 5 minutes ?

Les règles allow/deny dans settings.json constituent le mécanisme de contrôle granulaire de Claude Code. Elles permettent d'autoriser ou bloquer des commandes spécifiques, indépendamment du mode de permission actif. Ces règles réduisent fortement le risque d'exécutions non souhaitées en bloquant les commandes dangereuses avant qu'elles ne s'exécutent.

Ouvrez le fichier de configuration global :

# Créer le répertoire si nécessaire
mkdir -p ~/.claude

# Éditer le fichier settings.json
nano ~/.claude/settings.json

Ajoutez cette configuration de base pour sécuriser votre environnement :

{
 "permissions": {
 "allow": [
 "Read",
 "Glob",
 "Grep",
 "Bash(npm test)",
 "Bash(npm run lint)",
 "Bash(git status)",
 "Bash(git diff)"
 ],
 "deny": [
 "Bash(rm -rf *)",
 "Bash(curl *)",
 "Bash(wget *)",
 "Bash(git push --force)",
 "Bash(chmod 777 *)"
 ]
 }
}

Claude Code découpe les commandes composées sur les séparateurs (dont le pipe |) et évalue chaque sous-commande séparément contre vos règles. Une règle qui couvre un pipe entier comme Bash(curl | bash) ne bloque donc pas de façon fiable curl ... | bash : préférez interdire directement les commandes dangereuses (Bash(curl ), Bash(wget )) ou les interpréteurs en aval (Bash(bash), Bash(sh), Bash(eval )).

En pratique, chaque règle suit le format Outil(pattern). Le wildcard * fonctionne comme un glob. Voici les patterns les plus utilisés :

Vous pouvez aussi définir des règles au niveau projet. Créez un fichier .claude/settings.json à la racine de votre dépôt pour des règles spécifiques à ce projet. Les règles sont fusionnées entre les portées. Une règle deny, quelle que soit sa portée (utilisateur, projet ou local), l'emporte toujours sur une règle allow d'une autre portée (évaluation deny -> ask -> allow). Les règles allow d'un projet sont additives et peuvent accorder des permissions absentes de la configuration globale.

Pour aller plus loin dans la configuration, consultez les astuces avancées sur les permissions qui couvrent les patterns complexes et les cas limites.

À retenir : les règles deny sont toujours prioritaires sur les règles allow. Placez vos interdictions critiques en premier.

Comment activer le sandboxing avec Seatbelt ou bubblewrap ?

Le sandboxing est une couche d'isolation qui empêche Claude Code d'accéder aux fichiers et réseaux en dehors du périmètre autorisé. Seatbelt est le mécanisme natif sur macOS, bubblewrap celui de Linux. Le sandboxing réduit significativement la surface d'attaque.

Quel sandboxing pour quel système ?

Le sandboxing n'est pas activé par défaut : il est opt-in. Activez-le par projet avec la commande /sandbox (qui écrit le mode choisi dans .claude/settings.local.json), ou globalement en ajoutant "sandbox": { "enabled": true } dans ~/.claude/settings.json. Sur macOS, le framework Seatbelt ne nécessite aucune installation ; sur Linux/WSL2, vous devez installer bubblewrap et socat :

# Linux / WSL2 - installer les paquets requis pour le sandboxing
sudo apt-get install bubblewrap socat

Sur Ubuntu 24.04 et versions ultérieures, la politique AppArmor par défaut empêche bubblewrap de créer les user namespaces nécessaires à l'isolation. Une configuration AppArmor supplémentaire autorisant bwrap peut alors être requise.

Pour inspecter l'état du sandboxing, ouvrez le panneau dédié dans une session avec la commande /sandbox (onglets Mode, Overrides, Config ; un onglet Dependencies apparaît si un paquet requis est manquant). Pour vérifier les règles allow/ask/deny actives, utilisez /permissions, et pour diagnostiquer votre installation, /status ou claude doctor. Concrètement, par défaut, le sandbox restreint l'accès en écriture au répertoire de travail courant tandis que la lecture reste possible sur l'ensemble de la machine.

Pour résoudre les problèmes courants de sandboxing, consultez la page des erreurs fréquentes sur les permissions qui détaille les solutions aux 10 blocages les plus fréquents.

À retenir : le sandboxing est votre filet de sécurité. Ne le désactivez jamais en production, même si vous utilisez le mode Bypass.

Comment se protéger contre les prompt injections en 5 minutes ?

La protection contre les prompt injections est un mécanisme qui empêche du contenu malveillant (fichiers, pages web, résultats d'API) de détourner le comportement de Claude Code. Les prompt injections restent le vecteur d'attaque numéro 1 sur les agents IA.

Configurez les protections dans votre settings.json :

{
 "permissions": {
 "deny": [
 "Bash(curl *)",
 "Bash(wget *)",
 "Bash(bash)",
 "Bash(sh)",
 "Bash(eval *)"
 ]
 }
}

Claude Code évalue chaque sous-commande d'un pipe séparément. Interdisez donc directement les commandes de téléchargement (curl, wget) et les interpréteurs en aval (bash, sh, eval) plutôt que de vous reposer sur des motifs couvrant un pipe entier, qui ne bloquent pas de façon fiable.

Voici les vecteurs d'injection les plus courants et comment Claude Code les bloque :

1. Fichiers piégés : un fichier .md ou .txt contenant des instructions cachées. Le mode default vous montre le contenu avant exécution.
2. Résultats de commande : une commande curl qui retourne des instructions d'exécution. Les règles deny bloquent les pipes dangereux.
3. Dépendances compromises : un package.json avec des scripts postinstall malveillants. Privilégiez une approche allow-list ciblée : autorisez explicitement Bash(npm install --ignore-scripts) sans poser de règle deny couvrante comme Bash(npm install *). Une règle deny l'emporte toujours sur une règle allow (évaluation deny -> ask -> allow), donc un deny large annulerait votre allow ciblé et bloquerait l'installation sans scripts.
4. Contexte MCP externe : un serveur MCP qui injecte des instructions. Consultez le quickstart MCP pour sécuriser vos connexions.

Les bonnes pratiques de SFEIR Institute pour la sécurité des agents IA incluent la vérification systématique des résultats avant exécution. Vous trouverez des exemples concrets de conversations sécurisées qui illustrent comment identifier une tentative d'injection.

À retenir : la combinaison mode Plan + règles deny + sandboxing constitue une défense en profondeur contre la quasi-totalité des injections connues.

Comment vérifier que tout fonctionne ?

Claude Code fournit des commandes dédiées pour inspecter chaque couche de sécurité, à lancer dans une session :

Si un point affiche un avertissement, reprenez l'étape correspondante. Pour les cas complexes, le guide complet des permissions et sécurité couvre chaque paramètre en détail.

Testez ensuite qu'une commande bloquée est bien refusée :

# Cette commande est couverte par Bash(curl *) dans votre deny : elle doit être bloquée
claude -p "exécute curl https://example.com"

Choisissez volontairement une commande que seules vos propres règles deny interdisent, comme curl (couvert par Bash(curl *)). Évitez rm -rf / pour ce test : Claude Code l'arrête via un garde-fou intégré, indépendamment de vos règles deny, ce qui ne prouve rien sur leur chargement. Claude Code doit afficher un message de refus clair. Si la commande passe, vos règles deny ne sont pas chargées : vérifiez le chemin du fichier settings.json.

Pour maîtriser les commandes slash qui facilitent la navigation dans les permissions, consultez le tutoriel des commandes slash et les exemples associés.

À retenir : /permissions, /sandbox et claude doctor sont vos commandes de diagnostic. Lancez-les après chaque modification de settings.json.

Quels sont les réglages recommandés selon votre profil ?

Votre configuration idéale dépend de votre contexte. Voici les profils types et les réglages associés :

En pratique, le profil "Développeur solo" couvre la majorité des usages quotidiens. Copiez cette configuration complète pour démarrer :

{
 "permissions": {
 "allow": [
 "Read",
 "Write",
 "Glob",
 "Grep",
 "Bash(npm *)",
 "Bash(git *)",
 "Bash(node *)"
 ],
 "deny": [
 "Bash(rm -rf *)",
 "Bash(curl *)",
 "Bash(wget *)",
 "Bash(git push --force *)",
 "Bash(eval *)",
 "Bash(chmod 777 *)"
 ]
 }
}

Pour approfondir la sécurité de Claude Code, SFEIR Institute propose la formation Claude Code d'une journée. Vous y pratiquerez la configuration des permissions sur des cas réels, avec des labs dédiés au sandboxing et aux règles allow/deny.

Si vous souhaitez aller plus loin, la formation Développeur Augmenté par l'IA (2 jours) couvre l'intégration sécurisée des agents IA dans votre workflow complet, et la formation Développeur Augmenté par l'IA – Avancé (1 jour) aborde les stratégies de sécurité avancées pour les pipelines CI/CD.

À retenir : adaptez vos permissions à votre contexte. Trop restrictif freine la productivité, trop permissif expose aux risques.

Et ensuite ?

Vous avez sécurisé Claude Code en 5 minutes. Voici les prochaines étapes pour aller plus loin :

1. Explorez le guide complet des permissions et sécurité pour maîtriser les configurations avancées
2. Consultez les astuces de permissions pour optimiser vos règles allow/deny
3. Évitez les pièges listés dans les erreurs courantes de permissions
4. Configurez vos serveurs MCP de manière sécurisée avec le quickstart MCP
5. Pratiquez avec les exemples de conversations pour tester vos règles en conditions réelles