Que fait --dangerously-skip-permissions dans Claude Code ?

Il démarre la session en mode bypassPermissions, comme --permission-mode bypassPermissions. Les appels d’outils s’exécutent sans demande, sauf les règles ask explicites, les règles deny, les questions que Claude vous pose et la suppression de chemins critiques comme votre dossier personnel.

Est-il sûr d’utiliser --dangerously-skip-permissions ?

Seulement dans un environnement isolé. La documentation d’Anthropic dit de l’utiliser dans des conteneurs, des VM ou des dev containers sans accès à Internet, et précise qu’il n’offre aucune protection contre l’injection de prompt ni contre les actions involontaires.

Pourquoi Claude Code refuse-t-il d’ignorer les permissions en root ?

Sous Linux et macOS, l’option refuse de s’exécuter avec les privilèges root ou sudo, pour des raisons de sécurité. La vérification est sautée dans un sandbox reconnu. Lancez Claude Code en utilisateur normal, ou en utilisateur non root dans un conteneur.

Quelle alternative plus sûre à l’abandon des permissions ?

Des règles allow dans settings.json pour les commandes de confiance, des règles deny pour celles que vous ne voulez jamais, le mode auto avec son classificateur de sécurité, et le sandbox Bash. Ensemble, elles suppriment la plupart des demandes sans abandonner le contrôle.

Comment AgentVera gère-t-il les permissions de Claude Code ?

Chaque agent a un réglage Permissions : Ask, Auto ou Full access. Sur Pro et Team, Auto-approve safe requests répond à votre place aux commandes en lecture seule et de test. Les agents peuvent aussi tourner dans un conteneur Docker, et chaque tour reçoit un checkpoint annulable.

Claude Code --dangerously-skip-permissions en sécurité

--dangerously-skip-permissions lance Claude Code en mode bypassPermissions : les appels d’outils s’exécutent sans vous demander. C’est le moyen le plus rapide de faire cesser les demandes, et aussi le plus risqué. La documentation d’Anthropic dit elle-même de ne l’utiliser que dans des environnements isolés comme des conteneurs ou des VM. En général, vous n’en avez pas besoin. Quelques règles allow, le mode auto ou un sandbox suppriment la plupart des demandes et gardent les garde-fous.

Cet article couvre ce que l’option saute, ce qu’elle ne saute pas, où cela tourne mal, et les options plus sûres. À la fin, il montre comment AgentVera traite le même problème quand plusieurs agents tournent en même temps.

Ce que fait réellement l’option

Claude Code a des modes de permission. L’option est un raccourci vers l’un d’eux :

claude --dangerously-skip-permissions
# same as
claude --permission-mode bypassPermissions

Dans ce mode, Claude modifie des fichiers, exécute des commandes shell et appelle des outils sans s’arrêter. D’après la documentation des modes de permission, quelques éléments l’arrêtent encore :

Les règles deny. Une règle deny dans vos réglages bloque un outil dans tous les modes, bypass compris.
Les règles ask explicites. Si vous avez écrit une règle ask, il demande encore.
Les questions que Claude vous pose. Claude peut toujours s’interrompre pour poser une question.
La suppression de chemins critiques. rm ou rmdir sur la racine du système de fichiers, les dossiers de premier niveau, votre dossier personnel ou le répertoire de travail et ses parents demande encore confirmation.

Les règles allow n’ont aucun effet en mode bypass, puisque tout est déjà autorisé. Les écritures vers des chemins protégés comme .git et .claude sont aussi permises.

Quelques détails de plus comptent en pratique :

La première fois que vous l’utilisez en interactif, Claude Code affiche une boîte de dialogue d’avertissement. L’accepter écrit skipDangerousModePermissionPrompt: true dans ~/.claude/settings.json.
Dans une exécution non interactive (claude -p), il n’y a pas de boîte de dialogue.
Sous Linux et macOS, l’option refuse de s’exécuter en root ou avec sudo. La vérification est sautée dans un sandbox reconnu.
Vous ne pouvez pas passer en bypass depuis une session qui n’a pas démarré avec. --allow-dangerously-skip-permissions ajoute le mode au cycle Shift+Tab sans l’activer.
Les administrateurs peuvent désactiver le mode pour tout le monde avec permissions.disableBypassPermissionsMode: "disable" dans les réglages gérés.

