L’option a deux rayons d’explosion, et presque tout ce qui est écrit à son sujet n’en couvre qu’un. --dangerously-skip-permissions empêche Claude Code de demander une autorisation avant de modifier un fichier ou d’exécuter une commande. L’exposition évidente concerne votre système de fichiers. Celle dont personne ne parle concerne votre facture : un agent qui ne s’arrête jamais pour demander ne cesse pas non plus de dépenser, et les échecs agentiques sont des boucles.
Les deux aspects peuvent être contenus, et aucun ne vous oblige à cesser d’utiliser l’option. Voici ce qu’elle fait réellement, puis les trois mesures de confinement qui prennent environ une minute chacune.
Ce que cela fait
Claude Code s’arrête normalement avant une action conséquente et attend une approbation. L’option désactive cette pause pendant toute la session. Elle n’accorde pas de nouvelles capacités au modèle et ne change pas le modèle ; elle supprime l’étape de vérification entre un plan et son exécution.
C’est pourquoi la formulation honnête n’est pas « cette option est-elle dangereuse ? », mais à quoi cette session peut-elle accéder ? La même commande est anodine dans un checkout temporaire et réellement imprudente dans un dépôt dont l’environnement contient des identifiants de production. L’option reste la même ; c’est l’exposition que vous contrôlez.
Confinement 1 — lui donner son propre checkout
C’est la mesure la moins coûteuse et elle suffit généralement. Un git worktree est un répertoire de travail complet sur sa propre branche ; une modification non vérifiée est donc déposée à un endroit que vous pouvez supprimer, plutôt que par-dessus votre travail.
# Containment that costs one command: give the agent its own checkout.
# A worktree is a real working directory on its own branch, so a runaway
# edit is contained to a branch you can delete rather than to your repo.
git worktree add -b agent/task-123 ../repo-agent-123
cd ../repo-agent-123
claude --dangerously-skip-permissions
# When it is done, review the branch like any other, then:
git worktree remove ../repo-agent-123La vérification a toujours lieu — simplement une fois, sur une branche, au lieu de quarante fois, via une invite. C’est généralement une meilleure utilisation de votre attention que l’approbation de chaque écriture de fichier, ce qui constitue le véritable argument en faveur de l’option, plutôt que l’impatience.
Confinement 2 — lui donner ses propres identifiants
Tout ce qui se trouve dans l’environnement de ce shell est accessible à l’agent. La solution n’est pas d’être prudent, mais d’y placer moins de choses. Créez des identifiants pour l’agent au lieu de réutiliser ceux que vous avez partout, afin que l’arrêt de l’agent nécessite une seule révocation et non la rotation de tout ce que vous possédez.
# A key per agent, not a key per human. Revoking one key stops one
# agent; revoking the key you use everywhere stops your whole day.
export ANTHROPIC_BASE_URL=https://api.kunavo.com
export ANTHROPIC_AUTH_TOKEN=sk-kn-... # created for this agent only
export ANTHROPIC_MODEL=claude-sonnet-5
export ANTHROPIC_DEFAULT_OPUS_MODEL=claude-opus-5-5
export ANTHROPIC_DEFAULT_SONNET_MODEL=claude-sonnet-5
export ANTHROPIC_DEFAULT_HAIKU_MODEL=claude-haiku-4-5
claude --dangerously-skip-permissionsConservez les lignes de modèle : le modèle par défaut intégré à Claude Code et son alias opus pointent tous deux vers le dernier Opus et, si Kunavo ne fournit pas encore ce modèle, un agent sans surveillance échoue lors de sa première requête avec une erreur 404. L’alias sonnet demande Sonnet 5.5, que Kunavo ne fournit pas ; sans la ligne ANTHROPIC_DEFAULT_SONNET_MODEL, tout sous-agent configuré avec model: sonnet, /model sonnet et la phase d’exécution de opusplan renvoie une erreur 404 de la même manière. L’alias opus est associé à Opus 5.5 (claude-opus-5-5), qui nécessite Claude Code v2.1.280 ou une version ultérieure — exécutez d’abord claude update si votre version est plus ancienne. Chez Kunavo, une clé peut être révoquée indépendamment : la révocation est vérifiée à chaque requête authentifiée, une clé révoquée cesse donc immédiatement de fonctionner, plutôt qu’à la fin d’une période de facturation. Une clé peut également avoir sa propre limite mensuelle de dépenses et une liste d’adresses IP autorisées ; c’est ce qui transforme « une clé par agent » d’une simple question d’organisation en une véritable limite : la clé de l’agent peut être plafonnée et limitée sans toucher à celle que vous utilisez manuellement. La création d’une deuxième clé est gratuite. Les détails de configuration se trouvent dans l’obtention d’une clé API pour Claude Code.
Confinement 3 — limiter les dépenses, pas seulement le système de fichiers
C’est l’axe que le reste d’Internet laisse de côté. Pensez à ce que fait un agent sans surveillance lorsqu’il échoue plutôt que lorsqu’il fonctionne : il réessaie. Chaque nouvelle tentative est un aller-retour facturé qui n’a rien produit, et le contexte d’un agent de programmation est volumineux ; ces allers-retours ne sont donc pas bon marché. Une tâche de vingt étapes est normale ; une boucle bloquée ne l’est pas.
La limite dépend entièrement de votre mode de facturation. Un abonnement la limite par une fenêtre d’utilisation — un véritable plafond, même s’il se manifeste par un arrêt plutôt que par un avertissement. Une carte enregistrée n’a naturellement aucun plafond. Sur Kunavo, il y en a deux, et le second mérite d’être défini avant une exécution sans surveillance : la facturation débite un solde prépayé, de sorte qu’une requête ne peut jamais prélever plus que le solde disponible, et une clé peut avoir sa propre limite mensuelle de dépenses. La limite est vérifiée avant l’exécution ; le dépassement ne se produit donc jamais au lieu d’être constaté après coup. Au-delà, l’appel est refusé avec un message indiquant la clé plutôt que le portefeuille, et la limite est réinitialisée au début du mois civil suivant. Définissez-en une sur la clé détenue par l’agent : le pire scénario n’est plus « le solde », mais un montant que vous avez choisi.
Le calcul du coût attendu d’une exécution — pour distinguer une session normale d’une boucle — se trouve sur la page tarifaire de Claude Code, et les limites de Claude Pro et Max couvrent l’aspect abonnement de la même question.
Quand l’utiliser et quand s’en abstenir
| Situation | Raisonnable ? |
|---|---|
| Worktree jetable, clé limitée, aucun identifiant de production dans le shell | Oui — c’est précisément l’usage prévu de l’option |
| Conteneur ou VM que vous pouvez supprimer | Oui, et c’est encore préférable |
| Longue exécution sans surveillance que vous examinerez sous forme d’un seul diff | Oui, avec un solde dimensionné pour cela |
| Votre checkout principal contenant des modifications non validées | Non — validez ou mettez d’abord de côté vos modifications, puis utilisez un worktree |
| Un shell contenant des identifiants cloud ou de production | Non |
| Une machine pouvant accéder directement à la production | Non |
Le schéma du tableau est que chaque « non » concerne l’accès, et aucun ne concerne l’option. Limitez l’accès et l’option cesse d’être la variable intéressante — c’est précisément le point.
Questions fréquentes
Que fait --dangerously-skip-permissions dans Claude Code ?
Cela empêche Claude Code de demander une approbation avant chaque action ; les modifications de fichiers et les commandes shell s’exécutent donc sans invite. Le nom est exact, sans dramatisation : l’invite d’autorisation est la seule chose qui sépare un plan élaboré par le modèle de son exécution, et l’option la supprime pendant toute la session. Elle ne change rien à ce que le modèle est capable de faire — uniquement au fait qu’un humain voie chaque étape avant son exécution.
Est-il sûr d’utiliser --dangerously-skip-permissions ?
La sécurité dépend de ce à quoi la session peut accéder. L’option ne rend pas le modèle plus capable ; elle supprime l’étape de vérification. La vraie question est donc ce qu’une erreur non vérifiée peut toucher : le répertoire dans lequel l’agent démarre, les identifiants présents dans son environnement et l’accès éventuel de la machine à la production. Dans un checkout jetable avec une clé limitée, une erreur non vérifiée est une branche que vous supprimez. Dans votre dépôt principal avec vos identifiants de production exportés, ce n’est pas le cas. Même option, exposition radicalement différente.
Comment exécuter Claude Code sans invites d’autorisation en toute sécurité ?
Limitez les trois éléments auxquels il peut accéder, dans cet ordre. Donnez-lui son propre checkout — un git worktree sur sa propre branche se crée en une commande et transforme une mauvaise modification en branche supprimable. Donnez-lui ses propres identifiants plutôt que la clé que vous utilisez partout, afin que sa révocation arrête un seul agent et non toute votre journée. Et n’exportez pas dans le shell qu’il exécute des identifiants qu’il n’a aucune raison de voir, car tout ce qui se trouve dans cet environnement est accessible. Rien de tout cela ne nécessite un conteneur, même si un conteneur est strictement préférable lorsque vous en avez un.
Un agent autonome peut-il générer une facture API sans limite ?
C’est l’axe que la plupart des discussions sur cette option ignorent. Un agent qui ne s’arrête jamais pour demander n’arrête pas non plus de dépenser, et les boucles agentiques échouent du côté coûteux — une boucle de nouvelles tentatives correspond à de nombreux allers-retours facturés sans résultat. Deux éléments la limitent sur Kunavo. La facturation débite un solde prépayé plutôt qu’une carte, donc le solde constitue un plafond strict. De plus, une clé peut avoir sa propre limite mensuelle de dépenses, vérifiée avant l’exécution de la requête : au-delà de la limite, l’appel est refusé avec un message indiquant la clé plutôt que le portefeuille, et la limite est réinitialisée au début du mois civil suivant. Définissez-en une sur la clé remise à l’agent, et le pire scénario est un montant que vous avez choisi.
Quelle est la différence entre ignorer les autorisations et utiliser un mode d’autorisation ?
Les modes d’autorisation de Claude Code vous permettent de décider à l’avance quelles catégories d’actions nécessitent une approbation ; un humain reste ainsi dans la boucle pour les actions risquées et en sort pour les actions routinières. L’option est la version brutale de la même idée, avec tout réglé sur allow. Pour les exécutions sans surveillance, l’option est souvent ce que vous voulez ; pour le travail interactif, un mode l’est généralement davantage, car la friction supprimée par l’option permettait de détecter de vraies erreurs.
L’option fonctionne-t-elle de la même manière via une passerelle ?
Oui — l’option est entièrement côté client. Elle détermine si Claude Code vous demande votre accord avant d’agir et n’a rien à voir avec l’endpoint qui sert le modèle. Définir ANTHROPIC_BASE_URL sur une passerelle modifie la destination et le coût des requêtes, mais pas ce que l’agent est autorisé à faire localement. La seule chose que change un endpoint est le second axe mentionné plus haut : la manière dont les dépenses sont limitées.