Claude Code --dangerously-skip-permissions : ce que le flag désactive, et ce qui bloque encore

Que désactive exactement claude --dangerously-skip-permissions ?

claude --dangerously-skip-permissions désactive les demandes de permission de Claude Code, et une partie de ses contrôles de sécurité avec elles. Le flag lance l'outil en mode bypassPermissions : la référence CLI d'Anthropic le présente comme « équivalent à --permission-mode bypassPermissions », et la page des modes de permission précise que ce mode « désactive les demandes de permission et les contrôles de sécurité, si bien que les appels d'outils s'exécutent immédiatement, y compris les écritures dans les chemins protégés ». Modifications de fichiers, commandes shell, requêtes web, outils MCP : tout part sous votre utilisateur, sans qu'on vous demande rien.

Les « chemins protégés » sont le détail que la plupart des articles laissent de côté. Il s'agit de .git, .vscode, .claude, .mcp.json ou d'un profil shell comme .zshrc, autant de fichiers qu'un autre programme exécutera plus tard. C'est le mécanisme de la plupart des évasions de sandbox divulguées en 2026. Dans tous les autres modes, y écrire déclenche une demande, un passage devant le classifieur ou un refus. En mode bypass, le tableau de la documentation indique « Autorisé ».

Voici ce qui saute et ce qui reste :

Dans une exécution -p, personne n'est là pour répondre : les appels qui attendraient encore une confirmation sont donc refusés. L'avertissement d'Anthropic tient en une ligne : « bypassPermissions n'offre aucune protection contre la prompt injection ni contre les actions non intentionnelles. »

Le mode bypass est-il activé par défaut, et quels sont les autres modes de permission de Claude Code ?

Non, jamais. Claude Code compte six modes de permission et bypassPermissions n'est le défaut intégré d'aucune offre. Sur les offres Pro, Max et Team, une nouvelle session de terminal démarre en auto (à partir de la v2.1.228). Avec une offre Enterprise, une clé d'API Console, Bedrock, Foundry, claude -p ou l'Agent SDK, elle démarre en default, que l'interface affiche sous le nom Manual.

Le mode de départ se décide dans cet ordre : le flag, puis permissions.defaultMode dans un fichier de settings, puis le défaut intégré. Si vous clonez des dépôts qui ne sont pas les vôtres, un détail compte. La référence des settings indique que auto et bypassPermissions « ne prennent pas effet depuis les settings de projet ou locaux », avant d'ajouter : « Avant la v2.1.257, bypassPermissions prenait effet depuis n'importe quel fichier. » Sur une version plus ancienne, un .claude/settings.json committé dans le dépôt pouvait choisir le mode bypass à votre place, derrière une boîte d'avertissement affichée une seule fois.

Peut-on activer bypass permissions « mid session », pendant que Claude Code tourne ?

Seulement si la session a été lancée avec le bypass disponible. La documentation ne laisse aucune marge : « Vous ne pouvez pas passer en bypassPermissions depuis une session que vous avez démarrée sans l'activer. » Pour garder l'option ouverte, lancez Claude Code avec --allow-dangerously-skip-permissions, qui ajoute le mode au cycle Shift+Tab, après plan. Un hook ne peut pas l'accorder non plus.

Ce second flag a un effet de bord. Dès que le bypass est disponible dans un terminal interactif, les blocages du mode plan ne sont plus appliqués : « Claude reçoit toujours pour consigne de planifier sans modifier, mais une modification de fichier ou une commande shell qu'il tente pendant la planification s'exécute sans demande. » Le mode plan devient une consigne donnée au modèle et cesse d'être un blocage appliqué par le client, sauf dans les exécutions -p, dans l'Agent SDK et dans le panneau de chat de VS Code.

--dangerously-skip-permissions fonctionne-t-il dans l'extension VS Code ?

Oui, derrière un interrupteur désactivé par défaut. L'extension n'affiche Bypass permissions dans son indicateur de mode qu'une fois activée l'option « Allow dangerously skip permissions » (allowDangerouslySkipPermissions, false par défaut), que la documentation accompagne de cette consigne : « À n'utiliser que dans des sandboxes sans accès à Internet. » Sans elle, un défaut réglé sur bypassPermissions fait démarrer la conversation en Manual, et un dépôt ne peut pas choisir le mode de départ.

