Toutes les autorisations, sans saccager votre machine

Claude Code demande avant de faire quoi que ce soit de conséquent. Au bureau, ça va : un coup d'œil, vous validez, vous continuez. Loin du bureau, cela bloque le travail. L'agent s'arrête à l'étape trois d'une tâche de vingt minutes et attend un tap qui arrive quarante minutes plus tard, alors que tout l'intérêt de lui confier la tâche était justement que vous ne regardiez pas.

Alors on se tourne vers --dangerously-skip-permissions. Ce flag est dangereux sur la mauvaise machine et raisonnable sur la bonne, et la différence ne tient pas à votre prudence. Elle tient à ce que l'agent peut atteindre quand il fait quelque chose que vous n'aviez pas prévu. Cette page explique ce que fait vraiment ce flag, pourquoi il refuse de tourner en root, la configuration qui le rend défendable, et ses équivalents dans Codex, OpenCode, Grok Build et Antigravity.

Ce que bypass permet vraiment

Claude Code a six modes d'autorisation. La page des modes d'autorisation d'Anthropic les décrit ainsi. Le tableau suit l'ordre de la documentation : default est le nom de configuration du mode Manual, pas le mode dans lequel une session démarre.

Bypass exécute immédiatement chaque appel d'outil, y compris les écritures dans des chemins protégés comme .git et la propre configuration de Claude. Quelques garde-fous tiennent toujours :

• Les règles de refus de vos paramètres bloquent dans tous les modes, bypass compris. Les règles d'autorisation n'y ont aucun effet.
• Les règles « ask » explicites déclenchent toujours une demande.
• rm et rmdir visant des chemins critiques déclenchent toujours une demande : la racine du système de fichiers, les répertoires de premier niveau, votre répertoire personnel, ainsi que le répertoire de travail et ses parents.

Ce que bypass ne vous donne pas, c'est une quelconque défense contre l'injection de prompt ou une commande fausse exécutée avec aplomb. La documentation d'Anthropic le dit clairement : ne l'utilisez que dans des environnements isolés où Claude Code ne peut pas endommager votre hôte.

Deux flags qui se ressemblent

• --dangerously-skip-permissions démarre la session en mode bypass. C'est l'équivalent de --permission-mode bypassPermissions.
• --allow-dangerously-skip-permissions ajoute seulement bypass au cycle Maj+Tab. La session démarre dans un mode normal, et vous passez en bypass quand vous le décidez.

Le second compte, car vous ne pouvez pas passer en bypass dans une session qui n'a pas été démarrée avec ce mode activé. Si vous pensez en avoir besoin plus tard, il faut le décider au lancement. La forme --allow- est la façon prudente de le faire : la session se comporte normalement jusqu'à ce que vous basculiez délibérément.

Le premier lancement interactif avec bypass activé affiche un dialogue d'avertissement. L'accepter écrit skipDangerousModePermissionPrompt: true dans ~/.claude/settings.json ; le refuser fait quitter Claude Code. Les exécutions non interactives avec -p sautent ce dialogue. Les administrateurs peuvent bloquer ce mode pour tout le monde avec permissions.disableBypassPermissionsMode: "disable" dans les paramètres gérés.

Pourquoi il échoue en root

Sur Linux et macOS, Claude Code refuse de démarrer en mode bypass en root ou sous sudo :

--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons

Cette vérification est ignorée dans une sandbox que Claude Code reconnaît, et le dev container d'Anthropic le fait tourner avec un utilisateur non root pour cette raison. Sur un VPS classique où vous vous connectez en root, créez d'abord un utilisateur normal. Notre guide d'installation sur VPS donne les trois commandes.

Nous avons appris trois choses concrètes en faisant tourner Claude Code sous le daemon de Maude sur de nombreux serveurs différents :

• En root, la forme --allow- échouait aussi. Lors de nos tests avec Claude Code 2.1.x, le processus quittait dès le lancement au lieu de simplement exclure bypass du cycle. Tout wrapper qui ajoute ce flag doit d'abord vérifier l'identifiant de l'utilisateur, sinon toutes les sessions d'un serveur en root meurent.
• Les anciennes versions rejettent purement et simplement le flag. Une CLI qui ne connaît pas le flag quitte de la même façon. Vérifiez qu'il apparaît dans claude --help avant de le passer.
• Testez sur une machine vierge. Votre propre ~/.claude/settings.json contient probablement déjà skipDangerousModePermissionPrompt depuis le jour où vous avez validé l'avertissement. Sur un serveur neuf, ce dialogue apparaît avant l'invite et une session sans surveillance reste bloquée dessus. Testez dans un conteneur propre, pas sur votre portable.

Le principe du serveur jetable

Avant d'assouplir les autorisations où que ce soit, posez-vous une question : si ce processus exécutait maintenant une commande destructrice arbitraire, que perdrais-je ?

Sur un portable typique, la réponse honnête est inconfortable : vos clés SSH, les identifiants cloud dans ~/.aws et ~/.config, des profils de navigateur avec des sessions actives, un .env avec des URL de production, et tous les autres dépôts que vous avez clonés. Sur un VPS jetable avec un seul projet, la réponse, c'est ce projet, déjà poussé de toute façon, plus une heure de reconstruction. C'est un risque acceptable. Voici trois endroits où placer l'agent :

