Claude Code : permissions, bypass et alternatives plus sûres

Claude Code : permissions et contrôles désactivés par le bypass

--dangerously-skip-permissions et --permission-mode bypassPermissions activent le même mode. Claude peut alors modifier des fichiers, exécuter des commandes shell et appeler d’autres outils sans les demandes de validation habituelles. Ce mode autorise aussi l’écriture dans les chemins protégés. Au premier lancement interactif, un avertissement vous demande d’assumer cette responsabilité ; si vous le refusez, Claude Code se ferme. Documentation d’Anthropic sur le bypass

Imaginez un atelier : les permissions sont le guichet qui valide chaque intervention, et l’isolation, les murs qui l’entourent. Supprimer le guichet ne construit pas les murs. Vous gagnez une session de travail sans interruption, mais perdez l’occasion d’intercepter une mauvaise action avant son exécution.

Le workflow change donc de logique : au lieu d’approuver chaque opération, vous définissez d’abord l’environnement, puis examinez le résultat. Cela ne garantit ni la justesse du code ni l’innocuité d’instructions malveillantes.

Quels contrôles restent actifs malgré le bypass ?

Le mot « skip » ne signifie pas que tous les contrôles disparaissent. Ces distinctions expliquent pourquoi une exécution censée se dérouler sans surveillance peut s’arrêter ou refuser une action :

Pour la dernière ligne, le paramètre exact est permissions.blockReadsOutsideWorkingDirectories: true. Les commandes Bash reconnues comme lisant des fichiers peuvent encore demander une validation hors des répertoires autorisés ; les blocages imposés par le sandbox fonctionnent différemment. Lors d’une exécution non interactive avec -p et le bypass, les appels qui nécessiteraient encore une confirmation sont refusés. Actions qu’aucun mode n’approuve automatiquement, paramètre de lecture hors des répertoires autorisés

Les hooks bloquants PreToolUse restent eux aussi pris en compte dans la validation des outils. Une exception concerne EndConversation : les règles deny et ask ne le contraignent pas tant qu’un autre outil reste disponible. Les mods installés peuvent passer outre certaines décisions de permissions non imposées par l’administration ; les contrôles obligatoires d’une équipe doivent donc relever d’une politique administrée. Les administrateurs peuvent interdire le bypass avec "permissions": {"disableBypassPermissionsMode": "disable"}. Une session démarrée avec --restricted refuse également ce mode. Priorité des hooks et des règles, paramètre de désactivation du bypass

Le bypass autorise l’écriture dans les chemins protégés

Ne supposez pas que .git ou .claude restent soumis à confirmation. Le mode bypass permet d’écrire dans les chemins protégés. Cette protection est distincte des contrôles de suppression des répertoires critiques évoqués plus haut.

La liste des chemins protégés d’Anthropic comprend :

Des exceptions ciblées existent dans .claude, notamment pour les worktrees propres à Claude, les fichiers du plan en cours, les espaces temporaires des sessions en arrière-plan et certains fichiers mémoire Markdown. Dans les sessions habituelles en mode manuel (Manual) ou acceptEdits, les écritures protégées demandent une confirmation ; le mode auto les soumet à son classificateur. Une règle d’autorisation dans un fichier de paramètres ne peut pas les approuver à l’avance. Chemins protégés et exceptions

Quatre solutions plus sûres pour limiter les interruptions

Choisissez le contrôle adapté à l’interruption. La plupart des développeurs ont d’abord besoin de règles de validation plus précises avant d’avoir besoin du bypass.

Passer au mode auto pour le développement courant

Lancez une session avec claude --permission-mode auto. Un classificateur — un modèle distinct qui examine les actions proposées — prend en charge les décisions de validation courantes. Pour en faire le mode par défaut des sessions de terminal, intégrez "permissions": {"defaultMode": "auto"} à ~/.claude/settings.json.

Placer cette valeur dans .claude/settings.json ou .claude/settings.local.json ne l’active pas. Le mode auto dépend aussi des modèles pris en charge et des paramètres de l’organisation ; les règles ask explicites continuent de demander une confirmation. Il réduit les interruptions sans garantir la sécurité. Paramètre du mode par défaut, conditions d’utilisation du mode auto

Notre guide du mode auto de Claude Code explique dans quels cas ce modèle de vérification convient à votre workflow.

Autoriser les opérations courantes et bloquer des actions précises

Utilisez permissions.allow pour les commandes que vous avez examinées, et permissions.deny pour les opérations à bloquer. Claude Code évalue deny avant ask, puis allow. Une autorisation large ne peut pas annuler une interdiction correspondante. Règles de permissions