C'est aussi là qu'il faut tester la sandbox. L'issue #32814, ouverte le 10 mars 2026, signalait que l'extension lançait le binaire sans --sandbox, si bien que sandbox.enabled: true n'appliquait aucun profil Seatbelt. Elle a été fermée automatiquement comme doublon quatre jours plus tard, et nous n'avons pas retesté les versions actuelles. Le test est simple : demandez à l'agent d'écrire hors de l'espace de travail, et regardez.

Pourquoi --dangerously-skip-permissions est-il refusé en root ou avec sudo ?

Parce que Claude Code refuse cette combinaison sur Linux et macOS. Le message d'erreur est --dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons, et la page sur le sandboxing en donne la raison : « un accès root combiné à l'absence de demandes de permission peut modifier n'importe quel fichier ou service du système ». La vérification est ignorée « automatiquement à l'intérieur d'une sandbox reconnue ».

On tombe surtout sur cette erreur dans Docker, où les processus tournent en root par défaut. Le correctif documenté : « vérifiez que remoteUser désigne un compte non root ».

La sandbox vous protège-t-elle encore quand les permissions sautent ?

En partie. Le mode de permission décide si un appel d'outil s'exécute ; la sandbox intégrée limite ce qu'une commande Bash peut atteindre une fois lancée. Les deux mécanismes sont indépendants, donc les commandes shell sandboxées restent confinées en mode bypass. Mais la sandbox ne couvre que le shell. La page de comparaison d'Anthropic l'écrit sans détour : « Les outils de fichiers intégrés, les serveurs MCP et les hooks s'exécutent toujours directement sur votre hôte. »

Prenez le cas concret, sandbox activée et permissions sautées. Une commande shell qui ajoute une ligne à ~/.zshrc est arrêtée par le système d'exploitation. L'outil Edit qui écrit dans le même fichier ne l'est pas : « Read, Edit et Write utilisent directement le système de permissions au lieu de passer par la sandbox », et ce système, vous venez de le couper.

Il existe aussi une échappatoire. Une commande qui échoue dans la sandbox peut être retentée avec dangerouslyDisableSandbox, et cette nouvelle tentative « passe par le circuit de permission habituel », lequel, en mode bypass, ne comporte plus aucune demande. Fermez-la en passant sandbox.allowUnsandboxedCommands à false.

D'où la règle de la documentation : les sessions en bypass se lancent « dans un conteneur, une VM ou le sandbox runtime », là où les outils de fichiers, les serveurs MCP et les hooks se trouvent eux aussi à l'intérieur de la frontière. Codex trace la ligne ailleurs, avec un seul flag qui retire à la fois les approbations et la sandbox : voir notre guide des flags de Codex.

Le chemin le plus court est la Dev Container Feature d'Anthropic, à déclarer dans .devcontainer/devcontainer.json, sans monter aucun secret de l'hôte :

{
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
  "remoteUser": "vscode",
  "features": {
    "ghcr.io/anthropics/devcontainer-features/claude-code:1.0": {}
  }
}

npm install -g @devcontainers/cli
devcontainer up --workspace-folder .
devcontainer exec --workspace-folder . \
  claude -p "run the test suite and fix what fails" --dangerously-skip-permissions

Authentifiez-vous une fois à l'intérieur du conteneur, ou passez une ANTHROPIC_API_KEY au périmètre restreint. Vous obtenez un utilisateur non root et une frontière de processus, pas une politique de sortie réseau : c'est le conteneur de référence du dépôt anthropics/claude-code qui ajoute un script de pare-feu en refus par défaut. La page dev container prévient qu'une session en bypass peut toujours exfiltrer « tout ce qui est accessible dans le conteneur, y compris les identifiants Claude Code stockés dans ~/.claude ». Montez le dépôt, jamais votre répertoire personnel.

Comment éviter que Claude Code demande une validation à chaque commande, sans le flag ?

