CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS : réglage et audit

Ne définissez pas CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS sur les machines de développement ni sur les runners CI partagés. Dans Claude Code v2.1.311+, cette variable désactive une confirmation de suppression précise, uniquement en mode bypassPermissions. Réservez-la aux environnements isolés et jetables dont vous pouvez perdre tous les fichiers accessibles en écriture.

Au 2026-10-28, Anthropic documente ce réglage comme une variable de l’environnement de lancement. Il n’active pas le mode de contournement des permissions et ne désactive pas tous les autres contrôles.

Pourquoi le mode dangereux bloque-t-il encore rm -rf ~ ?

Claude Code vérifie les cibles reconnues de rm et rmdir séparément des autorisations habituelles des outils. L’option --dangerously-skip-permissions sélectionne bypassPermissions. Ce mode conserve toutefois la vérification des chemins critiques tant que le nouveau réglage ne s’applique pas.

Une règle allow ne peut pas autoriser la suppression d’un chemin reconnu comme critique. Un hook PreToolUse qui renvoie allow ne le peut pas non plus. Par défaut, le terminal demande une autorisation avec un compte à rebours de deux minutes.

Avec -p, un outil de permissions ou un callback SDK peut décider de l’opération. Un hook PermissionRequest qui autorise l’opération le peut aussi. Sans l’un de ces mécanismes, la suppression est refusée par défaut.

La définition des chemins critiques comprend :