Pour un dépôt de confiance, l’exemple suivant associe des autorisations ciblées à un hook bloquant. Intégrez-le à .claude/settings.json en conservant les clés existantes. Il démarre volontairement les sessions de terminal en mode manuel pour que les autorisations listées déterminent ce qui est permis. Vérifiez ce qu’exécutent les scripts de test et de lint du projet avant de les approuver.

{
  "permissions": {
    "defaultMode": "default",
    "allow": ["Bash(npm test)", "Bash(npm run lint)"],
    "deny": ["Bash(git push *)", "Read(./.env)", "Read(./.env.*)"]
  },
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "if": "Bash(rm *)",
        "command": "echo 'Use the approved cleanup task instead.' >&2; exit 2"
      }]
    }]
  }
}

Utilisez .claude/settings.local.json pour vos réglages personnels au niveau du projet ; ajoutez ce fichier à .gitignore si vous le créez vous-même. Ouvrez /permissions pour consulter les règles actives et les fichiers dont elles proviennent. Portée des paramètres

Ces motifs de correspondance n’isolent ni le système de fichiers ni le réseau. Une autre manière d’écrire une commande peut échapper à un motif Bash, et des scripts quelconques peuvent lire des fichiers indirectement malgré les règles deny des outils de fichiers. Gardez les secrets hors de l’environnement et imposez les restrictions par un sandbox lorsque l’accès doit être impossible. Limites des règles Bash, limites des règles de fichiers

Utiliser le mode plan avant une modification d’ampleur

Commencez avec claude --permission-mode plan, ou définissez "permissions": {"defaultMode": "plan"} dans les paramètres du projet. Claude explore le code et propose un plan de travail avant que les modifications des sources soient approuvées. Le paramètre de premier niveau "useAutoModeDuringPlan": false désactive la validation des commandes de planification par le classificateur : les commandes qui dépassent l’ensemble intégré d’opérations en lecture seule nécessitent alors votre accord. Configuration du mode plan

Démarrez une nouvelle session de planification sans option rendant le bypass disponible. Dans une session de terminal interactive où le bypass est disponible, le mode plan n’applique pas ses blocages habituels sur les modifications et les commandes. Cela vaut aussi lorsque cette disponibilité vient de --allow-dangerously-skip-permissions, qui permet de choisir le bypass ultérieurement sans l’activer immédiatement. Mode plan et disponibilité du bypass

Bloquer des commandes précises avec des hooks

Le gestionnaire hooks.PreToolUse de l’exemple utilise matcher: "Bash", type: "command" et if: "Bash(rm *)". Quand la condition est remplie, sa commande shell affiche un motif et se termine avec le code 2, ce qui bloque l’appel de l’outil. Aucun script séparé n’est nécessaire. Cette commande shell est un petit exemple de notre cru, fondé sur les champs de hooks et le code de sortie bloquant documentés par Anthropic. Configuration des hooks, codes de sortie bloquants

Ce mécanisme bloque les appels rm correspondants, pas toutes les façons possibles de supprimer un fichier. Une équipe peut le remplacer par un validateur qu’elle a examiné pour ses propres commandes de déploiement ou de nettoyage. Gardez des contrôles assez ciblés pour pouvoir les comprendre et les tester. Notre page sur les hooks de Claude Code détaille leur configuration et leur débogage.

Dans quels environnements Anthropic autorise-t-il le bypass ?

Le tableau des configurations courantes d’Anthropic exige un conteneur, une VM ou un environnement d’exécution sandbox, avec un utilisateur non-root sous Linux et macOS. La section consacrée au bypass décrit des environnements isolés qui ne peuvent pas endommager l’hôte et mentionne expressément ceux qui n’ont pas accès à Internet. Le guide du devcontainer fournit, lui, une configuration connectée dont les accès sortants sont limités aux services nécessaires à Claude. Considérez un accès réseau sans restriction comme une exposition supplémentaire. Isolation requise, restrictions réseau du devcontainer

Sous Linux et macOS, le lancement du bypass en tant que root ou via sudo est normalement refusé. La documentation indique qu’une exception s’applique automatiquement dans un sandbox reconnu ; la méthode documentée avec un devcontainer utilise un compte non-root. Ne cherchez pas à résoudre une erreur liée à root en affaiblissant cette limite.

Mettre en place le devcontainer de référence

Utilisez une copie de travail jetable d’un dépôt de confiance. Une fois Docker, VS Code et l’extension Dev Containers installés, partez du projet de référence d’Anthropic :

git clone https://github.com/anthropics/claude-code.git claude-code-isolated
code claude-code-isolated