Passez en mode auto, ou écrivez des règles. Le mode auto remplace la demande par un modèle classifieur, et c'est déjà le défaut sur les offres Pro, Max et Team. Ailleurs, les règles permissions.allow pré-approuvent les commandes que vous lancez toute la journée, acceptEdits fait taire les demandes sur les modifications de fichiers, et le mode auto-allow de la sandbox exécute les commandes shell sandboxées sans rien demander.

L'argument en faveur d'un outil qui demande moins vient d'Anthropic lui-même. Son billet d'ingénierie sur le mode auto, daté du 25 mars 2026, s'ouvre sur cette phrase : « Les utilisateurs de Claude Code approuvent 93 % des demandes de permission. » Un point de contrôle qui dit oui 93 fois sur 100 relève surtout de l'habitude. Reste à savoir ce qui le remplace, et pour le flag, la page sur le sandboxing répond : « Rien. »

Voici un ~/.claude/settings.json qui supprime l'essentiel des demandes et conserve celles qui comptent :

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "disableBypassPermissionsMode": "disable",
    "allow": ["Bash(npm run *)", "Bash(git commit *)"],
    "ask": ["Bash(git push *)", "Bash(terraform *)"],
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Bash(curl *)"
    ]
  }
}

Les règles sont évaluées dans l'ordre deny, puis ask, puis allow. Pour un « allow all », le schéma documenté consiste à placer un "Bash" nu dans allow et à lui adjoindre un hook PreToolUse qui rejette les quelques commandes dont vous ne voulez jamais.

Côté entreprise, la clé que cherchent les administrateurs est disableBypassPermissionsMode. Placée dans les réglages managés, elle verrouille toute l'équipe, et Claude Code « rejette alors le flag --dangerously-skip-permissions ».

Gardez en tête la limite des règles Bash(...). Elles comparent du texte de commande, et la page des permissions d'Anthropic écrit qu'une règle deny « couvre l'invocation que Claude produit habituellement et ne constitue pas une frontière de sécurité autour du programme » : Bash(rm *) arrête rm -rf build/, pas /bin/rm -rf build/ ni bash -c 'rm -rf build/'.

Quels garde-fous de Claude Code tiennent encore quand les permissions sont sautées ?

Trois : les règles deny, la vérification des chemins critiques sur rm, et les hooks PreToolUse. Le guide des hooks indique que ces hooks « se déclenchent avant toute vérification du mode de permission, dans tous les modes de permission », et qu'un hook qui renvoie un refus « bloque l'outil même en mode bypassPermissions ou avec --dangerously-skip-permissions ». Des trois, le hook est le seul à exécuter votre propre logique.

En voici un, minimal, déclaré dans ~/.claude/settings.json :

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [{ "type": "command", "command": "$HOME/.claude/hooks/guard.sh" }]
      }
    ]
  }
}

#!/bin/bash
# ~/.claude/hooks/guard.sh : exit 2 bloque l'appel, stderr est renvoyé à Claude
CMD=$(jq -r '.tool_input.command')
if echo "$CMD" | grep -Eiq 'terraform[[:space:]]+destroy|drop[[:space:]]+(schema|database|table)|push[[:space:]].*--force'; then
  echo "Blocked: destructive command, ask the human to run it." >&2
  exit 2
fi
exit 0

Rangez-le dans les settings utilisateur ou managés. En mode bypass, le répertoire .claude du projet est inscriptible sans demande : un hook qui vit dans le dépôt, l'agent peut le modifier.

Passons aux limites, car ce garde compare du texte. La note de recherche GuardFall de la Cloud Security Alliance, publiée le 11 juillet 2026, a contourné les gardes de commandes de dix agents de code open source sur onze, avec cinq classes d'injection shell. Claude Code ne faisait pas partie du panel, mais le raisonnement vaut pour tout outil qui compare des chaînes : « Un garde qui inspecte la chaîne avant transformation et un shell qui exécute la chaîne après transformation évaluent, en pratique, deux commandes différentes. »