Les risques

La documentation le dit sans détour : le mode bypass « n’offre aucune protection contre l’injection de prompt ni contre les actions involontaires ». Voici ce que cela signifie au quotidien.

Injection de prompt

Claude lit des fichiers, des pages web, des textes de tickets et des sorties d’outils. Si l’un d’eux contient des instructions, le modèle peut les suivre. Avec les demandes activées, vous voyez le curl suspect vers un hôte inconnu avant son exécution. En mode bypass, vous l’apprenez après.

Commandes destructrices absentes de la liste critique

La vérification des chemins critiques couvre rm de votre dossier personnel ou de la racine du projet. Elle ne couvre pas git reset --hard, git clean -fd, une table de base de données supprimée, un force push ni une migration lancée sur le mauvais environnement. Tout cela s’exécute sans demande.

Les secrets et le reste de votre machine

Sur votre portable, Claude s’exécute sous votre identité. Il peut lire vos clés SSH, vos identifiants cloud et vos fichiers .env, et il peut atteindre le réseau. Une erreur ou une instruction injectée dispose de tout votre compte.

Les checkpoints ne couvrent pas tout

Claude Code prend un checkpoint avant chaque prompt, et /rewind (ou Échap deux fois) restaure le code, la conversation, ou les deux. Mais la documentation des checkpoints précise que les changements faits par des commandes Bash comme rm, mv et cp ne sont pas suivis, pas plus que les changements hors de la session. Rewind ne remplace pas git.

Des moyens plus sûrs de réduire les demandes de permission

La plupart des gens recourent à l’option parce que les demandes les ralentissent. Ces options règlent les demandes et gardent les garde-fous.

1. Choisir le bon mode de permission

Mode	S’exécute sans demander	Idéal pour
`default` (Manual)	Lectures uniquement	Code inconnu, dépôts sensibles
`acceptEdits`	Lectures, modifications de fichiers, commandes de fichiers courantes comme `mkdir`, `mv`, `cp`	Codage quotidien où vous relisez le diff
`plan`	Lectures uniquement, aucune modification de source	Explorer et planifier avant un changement
`auto`	Tout, avec un classificateur qui vérifie chaque action d’abord	Tâches longues dont vous approuvez la direction
`dontAsk`	Seulement les outils pré-approuvés ; le reste est refusé	CI et scripts
`bypassPermissions`	Tout sauf les cas ci-dessus	Conteneurs et VM isolés uniquement

Shift+Tab parcourt les modes dans une session. --permission-mode en choisit un au démarrage, et permissions.defaultMode dans les réglages définit votre mode par défaut.

Le mode auto est le juste milieu que la plupart des gens veulent. Un modèle classificateur examine chaque action avant son exécution. Il bloque les actions qui dépassent votre demande, visent une infrastructure qu’il ne reconnaît pas ou semblent dictées par un contenu hostile. S’il bloque trois fois de suite ou 20 fois au total, le mode auto se met en pause et les demandes normales reviennent. Deux limites s’appliquent : il demande un modèle pris en charge, et la documentation dit qu’il « réduit les demandes de permission mais ne garantit pas la sécurité ». Les versions récentes de Claude Code démarrent les sessions interactives en mode auto par défaut. Consultez /permissions pour voir dans quel mode vous êtes.

2. Écrire des règles allow et deny

Les règles de permission vivent dans settings.json et sont appliquées par Claude Code, pas par le modèle. Elles sont vérifiées dans l’ordre : deny, puis ask, puis allow. La première correspondance l’emporte, donc une règle allow ne peut jamais passer outre un deny.