Un conteneur sur votre propre machine

C'est l'option la moins chère et la plus proche. Lancez un conteneur Linux avec Docker ou OrbStack, installez Claude Code à l'intérieur avec un utilisateur non root, et montez uniquement le projet sur lequel il doit travailler. Ne montez pas votre répertoire personnel, ne lui passez pas les identifiants de l'hôte, et n'utilisez ni --privileged ni le montage du socket Docker, car les deux redonnent la main sur l'hôte.

Un VPS dédié

C'est l'option sur laquelle la plupart des gens s'arrêtent : une petite machine qui fait tourner un ou deux projets et rien d'autre. Elle est toujours allumée, donc le travail continue pendant que vos propres machines sont éteintes. Si elle est un jour compromise, vous la détruisez et en construisez une autre. Faites en sorte qu'elle soit banale à reconstruire, avec un court script d'installation plutôt qu'une machine peaufinée à la main pendant un an. Le guide d'achat de VPS traite du dimensionnement.

Une sandbox cloud éphémère

Les sessions cloud d'Anthropic exécutent chaque tâche dans une VM isolée, avec les identifiants git gardés hors de la sandbox et un accès réseau limité par défaut. C'est une isolation solide, sans rien à maintenir. Mais bypass n'y est pas disponible. Les sessions cloud proposent Accept edits, Plan et Auto, et ignorent bypassPermissions défini dans les paramètres d'un dépôt.

Les secrets à garder hors de la machine

• Les identifiants de production. Pointez-le vers la préproduction ou une copie locale. Le danger dont vous vous protégez n'est pas la malveillance ; c'est une erreur commise avec aplomb sur une chaîne de connexion qui traînait là.
• Votre clé SSH personnelle. Donnez au serveur sa propre clé de déploiement ou un jeton à portée fine, limité aux dépôts dont il a besoin. N'utilisez pas non plus le transfert d'agent SSH vers lui : cela prête vos clés à la machine tant que vous êtes connecté.
• Les jetons cloud trop larges. Pas de clés AWS administrateur ni de jetons GitHub valables pour toute l'organisation. Si une tâche en exige un, limitez sa portée et laissez-le expirer.
• Tout ce qui n'existe que là-bas. Poussez souvent, pour que perdre le serveur ne vous coûte rien que vous ne puissiez recréer.

Un identifiant doit vivre sur la machine : la connexion de l'agent lui-même. Claude Code la conserve dans ~/.claude/.credentials.json, donc quiconque a un shell avec cet utilisateur peut utiliser votre forfait. Raison de plus pour donner à l'agent son propre utilisateur.

Les équivalents dans Codex et les autres agents

Chaque agent de code a sa propre version de cet interrupteur, et elles ne veulent pas toutes dire la même chose :

Sources : référence de Codex CLI et validations et sécurité, autorisations d'OpenCode, autorisations de Grok Build, autorisations d'Antigravity et le codelab Antigravity CLI de Google, vérifiés en octobre 2026. Codex et Antigravity utilisent tous deux une sandbox par défaut : désactiver leurs demandes et désactiver leur sandbox sont deux décisions distinctes. C'est la désactivation de la sandbox qui exige la machine jetable.

Puis-je activer bypass depuis mon téléphone ?

Pas depuis l'app Claude. La documentation mobile d'Anthropic indique que vous ne pouvez pas sélectionner Bypass permissions depuis l'app, ni pour les sessions cloud ni pour Remote Control, et Remote Control depuis l'app ne propose pas Auto non plus. Pour un client généraliste, c'est un réglage par défaut raisonnable.

Maude est conçu pour l'autre cas, un serveur qui vous appartient et que vous pourriez reconstruire : il propose donc le mode accès complet de chaque agent sous le nom « yolo », à côté des autres modes de l'agent. Pour Claude, il ne prend effet que si le daemon tourne avec un utilisateur non root et que le Claude Code installé prend en charge le flag. Sinon, la session reste dans un mode normal. Maude démarre la session dans un mode normal et passe en bypass après le lancement, jamais au démarrage. Sur un serveur uniquement en root, un bouton dans l'app crée un utilisateur non root pour vous. Vous pouvez définir un mode par défaut pour chaque agent, ou le changer pour chaque session.

Le piloter depuis votre téléphone

Si vous avez mis en place le serveur jetable, Claude Code sur votre téléphone montre comment Maude l'y fait tourner. Valider les autorisations d'un agent depuis votre téléphone présente l'approche inverse : garder les demandes actives et y répondre depuis une notification.

Questions fréquentes

Ce qui a changé

• 1 octobre 2026 — Réécrit : restriction en root, --allow-dangerously-skip-permissions vs --dangerously-skip-permissions, le mode auto comme juste milieu par défaut, ce que bypass bloque encore, les équivalents Codex/OpenCode/Grok Build/Antigravity, et ce que permettent l'app mobile d'Anthropic et Maude.
• 25 juillet 2026 — Première publication.