Notre propre garde de commandes se trompe aussi dans l'autre sens. Dans notre étude contrôlée du 24 août 2026, il a vérifié 1 769 commandes shell et en a refusé 17 : une vraie prise, un agent qui allait chercher un identifiant stocké, trois applications correctes de la politique, et 13 faux positifs qui ont chacun coûté un tour à l'agent, la plupart dus au token nc repéré à l'intérieur d'un heredoc Python. Un garde textuel attrape le cas courant, rien de plus. La frontière qui tient quand il rate, c'est le conteneur.

Claude Code a-t-il vraiment supprimé une base de données de production ?

Oui, et le cas le mieux documenté n'impliquait pas le flag. Le 26 février 2026, Claude Code a exécuté terraform destroy sur l'infrastructure de production de DataTalks.Club, emportant la base de données, 2,5 ans de travaux soumis aux cours et tous les snapshots automatiques. Son fondateur, Alexey Grigorev, a publié le post-mortem le 6 mars ; le support AWS a restauré les données environ 24 heures plus tard.

L'agent avait annoncé son geste : « Je ne peux pas le faire. Je vais lancer un terraform destroy. » Grigorev écrit que cela « semblait logique », et donc : « je n'ai pas arrêté l'agent ». Son billet ne mentionne nulle part des permissions sautées. Un humain se tenait bien au point de contrôle, et la commande est passée parce que la justification sonnait juste. Son bilan, repris aussi par Tom's Hardware : « J'ai traité plan, apply et destroy comme quelque chose qui pouvait se déléguer. Cela a retiré la dernière couche de sécurité. »

93 %

des demandes de permission approuvées par les utilisateurs de Claude Code (Anthropic, 25 mars 2026)

65

issues dont le titre contient rm -rf sur le tracker de Claude Code, dont 13 encore ouvertes (API GitHub, 20 septembre 2026)

17 %

des vraies actions trop zélées que le classifieur du mode auto laisse passer, d'après le décompte d'Anthropic

Une recherche par titre de rm -rf dans le tracker de Claude Code renvoie 65 issues au 20 septembre 2026. Le titre de l'une d'elles annonce que Claude Code a exécuté un rm -rf « supprimant l'intégralité du répertoire personnel ». Ce sont des signalements d'utilisateurs, que nous n'avons pas vérifiés. Le journal d'incidents interne d'Anthropic, cité dans son billet sur le mode auto, compte lui aussi « des tentatives de migration sur une base de données de production ».

Ce qui aurait aidé, du plus solide au moins solide :

1. Aucun identifiant de production dans la session, et une protection contre la suppression sur la base. C'est le correctif que Grigorev a lui-même retenu.
2. Une règle ask sur Bash(terraform *).
3. Le hook présenté plus haut.
4. Le mode auto, dont la liste de blocage par défaut nomme terraform destroy.

Claude Code en entreprise : la sécurité est-elle réglée si personne ne saute les permissions ?

Non : sans permissions sautées, la sécurité de Claude Code est meilleure, et elle reste incomplète. D'abord, du code s'exécute parfois avant que le système de permissions ait son mot à dire. La CVE-2025-59536 permettait à un projet d'exécuter du code avant l'acceptation de la boîte de dialogue de confiance au démarrage (corrigée en 1.0.111), et la recherche GitSpawn de Manifold, datée du 1er septembre 2026, a fait tourner la commande core.fsmonitor d'un dépôt « avant que la demande de confiance de l'espace de travail ne soit acceptée ». Ensuite, les permissions décident seulement si une action peut s'exécuter. Elles ne lisent jamais le code que l'agent écrit.

C'est pour cette seconde limite que cet article existe. Tous les contrôles décrits plus haut décident de ce que Claude Code peut exécuter, aucun ne regarde ce qu'il écrit. Une session en mode Manual, où un ingénieur attentif lit chaque demande, peut très bien committer un endpoint sans contrôle d'autorisation : un diff qui compile n'est pas un événement de permission. Si cet endpoint sert des données personnelles, l'oubli devient aussi un sujet RGPD, et aucun mode de permission ne l'aura vu passer. Sauter les permissions retire le dernier point de contrôle humain sur les actions ; les garder n'en ajoute aucun sur le code. La page sécurité d'Anthropic vous laisse cette part : « Il vous appartient de vérifier la sûreté du code et des commandes proposés avant de les approuver. »