{
  "permissions": {
    "allow": ["Bash(npm run test *)", "Bash(npm run lint)", "Bash(git diff *)"],
    "ask": ["Bash(git commit *)"],
    "deny": ["Bash(git push *)", "Read(./.env)"]
  }
}

Utilisez /permissions pour voir et modifier les règles dans une session. Autorisez les commandes que vous lancez cinquante fois par jour, comme les tests, le lint et git en lecture seule. Refusez celles que vous ne voulez jamais voir un agent lancer. CLAUDE.md est une consigne pour le modèle. Il ne change pas les permissions.

Pour les scripts, dontAsk plus une courte liste allow est plus strict que bypass :

claude -p "run the test suite and fix failures" \
  --permission-mode dontAsk --allowedTools "Bash(npm test)" "Read" "Edit"

3. Activer le sandbox Bash

La documentation du sandboxing décrit un sandbox au niveau du système qui limite les fichiers et les domaines réseau que les commandes shell peuvent atteindre. Activez-le avec /sandbox ou sandbox.enabled: true. Il fonctionne sous macOS, Linux et WSL2. Il ne s’applique qu’aux commandes shell. Les outils de fichiers, les serveurs MCP et les hooks s’exécutent en dehors.

4. Si vous ignorez les permissions, isolez d’abord

Parfois bypass est le bon choix, comme pour une longue exécution sans surveillance sur du code jetable. Suivez alors la configuration de la documentation : un conteneur, une VM ou un dev container, un utilisateur non root, aucun secret monté et idéalement aucun accès à Internet. La forme courante sans surveillance est :

claude -p "<task>" --dangerously-skip-permissions

Lancez-la dans le conteneur, pas sur votre portable.

5. Travailler dans un worktree et commiter souvent

Un git worktree donne à l’agent son propre dossier et sa propre branche. S’il saccage la branche, vous supprimez le worktree et main n’en a jamais rien su. Des commits fréquents vous donnent des points de restauration qui couvrent aussi ce que Bash a changé, ce que les checkpoints ne peuvent pas faire.

Un tableau de décision rapide

Situation	À utiliser
Vous approuvez sans cesse les mêmes commandes de test et de lint	Règles allow
Vous voulez moins de demandes mais gardez un contrôle de sécurité	Mode auto
Tâche CI ou script avec un ensemble d’outils connu	`dontAsk` plus `--allowedTools`
Les commandes shell ne doivent toucher ni le réseau ni votre dossier personnel	Sandbox Bash
Longue exécution sans surveillance sur du code jetable	Bypass dans un conteneur, en non-root
Identifiants de production sur la machine	Jamais de bypass

Comment AgentVera gère cela

Quand vous lancez plusieurs agents, les demandes se multiplient. Cinq agents, ce sont cinq endroits qui peuvent attendre un oui. AgentVera vous donne les mêmes options par agent, plus des moyens de répondre aux demandes de n’importe où.

Un niveau de permission pour chaque agent

Dans la boîte de dialogue de l’agent et le sélecteur de modèle, un champ Permissions offre trois options :

Ask : la CLI demande comme d’habitude.
Auto : le mode auto propre à la CLI. Les modifications et les commandes sûres passent, les risquées s’arrêtent encore. Pour Claude Code, l’agent démarre avec --permission-mode auto.
Full access : ne demande jamais. Pour Claude Code, c’est --dangerously-skip-permissions. L’indice de l’application le dit clairement : « Best in a worktree or container ».

L’en-tête de l’agent affiche un badge comme « Permissions: Auto ». Codex et les autres CLI ont leurs propres équivalents. Changer le niveau relance l’agent, et la conversation continue. Si une politique d’équipe plafonne les approbations, les agents continuent de demander.

Auto-approve safe requests (Pro et Team)

L’approbation automatique est une voie intermédiaire pour les agents Claude Code. Avec Auto-approve safe requests activé, AgentVera ne répond qu’aux demandes que Claude aurait posées de toute façon, et seulement aux sûres :

