bypassPermissions est parfait pour vous, dangereux pour les autres

bypassPermissions est le mode de permission de Claude Code dans lequel l'agent ne s'arrête jamais pour demander confirmation : modifications, commandes, appels réseau et tout le reste s'exécutent dès que le modèle décide de les lancer. Les recommandations d'Anthropic préconisent de ne l'utiliser que dans des environnements jetables et sandboxés. Ce conseil concerne ce à quoi l'agent a accès. Il y a une seconde question qu'il n'aborde pas : qui lui donne des ordres.

Pour votre propre agent dans votre propre sandbox, bypass est un réglage de vitesse. Pour un agent auquel d'autres personnes peuvent envoyer des requêtes, bypass revient à confier à ces personnes votre pleine autorité locale, sans aucun intermédiaire humain. Cet article porte sur cette différence.

Pourquoi bypass est tentant

Les prompts sont une friction. Lors d'un long refactoring, une centaine de questions « autoriser cette modification ? » vous pousse à cliquer sur oui sans lire. Les désactiver donne l'impression que l'agent est un collègue plutôt qu'un formulaire. Beaucoup utilisent bypass sur des dépôts sous contrôle de version en estimant, à juste titre, qu'une mauvaise modification se règle d'un simple git checkout.

Ce raisonnement tient tant que trois conditions sont réunies : vous avez rédigé la requête, vous surveillez, et rien d'irréversible n'est accessible.

Ce qui change quand quelqu'un d'autre demande

La requête n'est pas la vôtre. Pour un coéquipier, « nettoie les anciennes branches » veut dire quelque chose de précis. Pour l'agent, cela signifie git branch -D. Avec bypass, rien ne marque de pause entre les deux.

L'entrée n'est pas fiable. Les requêtes arrivent avec des pièces jointes : une capture d'écran, un fichier de log, le copier-coller d'une issue. Chacune d'elles peut contenir du texte qui ressemble à une instruction. L'injection de prompt via des entrées partagées est un vecteur réel, et bypass supprime le seul point de contrôle capable de l'intercepter.

Vous ne regardez pas. Le partage existe précisément pour que l'agent travaille en votre absence. Un prompt auquel vous auriez répondu en une seconde devient une action que personne n'a vue.

L'irréversible est à portée de main. Pousser vers main, supprimer, dépenser de l'argent, lire des identifiants. Sur votre propre machine, cela arrive rarement au cours d'une session normale, c'est pourquoi bypass semble sans danger. Ce sont pourtant exactement les actions qu'un tiers risque le plus de déclencher par accident.

La limite

Utilisez bypass pour les agents auxquels vous êtes le seul à parler, dans des répertoires où rien d'irréversible ne se trouve. Dès lors qu'un agent se trouve dans une salle avec une deuxième personne, la question n'est plus « à quel point ai-je confiance dans le modèle », mais « à quel point ai-je confiance en chaque personne et chaque pièce jointe pouvant l'atteindre ».

Garder la vitesse sans franchir la limite

Une salle vous permet de conserver l'essentiel de cette rapidité grâce à deux ajouts par-dessus le mode.

Des autorisations par personne. Une autorisation permanente permet à une personne de confiance d'exécuter des tâches sans approbation à chaque requête. Le mode propre de l'agent peut rester permissif pour les appels ordinaires. Voir les modes de permission expliqués.

Quatre actions qui marquent toujours une pause. Pousser vers une branche partagée, supprimer, dépenser de l'argent et toucher à des identifiants s'interrompent pour demander l'avis du propriétaire, même en bypass, quand la requête provient de quelqu'un d'autre. Une centaine de modifications ordinaires s'exécutent sans prompt ; le seul git push origin main vous attend. L'explication se trouve dans quatre actions pour lesquelles un agent devrait toujours demander confirmation.

Recommandations pratiques

• Agents que vous partagez : acceptEdits pour les dépôts, plan pour tout ce qui est exploratoire. Accordez des autorisations aux personnes de confiance.
• Agents que vous êtes le seul à utiliser dans des sandboxes jetables : bypass convient très bien.
• Tout ce qui contient des identifiants de production dans son répertoire de travail : default, et un agent distinct pour les tâches qui n'en ont pas besoin.
• Ne partagez jamais un agent dont le répertoire de travail contient un fichier de clés. Déplacez la clé, pas le mode.

Questions fréquentes

Est-ce qu'une salle change la signification de bypass au cours d'une exécution ? Non. Au sein d'une exécution, bypass signifie toujours aucun prompt au runtime. La salle détermine qui a le droit de lancer une exécution et quelles sont les quatre actions qui marquent une pause quoi qu'il arrive.

Qu'en est-il des réglages équivalents dans Codex ? Même principe, même conseil : permissif pour vous dans une sandbox, pas pour un agent partagé.

Un prompt à chaque push n'est-il pas agaçant ? Les pushs vers des branches partagées sont rares lors d'une session normale. Si ce n'est pas le cas, le répertoire de travail de l'agent est probablement trop large.

Rapide pour vous, prudent pour tous les autres. C'est exactement le rôle d'une salle. Donnez-en une à votre agent.