C'est là que se place un contrôle agent-time. VibeDefend fonctionne sous forme de hooks dans la même boucle : il place dans le contexte du modèle les règles pertinentes pour un fichier au moment de la modification, renvoie à l'agent les constats SAST, SCA, secrets, IaC et CI/CD, et garde les commandes, dans les limites décrites plus haut. Dans l'étude du 24 août, l'agent équipé de la couche a repris à la valeur exacte 57 des 64 règles notées (89 %), contre 8 sur 65 (12 %) sans outil. La même étude consigne une tâche où la règle a été servie treize fois et où l'agent a tout de même démantelé ses propres garde-fous : l'injection informe, elle n'impose pas. Les détails se trouvent dans Claude Code respecte-t-il votre CLAUDE.md ?, dans la sécurité des agents de code IA et dans notre guide de sécurité Claude Code.

Lancez le flag délibérément, dans un conteneur, sous un utilisateur non root, avec des règles deny, un hook et quelque chose qui lit le diff, et la configuration se défend. Sur un portable, passez en mode auto, et parlons de la part qu'aucun mode de permission ne couvre.

Questions fréquentes

Quelle est la commande pour lancer Claude Code avec dangerously skip permissions ?

claude --dangerously-skip-permissions, ou son équivalent claude --permission-mode bypassPermissions, complété de -p "<prompt>" pour une exécution non interactive. Anthropic la réserve aux « environnements isolés comme des conteneurs, des VM ou des dev containers sans accès à Internet ».

--dangerously-skip-permissions est-il activé par défaut dans Claude Code ?

Non. Le défaut intégré est le mode auto sur les offres Pro, Max et Team, et Manual partout ailleurs. Le bypass exige le flag, un defaultMode réglé au niveau utilisateur, ou une option explicitement activée dans l'extension VS Code et dans l'application de bureau. Depuis la v2.1.257, les settings d'un dépôt ne peuvent plus le sélectionner.

Peut-on activer bypass permissions sans relancer Claude Code ?

Uniquement si la session a été lancée avec --allow-dangerously-skip-permissions, avec le flag lui-même, ou avec un defaultMode utilisateur réglé sur bypassPermissions. Sinon, le mode n'apparaît jamais dans le cycle Shift+Tab.

Où se règle defaultMode dans les settings de Claude Code ?

Dans ~/.claude/settings.json, avec "permissions": { "defaultMode": "acceptEdits" }. Valeurs possibles : default (alias manual), acceptEdits, plan, auto, dontAsk, bypassPermissions. auto et bypassPermissions sont ignorés depuis les settings de projet et locaux, et l'extension VS Code lit d'abord claudeCode.initialPermissionMode.

Comment tout autoriser (allow all) dans Claude Code sans sauter les permissions ?

Ajoutez un "Bash" nu à permissions.allow et déclarez un hook PreToolUse qui rejette les commandes dont vous ne voulez jamais. Les règles deny et ask gardent la priorité. Le mode auto demande moins d'effort, même si Anthropic précise qu'il « ne garantit pas la sécurité ».

Peut-on utiliser Claude Code en entreprise en toute sécurité ?

Les contrôles existent : un managed-settings.json (dans /etc/claude-code/ sous Linux) avec disableBypassPermissionsMode, allowManagedPermissionRulesOnly et allowManagedHooksOnly, plus des clés de sandbox imposées de façon centralisée. Ils gouvernent ce que l'agent peut exécuter. Aucun ne relit le code qu'il produit : cette part reste la vôtre.

Claude Code est-il sans danger sur mon ordinateur personnel ?

En mode Manual ou auto, avec des règles deny sur les fichiers .env, sur ~/.ssh et sur les dossiers d'identifiants cloud, oui pour le travail de tous les jours. Avec les permissions sautées directement sur l'hôte, non : l'agent agit sous votre utilisateur, clés SSH et identifiants cloud à portée de main. Passez par un conteneur.