les outils de lecture comme Read, Glob, Grep et LS,
les commandes shell et git en lecture seule,
les commandes de test, lint, typecheck et build pour npm, pnpm, yarn, bun, pytest, cargo, go et d’autres.

Les commandes avec >, $() ou des backticks ne sont jamais approuvées automatiquement. Vos propres règles allow et deny de Claude s’appliquent toujours. Also approve file edits inside the project est désactivé par défaut. Activé, il couvre les modifications dans le projet ou le worktree et ne touche jamais .git ni .env. La liste Never auto-approve commence par git push, npm publish, rm, git reset --hard et git clean, et vous pouvez y ajouter les vôtres. Recent auto-approvals montre ce qui est passé pendant la session en cours.

L’interrupteur est activé par défaut mais ne prend effet que sur Pro et Team. Sur l’offre gratuite, les demandes continuent de vous arriver.

Répondre aux demandes depuis votre bureau, votre téléphone ou Telegram

Les demandes qui restent vous arrivent où que vous soyez. Sur le bureau, il y a une file d’approbation dans la barre d’état, ⇧⌘A saute à l’agent qui attend depuis le plus longtemps, et le Dock affiche un badge. Si vous laissez une approbation en attente, un rappel arrive après cinq minutes. Voir notifications et approbations.

Loin du bureau :

Telegram envoie les demandes d’approbation avec des boutons Approve et Deny.
La vue téléphone sur app.agentvera.dev affiche les approbations avec Approve et Reject.
L’application mobile envoie des notifications push pour elles.

Comme répondre à une demande prend quelques secondes, vous avez moins de raisons de recourir à Full access.

Agents Docker pour une vraie isolation

Pour les exécutions où vous voulez bien Full access, lancez l’agent avec Run in a Docker container. Cela marche pour les agents Claude Code et Codex locaux, et c’est sur toutes les offres. Voir agents dans Docker.

Le conteneur ne voit que le dossier du projet, pas vos clés SSH ni le reste de votre ordinateur.
Quand l’agent s’arrête, le conteneur est supprimé. Seuls les changements dans le dossier du projet restent.
Vous pouvez définir des limites de CPU et de mémoire.
Les hooks et MCP continuent de fonctionner.

Il demande Docker Desktop, Colima ou OrbStack. C’est l’environnement isolé que demande la documentation de Claude Code, sans écrire vous-même de Dockerfile.

Des checkpoints à chaque tour

Les checkpoints d’AgentVera prennent un instantané du dossier de travail dans une référence git cachée au début de chaque tour, en gardant les 60 derniers tours par agent. Comme ils capturent le dossier lui-même, ils attrapent aussi les fichiers qu’une commande shell a changés. Vous pouvez voir quels fichiers un tour a touchés, annuler le tour, et annuler l’annulation. Vos branches, votre index et votre stash restent intacts.

Liste de vérification avant d’ignorer les permissions

Des règles allow ou le mode auto pourraient-ils supprimer les demandes à la place ?
L’agent est-il dans un conteneur ou une VM, pas sur votre machine principale ?
S’exécute-t-il en utilisateur non root ?
Les secrets, clés SSH et identifiants de production sont-ils hors de portée ?
L’accès réseau est-il limité ou coupé ?
Le travail est-il sur sa propre branche ou son propre worktree, avec un commit récent où revenir ?
Des règles deny couvrent-elles git push et tout ce que vous ne voulez jamais ?

Pour conclure

--dangerously-skip-permissions est un vrai outil à usage étroit : des environnements jetables et isolés. Pour le travail quotidien, les règles allow et deny, le mode auto et le sandbox suppriment la plupart des demandes et gardent le contrôle entre vos mains. Si vous exécutez beaucoup d’agents, donnez à chacun le niveau dont il a besoin. Laissez passer seules les demandes sûres, répondez au reste depuis votre téléphone, et placez dans un conteneur les agents qui ont besoin de Full access.

Pour aller plus loin :

Pour essayer AgentVera, commencez par la page d’accueil.