• La racine du système de fichiers, comme /.
• Ses répertoires enfants directs, dont /usr, /etc et /data.
• Votre répertoire personnel, y compris son nom court Windows 8.3, comme C:\Users\LONGNA~1.
• Les racines des lecteurs Windows et leurs répertoires de premier niveau, comme C:\ et C:\Windows. Les formes \\?\C:\ et \\localhost\C$ comptent aussi.
• Votre répertoire de travail et ses parents.
• Vos répertoires de travail supplémentaires et leurs parents, uniquement pour un motif glob sous l’un d’eux, comme rm -rf <dir>/*.

Supprimer directement un répertoire supplémentaire avec rm -rf <dir> ne déclenche pas cette vérification propre aux répertoires supplémentaires. Une autre règle peut s’appliquer, notamment si ce répertoire se trouve directement sous la racine.

La vérification couvre les commandes que Claude Code reconnaît. Une commande non détectée ne reçoit aucune protection particulière. D’autres programmes autorisés peuvent aussi supprimer des fichiers. Remove-Item de PowerShell et les commandes de suppression de cmd ont leurs propres vérifications.

Configurer une seule session de terminal isolée

Définissez la variable dans l’environnement qui lance claude, puis sélectionnez explicitement bypassPermissions. Ce réglage convient, par exemple, à une tâche automatisée qui vide volontairement un répertoire de travail jetable.

Utilisez une CLI fonctionnelle, authentifiée et en version v2.1.311 ou ultérieure. Exécutez ces vérifications dans Bash sur macOS, Linux ou WSL :

claude --version
claude auth status --text

Si l’authentification échoue, utilisez claude auth login avec un compte autorisé. Si le mauvais exécutable se lance, suivez les vérifications d’installation et de PATH de Claude Code. Mettez à jour une ancienne installation avant de poursuivre.

Lancez la session avec une affectation temporaire dans Bash :

CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1 \
  claude --permission-mode bypassPermissions

L’affectation s’applique à cette commande et à ses processus enfants. Elle ne persiste pas dans le shell parent. Vous pouvez remplacer --permission-mode bypassPermissions par --dangerously-skip-permissions.

Dans l’environnement isolé, utilisez un compte non root. Sur Linux et macOS, le mode de contournement refuse normalement les lancements en tant que root ou avec sudo. Les sandboxes reconnus font exception.

Ne placez pas cette variable dans le bloc env de ~/.claude/settings.json, .claude/settings.json ou .claude/settings.local.json. La référence des variables d’environnement confirme que Claude Code l’y ignore. Changer de niveau de configuration ne résout pas ce problème.

Le réglage s’applique uniquement en mode bypassPermissions, pas en mode plan. Il concerne la vérification des chemins critiques des outils Bash et Monitor, y compris les commandes qu’elle ne peut pas analyser entièrement.

Pour retirer une variable exportée, quittez la session concernée et supprimez l’affectation de sa source de lancement. Exécutez unset CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS dans votre shell, puis ouvrez une nouvelle session.

Vérifier le message de démarrage sans rien supprimer

Le message de démarrage indique si le réglage peut prendre effet. Une réponse correcte du modèle ne suffit pas à établir l’état des permissions.

Pour un diagnostic simple dans l’environnement isolé, exécutez ceci dans Bash :

CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1 \
  claude --permission-mode bypassPermissions \
  --tools "" --disallowedTools "mcp__*" \
  -p "Reply with READY." 2>claude-startup.log

grep -F 'CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS' claude-startup.log

Les options de la CLI retirent les outils intégrés et bloquent les outils MCP pour ce diagnostic. Elles limitent les outils que le modèle peut appeler. Les hooks de démarrage et les extensions se chargent toujours.

La commande demande une réponse READY sur stdout. Elle enregistre la sortie de démarrage de stderr dans claude-startup.log, sans demander de suppression.

Les messages documentés contiennent l’une de ces trois expressions :

Extrait du message	Signification
is set, so dangerous rm commands can run without a prompt	Le réglage peut s’appliquer après le chargement des paramètres gérés et des hooks de plugins. Certaines règles ou certains hooks peuvent encore l’empêcher.
has no effect in this session	La confirmation ou le refus habituel reste en place pour toute la session. Corrigez la cause et redémarrez.
has no effect while the Windows registry cannot be read for managed settings	Les vérifications habituelles restent actives tant que la lecture du registre échoue. Une lecture ultérieure réussie peut activer le réglage sans redémarrage.

Dans une application Agent SDK, fournissez l’option stderr pour recevoir le message. L’absence de sortie ne prouve pas que la confirmation des chemins critiques reste active. Vérifiez la transmission de la variable au lancement, le mode actif et un éventuel lancement indirect de la session.

Si le diagnostic se termine avant d’afficher un message, examinez d’abord l’erreur de démarrage. Un échec d’authentification ou de configuration est distinct de ce réglage.

Neuf raisons pour lesquelles la variable reste sans effet

Vérifiez la version, l’environnement de lancement et le mode actif avant de modifier d’autres paramètres. Comparez ensuite votre situation aux exceptions documentées.

Chaque ligne décrit une cause possible. Conservez les protections voulues par votre équipe.

Cause	Vérifications et action
1. Un autre composant gère les demandes de permission	Recherchez --permission-prompt-tool ou un callback SDK canUseTool sans --permission-prompts none. Vérifiez aussi tout hook PermissionRequest, quel que soit son critère de correspondance, ou un mod gérant cet événement. Retirez un gestionnaire présent par erreur et redémarrez.
2. La session utilise un panneau de discussion graphique	Le panneau de discussion de l’extension VS Code et l’application Desktop n’appliquent pas ce réglage. Lancez la CLI depuis votre terminal, y compris le terminal intégré d’un IDE.
3. Une règle deny ou ask cible Bash, Edit ou Read	Toute règle de ce type désactive le réglage, même sans rapport avec une suppression. Dès sa lecture, cet effet dure toute la session, même après le retrait de la règle. Redémarrez après une modification approuvée. Pour exclure un outil, utilisez --tools plutôt qu’une règle deny.
4. Les lectures hors des répertoires de travail sont bloquées	Vérifiez permissions.blockReadsOutsideWorkingDirectories. Si sa désactivation est prévue, retirez chaque paramètre qui le définit sur true, puis redémarrez.
5. Claude Code a été lancé dans une autre session	Un lancement depuis l’outil Bash ou un hook d’une session conserve les vérifications habituelles, même avec la variable sur la ligne de commande. Lancez Claude Code depuis votre shell. Cette restriction des sessions imbriquées n’est pas une frontière de sécurité.
6. Un hook PreToolUse renvoie ask	Examinez la décision du hook pour la suppression et corrigez une réponse ask non souhaitée. Une réponse allow seule ne contourne pas la vérification ordinaire des chemins critiques.
7. Claude Code a créé la session	Les sessions en arrière-plan démarrent sans la variable. Cela concerne aussi les sessions des agents d’une équipe dans des volets séparés et celles créées par un serveur Remote Control. Si ce réglage est nécessaire, lancez la session directement depuis le terminal.
8. Les paramètres gérés n’ont pas été chargés correctement	Demandez à l’administrateur de réparer la source défaillante. Utilisez claude doctor pour examiner les échecs de récupération des paramètres gérés par le serveur. Les échecs de lecture du registre suivent le comportement décrit ci-dessous.
9. La lecture du registre Windows échoue	Cela concerne Windows et WSL, même lorsque WSL n’utilise pas les paramètres du registre. Causes possibles : interopérabilité désactivée, Windows dans une langue autre que l’anglais ou conteneur sur un noyau WSL2. Rétablissez l’interopérabilité seulement si vous y êtes autorisé ; sinon, effectuez vous-même le nettoyage prévu.

Après une modification autorisée, vérifiez de nouveau le message de démarrage. Si un hook Windows réagit de façon inattendue, consultez les vérifications de l’exécutable actif et des hooks Windows avant de modifier la politique de permissions.

Auditer les sources de lancement et appliquer la politique d’équipe

Auditez les fichiers de configuration et l’environnement du processus qui démarre Claude Code. Une recherche sans résultat dans le dépôt ne suffit pas à connaître les variables injectées par une CI hébergée.

Trouver les affectations persistantes et les refuser en CI

Recherchez la variable dans le dépôt et les profils de shell courants, sans afficher le contenu des fichiers. Cet exemple Bash nécessite ripgrep et affiche les noms des fichiers contenant une correspondance :

audit_paths=(.)
for audit_path in \
  "$HOME/.bashrc" "$HOME/.bash_profile" "$HOME/.profile" \
  "$HOME/.zshrc" "$HOME/.zprofile" "$HOME/.zshenv"
do
  if [[ -f "$audit_path" ]]; then
    audit_paths+=("$audit_path")
  fi
done

rg -l --hidden --no-ignore -F \
  -g '!.git/**' -g '!node_modules/**' \
  'CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS' \
  "${audit_paths[@]}"

Examinez les correspondances avant toute modification : mentionner la variable dans un document ne l’exporte pas. Étendez la recherche aux fichiers chargés par les profils, aux scripts de lancement, aux définitions de conteneurs et aux fichiers d’environnement.

Inspectez aussi les variables CI aux niveaux de l’organisation, du dépôt, de l’environnement et de la tâche. Vérifiez l’environnement du service du runner et les étapes qui modifient les variables avant le lancement. N’enregistrez pas l’environnement complet dans les journaux.

Dans un lanceur CI contrôlé, placez cette vérification Bash juste avant l’appel à Claude Code :

if [[ -n "${CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS+x}" ]]; then
  printf '%s\n' 'Refusing Claude Code launch: critical-path override variable is set.' >&2
  exit 1
fi

Cette vérification refuse toute présence de la variable, même avec une valeur vide ou 0. C’est une politique prudente du lanceur ; cela ne signifie pas que toutes les valeurs activent la fonction. Elle protège seulement les appels qui passent réellement par cette vérification.

Désactiver le mode de contournement avec les paramètres gérés

Bloquez ce mode si votre équipe n’en a pas besoin. La variable exige ce mode pour agir : le bloquer supprime donc une condition nécessaire. Un bloc env dans les paramètres gérés ne peut pas neutraliser cette variable lue uniquement au lancement.

Fusionnez ce contrôle avec les paramètres gérés actifs de l’organisation :

{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  }
}

Pour un déploiement par fichier, utilisez :

• macOS : /Library/Application Support/ClaudeCode/managed-settings.json
• Linux et WSL : /etc/claude-code/managed-settings.json
• Windows : C:\Program Files\ClaudeCode\managed-settings.json

Redémarrez Claude Code et consultez /status. Vérifiez que Setting sources indique la source gérée attendue. Une nouvelle tentative d’activation de bypassPermissions doit être refusée.

Vérifiez la source sélectionnée avant le déploiement : une source gérée plus prioritaire peut supplanter le fichier déployé. Protégez la politique par l’administration des machines. Une personne disposant de droits d’administrateur local peut modifier une politique stockée dans un fichier.

Quelle protection est la plus fiable : règles deny ou sandbox ?

Utilisez l’isolation du système d’exploitation pour délimiter l’accès aux fichiers, et les règles de permissions pour contrôler les appels aux outils. La confirmation des chemins critiques reste une vérification supplémentaire, pas une protection complète du système de fichiers.

Conservez les règles deny utiles. Toutefois, les règles Bash comparent le texte des commandes. Bash(rm *) ne couvre pas toutes les formes d’appel ni les autres programmes capables de supprimer des fichiers. Examinez aussi les hooks et mods installés : les extensions peuvent influer sur les décisions de permissions.

Sur les systèmes macOS, Linux et WSL2 compatibles, fusionnez ces paramètres du sandbox avec la politique gérée :

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false
  }
}

Cette configuration empêche le démarrage si le sandbox est indisponible et désactive les nouvelles tentatives hors du sandbox. Windows natif ne prend pas en charge ce sandbox ; cette politique y empêcherait donc le démarrage.

Consultez /sandbox pour examiner la configuration effective et les dépendances. Auditez excludedCommands et les chemins accessibles en écriture. Le mode strict permet encore des exclusions, et les paramètres utilisateur ou --settings peuvent élargir certaines listes.

Les commandes exécutées dans le sandbox peuvent toujours supprimer les données du projet accessibles en écriture. L’isolation intégrée ne contient pas non plus tous les hooks, serveurs MCP lancés localement ou outils de fichiers.

Pour les tâches sans surveillance exigeant une isolation plus large, protégez tout le processus Claude Code. Utilisez un conteneur, une VM ou un environnement d’exécution isolé. Gardez les chemins importants de l’hôte hors des montages accessibles en écriture et utilisez une copie de travail remplaçable.