1. Dans VS Code, lancez Dev Containers: Reopen in Container. La configuration de référence réunit la CLI, des volumes persistants et un pare-feu pour les connexions sortantes. Vérifiez que remoteUser désigne un compte non-root.
2. Dans le terminal du conteneur, exécutez id -u et vérifiez que le résultat n’est pas 0. Lancez claude pour vous connecter, puis quittez cette session.
3. Dans ce même terminal, exécutez claude -p "Inspect this repository and summarize its structure. Do not change files." --dangerously-skip-permissions.
4. Pour votre propre projet, copiez le répertoire .devcontainer/ de référence dans une copie de travail jetable et adaptez le Dockerfile à sa chaîne d’outils. Examinez le diff de l’espace de travail après chaque tâche.

Cette procédure suit le workflow du conteneur de référence d’Anthropic. Il s’agit d’un exemple fonctionnel, pas d’une image de base maintenue. Conservez ses restrictions sur les connexions sortantes ou mettez en place des contrôles réseau équivalents.

L’espace de travail monté reste accessible en écriture depuis le conteneur, et ces modifications se répercutent sur l’hôte. Évitez de monter ~/.ssh, des fichiers d’identifiants cloud ou des répertoires sans rapport avec la tâche. Un projet malveillant peut toujours exfiltrer ce qui est accessible à l’intérieur, y compris les identifiants de Claude. Utilisez des dépôts de confiance et surveillez le travail. Limites du devcontainer

Les sessions cloud ignorent le bypass défini par défaut

Les sessions cloud ignorent sans avertissement les valeurs defaultMode: "bypassPermissions" et defaultMode: "dontAsk" des fichiers de paramètres. Elles démarrent dans le mode affiché par le menu déroulant du cloud. Un paramètre JSON versionné dans le dépôt ne peut pas imposer le bypass à une session cloud. Comportement des modes dans le cloud

Votre fichier local ~/.claude/settings.json n’est pas transféré dans une session cloud hébergée par Anthropic. Les paramètres des dépôts ont aussi leurs limites : les sessions qui couvrent plusieurs dépôts ne chargent pas les règles de permissions et les hooks de chacun. Examinez la politique réellement appliquée dans l’environnement cloud au lieu de supposer que la configuration de votre terminal a été reprise. Paramètres dans les sessions cloud

Quel mode choisir selon le travail à effectuer ?

Le changement le plus utile consiste généralement à supprimer les validations répétitives d’un workflow existant. Voici les options concrètes, dans l’ordre où je les envisagerais :

Pour le cas de la CI, claude -p "run the test suite" --permission-mode dontAsk --allowedTools "Bash(npm test)" "Read" est le point de départ documenté par Anthropic. Cette commande refuse les opérations qui demanderaient autrement une confirmation. Configurations courantes

Quel que soit le mode retenu, appuyez-vous aussi sur nos bonnes pratiques Claude Code. Les permissions encadrent l’exécution ; la vérification détermine si le résultat mérite d’être conservé.

Deux outils utiles à développer en équipe

Un vérificateur de configuration des permissions est la piste la plus prometteuse. DataForSEO estime à 720 recherches par mois aux États-Unis le volume de la requête « claude code permissions ». Ce chiffre révèle une difficulté à trouver l’information, pas une intention d’achat démontrée. Une équipe plateforme développeurs pourrait créer un petit outil qui explique la portée des paramètres, signale les valeurs defaultMode ignorées et prévisualise les règles de commandes trop larges avant l’arrivée de nouveaux collègues. Son premier livrable utile serait un rapport assorti de modifications suggérées. La difficulté : le maintenir à mesure que le comportement de la configuration de Claude Code évolue.

Un lanceur d’exécutions jetables pourrait servir aux équipes qui répètent des tâches sans surveillance. La même analyse de la demande estime à 260 recherches par mois aux États-Unis le volume de « claude code docker ». Un MVP pourrait valider un modèle de conteneur préalablement examiné, les montages autorisés, l’exécution non-root et la politique de connexions sortantes, puis rassembler le diff et les logs obtenus pour un mainteneur. Sa valeur serait de rendre la configuration reproductible. Sa limite : un lanceur ne peut pas rendre sûr le code d’un dépôt non fiable, ni garantir l’isolation par la seule présence de Docker.

Ces deux pistes d’outillage interne doivent être validées auprès d’utilisateurs réels. Aucune ne nécessite de faire du bypass le réglage par défaut des machines de développement.

Dès lundi, choisissez un workflow répétitif, examinez les commandes qu’il exécute réellement et configurez les règles de validation minimales qui lui permettent d’aller au bout. Passez à un conteneur jetable uniquement lorsque la tâche exige une exécution sans surveillance qui dépasse ce cadre.

Si votre équipe a besoin de concevoir et de maintenir ce workflow, notre offre de systèmes d’IA en production peut l’y aider.