Modes disponibles
Chaque mode fait un compromis différent entre la commodité et la supervision. Le tableau ci-dessous montre ce que Claude peut faire sans invite de permission dans chaque mode.| Mode | Ce qui s’exécute sans demander | Idéal pour |
|---|---|---|
default | Lectures uniquement | Démarrage, travaux sensibles |
acceptEdits | Lectures, modifications de fichiers et commandes courantes du système de fichiers (mkdir, touch, mv, cp, etc.) | Itération sur le code que vous examinez |
plan | Lectures uniquement | Explorer une base de code avant de la modifier |
auto | Tout, avec des vérifications de sécurité en arrière-plan | Tâches longues, réduction de la fatigue des invites |
dontAsk | Uniquement les outils pré-approuvés | CI verrouillé et scripts |
bypassPermissions | Tout | Conteneurs et machines virtuelles isolés uniquement |
bypassPermissions, les écritures dans les chemins protégés ne sont jamais auto-approuvées, protégeant l’état du dépôt et la configuration propre de Claude contre la corruption accidentelle.
Les modes définissent la ligne de base. Superposez les règles de permission sur le dessus pour pré-approuver ou bloquer des outils spécifiques. Les règles de refus et les règles de demande explicite s’appliquent dans tous les modes, y compris bypassPermissions. Les règles d’autorisation n’ont aucun effet dans ce mode car tout le reste est déjà approuvé.
Changer de mode de permission
Vous pouvez changer de mode en cours de session, au démarrage ou comme paramètre par défaut persistant. Le mode est défini via ces contrôles, pas en demandant à Claude dans le chat. Sélectionnez votre interface ci-dessous pour voir comment le modifier.- CLI
- VS Code
- JetBrains
- Desktop
- Web and mobile
Pendant une session : appuyez sur Par défaut : définissez Le même drapeau
Maj+Tab pour parcourir default → acceptEdits → plan. Le mode actuel apparaît dans la barre d’état. Tous les modes ne sont pas dans le cycle par défaut :auto: apparaît quand votre compte répond aux exigences du mode auto ; le parcours vers auto affiche une invite d’acceptation jusqu’à ce que vous l’acceptiez, ou sélectionnez Non, ne me le demandez plus pour supprimer auto du cyclebypassPermissions: apparaît après que vous ayez démarré avec--permission-mode bypassPermissions,--dangerously-skip-permissions, ou--allow-dangerously-skip-permissions; la variante--allow-ajoute le mode au cycle sans l’activerdontAsk: n’apparaît jamais dans le cycle ; définissez-le avec--permission-mode dontAsk
plan, avec bypassPermissions en premier et auto en dernier. Si vous avez les deux activés, vous parcourrez bypassPermissions en allant vers auto.Au démarrage : passez le mode comme drapeau.defaultMode dans les paramètres.--permission-mode fonctionne avec -p pour les exécutions non-interactives.Approuver automatiquement les modifications de fichiers avec le mode acceptEdits
Le modeacceptEdits permet à Claude de créer et de modifier des fichiers dans votre répertoire de travail sans inviter. La barre d’état affiche ⏵⏵ accept edits on tandis que ce mode est actif.
En plus des modifications de fichiers, le mode acceptEdits approuve automatiquement les commandes Bash courantes du système de fichiers : mkdir, touch, rm, rmdir, mv, cp et sed. Ces commandes sont également auto-approuvées quand elles sont préfixées avec des variables d’environnement sûres comme LANG=C ou NO_COLOR=1, ou des wrappers de processus comme timeout, nice ou nohup. Comme les modifications de fichiers, l’approbation automatique s’applique uniquement aux chemins à l’intérieur de votre répertoire de travail ou additionalDirectories. Les chemins en dehors de cette portée, les écritures dans les chemins protégés et toutes les autres commandes Bash invitent toujours.
Quand l’outil PowerShell est activé, le mode acceptEdits approuve également automatiquement Set-Content, Add-Content, Clear-Content et Remove-Item sur les chemins dans la portée, ainsi que leurs alias courants. Les mêmes règles de portée et de chemins protégés s’appliquent.
Utilisez acceptEdits quand vous voulez examiner les modifications dans votre éditeur ou via git diff après coup plutôt que d’approuver chaque modification en ligne. Appuyez sur Maj+Tab une fois depuis le mode par défaut pour l’entrer, ou démarrez directement avec :
Analyser avant de modifier avec le mode de planification
Le mode de planification indique à Claude de rechercher et de proposer des modifications sans les apporter. Claude lit les fichiers, exécute des commandes shell pour explorer et écrit un plan, mais ne modifie pas votre source. Les invites de permission s’appliquent de la même manière que le mode par défaut. Entrez le mode de planification en appuyant surMaj+Tab ou en préfixant une seule invite avec /plan. Vous pouvez également démarrer en mode de planification depuis le CLI :
Maj+Tab à nouveau pour quitter le mode de planification sans approuver un plan.
Examiner et approuver un plan
Quand le plan est prêt, Claude le présente et demande comment procéder. À partir de cette invite, vous pouvez :- Approuver et démarrer en mode auto
- Approuver et accepter les modifications
- Approuver et examiner manuellement chaque modification
- Continuer la planification avec des commentaires
- Affiner avec Ultraplan pour un examen basé sur le navigateur
Maj+Tab, ou préfixez votre prochaine invite avec /plan.
Appuyez sur Ctrl+G pour ouvrir le plan proposé dans votre éditeur de texte par défaut et le modifier directement avant que Claude ne procède. Quand showClearContextOnPlanAccept est activé, chaque option d’approbation offre également d’effacer le contexte de planification en premier.
Accepter un plan nomme également la session à partir du contenu du plan automatiquement, sauf si vous avez déjà défini un nom avec --name ou /rename.
Définir le mode de planification comme valeur par défaut
Pour faire du mode de planification la valeur par défaut pour un projet, définissezdefaultMode dans .claude/settings.json :
Éliminer les invites de permission avec le mode auto
Le mode auto nécessite Claude Code v2.1.83 ou ultérieur.
- Plan : Tous les plans.
- Propriétaire : sur Team et Enterprise, un Propriétaire doit l’activer dans les paramètres d’administration Claude Code avant que les utilisateurs puissent l’activer. Les administrateurs peuvent également le verrouiller en définissant
permissions.disableAutoModesur"disable"dans les paramètres gérés. - Modèle : sur l’API Anthropic, Claude Opus 4.6 ou ultérieur, ou Sonnet 4.6. Sur Amazon Bedrock, Google Cloud Vertex AI et Microsoft Foundry, uniquement Claude Opus 4.7 et Opus 4.8. Les modèles plus anciens, y compris Sonnet 4.5, Opus 4.5, Haiku et les modèles claude-3, ne sont pas supportés sur aucun fournisseur.
- Fournisseur : disponible par défaut sur l’API Anthropic. Sur Amazon Bedrock, Google Cloud Vertex AI et Microsoft Foundry, le mode auto est désactivé jusqu’à ce que vous définissiez
CLAUDE_CODE_ENABLE_AUTO_MODE.
defaultMode: "auto" dans les paramètres et que la session démarre en mode default sans erreur, le paramètre se trouve probablement dans .claude/settings.json ou .claude/settings.local.json. Claude Code v2.1.142 et ultérieur ignorent auto de ces fichiers afin qu’un dépôt ne puisse pas s’accorder le mode auto. Déplacez-le vers ~/.claude/settings.json.
Activer le mode auto sur Bedrock, Vertex AI ou Foundry
Sur Amazon Bedrock, Google Cloud Vertex AI et Microsoft Foundry, le mode auto n’apparaît pas dans le cycleShift+Tab jusqu’à ce que CLAUDE_CODE_ENABLE_AUTO_MODE soit défini sur 1. La variable fonctionne dans Claude Code v2.1.158 et ultérieur. Seuls Claude Opus 4.7 et Opus 4.8 sont supportés sur ces fournisseurs.
Pour l’activer pour un développeur, ajoutez la variable au bloc env dans ~/.claude/settings.json :
env aux paramètres gérés.
Une fois la variable définie, le mode auto apparaît dans le cycle Shift+Tab pour chaque session. Pour en faire le mode de démarrage par défaut, définissez également "permissions": {"defaultMode": "auto"} dans les paramètres utilisateur ou gérés. Sur ces fournisseurs, Claude Code ignore defaultMode: "auto" sauf si CLAUDE_CODE_ENABLE_AUTO_MODE est également défini.
Pour empêcher les développeurs d’activer le mode auto, définissez disableAutoMode sur "disable" dans les paramètres gérés. Cela remplace la variable d’activation.
Si vous vous connectez via une passerelle LLM configurée avec ANTHROPIC_BASE_URL, le mode auto peut déjà être accessible sans la variable d’activation, car la passerelle achemine les demandes via l’API Anthropic. Le paramètre disableAutoMode s’applique de la même manière dans cette configuration.
Ce que le classificateur bloque par défaut
Le classificateur fait confiance à votre répertoire de travail et aux télécommandes configurées de votre dépôt. Tout le reste est traité comme externe jusqu’à ce que vous configuriez l’infrastructure de confiance. Bloqué par défaut :- Téléchargement et exécution de code, comme
curl | bash - Envoi de données sensibles à des points de terminaison externes
- Déploiements et migrations de production
- Suppression en masse sur le stockage cloud
- Octroi de permissions IAM ou de dépôt
- Modification de l’infrastructure partagée
- Destruction irréversible de fichiers qui existaient avant la session
- Forçage ou poussée directe vers
main git reset --hard,git checkout -- .,git restore .,git clean -fd,git stash drop, ougit stash clear, que le classificateur présume élimineraient les modifications non validéesgit commit --amendquand le commit à HEAD n’a pas été créé dans cette sessionterraform destroy,pulumi destroy,cdk destroy, outerragrunt destroy, et l’application d’un plan qui détruit les ressources
- Opérations de fichiers locaux dans votre répertoire de travail
- Installation de dépendances déclarées dans vos fichiers de verrouillage ou manifestes
- Lecture de
.envet envoi des identifiants à leur API correspondante - Demandes HTTP en lecture seule
- Poussée vers la branche sur laquelle vous avez commencé ou celle créée par Claude
claude auto-mode defaults pour voir les listes de règles complètes. Si les actions courantes sont bloquées, un administrateur peut ajouter des dépôts de confiance, des compartiments et des services via le paramètre autoMode.environment : consultez Configurer le mode auto.
Limites que vous énoncez dans la conversation
Le classificateur traite les limites que vous énoncez dans la conversation comme un signal de blocage. Si vous dites à Claude « ne pousse pas » ou « attends que j’examine avant de déployer », le classificateur bloque les actions correspondantes même quand les règles par défaut les autoriseraient. Une limite reste en vigueur jusqu’à ce que vous la leviez dans un message ultérieur. Le propre jugement de Claude qu’une condition a été remplie ne la lève pas. Les limites ne sont pas stockées comme des règles. Le classificateur les relit à partir de la transcription à chaque vérification, donc une limite peut être perdue si la compaction de contexte supprime le message qui l’a énoncée. Pour une garantie absolue, ajoutez une règle de refus à la place.Quand le mode auto revient en arrière
Chaque action refusée affiche une notification et apparaît dans/permissions sous l’onglet Récemment refusé, où vous pouvez appuyer sur r pour la réessayer avec une approbation manuelle.
Si le classificateur bloque une action 3 fois de suite ou 20 fois au total, le mode auto s’interrompt et Claude Code reprend l’invite. Approuver l’action invitée reprend le mode auto. Ces seuils ne sont pas configurables. Toute action autorisée réinitialise le compteur consécutif, tandis que le compteur total persiste pour la session et ne se réinitialise que quand sa propre limite déclenche un retour en arrière.
En mode non-interactif avec le drapeau -p, les blocages répétés abandonnent la session puisqu’il n’y a pas d’utilisateur pour inviter.
Les blocages répétés signifient généralement que le classificateur manque de contexte sur votre infrastructure. Utilisez /feedback pour signaler les faux positifs, ou demandez à un administrateur de configurer l’infrastructure de confiance.
Comment le classificateur évalue les actions
Comment le classificateur évalue les actions
Comment le mode auto gère les sous-agents
Comment le mode auto gère les sous-agents
Le classificateur vérifie le travail des sous-agents à trois points :
- Avant qu’un sous-agent ne démarre, la description de la tâche déléguée est évaluée, donc une tâche qui semble dangereuse est bloquée au moment du lancement.
- Pendant que le sous-agent s’exécute, chacune de ses actions passe par le classificateur avec les mêmes règles que la session parent, et tout
permissionModedans le frontmatter du sous-agent est ignoré. - Quand le sous-agent se termine, le classificateur examine son historique d’action complet ; si cette vérification de retour signale une préoccupation, un avertissement de sécurité est ajouté aux résultats du sous-agent.
Coût et latence
Coût et latence
Le classificateur s’exécute sur un modèle configuré par le serveur qui est indépendant de votre sélection
/model, donc changer de modèle ne change pas la disponibilité du classificateur. Les appels du classificateur comptent dans votre utilisation de jetons. Chaque vérification envoie une partie de la transcription plus l’action en attente, ajoutant un aller-retour avant l’exécution. Les lectures et les modifications de répertoire de travail en dehors des chemins protégés ignorent le classificateur, donc la surcharge provient principalement des commandes shell et des opérations réseau.Autoriser uniquement les outils pré-approuvés avec le mode dontAsk
Le modedontAsk refuse automatiquement chaque appel d’outil qui inviterait autrement. Seules les actions correspondant à vos règles permissions.allow et les commandes Bash en lecture seule peuvent s’exécuter ; les règles ask explicites sont refusées plutôt que d’inviter. Cela rend le mode entièrement non-interactif pour les pipelines CI ou les environnements restreints où vous prédéfinissez exactement ce que Claude peut faire. Les sessions cloud sur Claude Code sur le web ignorent defaultMode: "dontAsk" ; consultez bypassPermissions pour plus de détails.
Définissez-le au démarrage avec le drapeau :
Ignorer toutes les vérifications avec le mode bypassPermissions
Le modebypassPermissions désactive les invites de permission et les vérifications de sécurité pour que les appels d’outils s’exécutent immédiatement. À partir de la v2.1.126, cela inclut les écritures dans les chemins protégés, que les versions antérieures invitaient toujours. Les règles ask explicites forcent toujours une invite dans ce mode, et les suppressions ciblant la racine du système de fichiers ou le répertoire personnel, telles que rm -rf / et rm -rf ~, invitent toujours comme disjoncteur contre les erreurs du modèle. Utilisez ce mode uniquement dans les environnements isolés comme les conteneurs, les machines virtuelles ou les devcontainers sans accès à Internet, où Claude Code ne peut pas endommager votre système hôte.
Vous ne pouvez pas entrer bypassPermissions à partir d’une session qui a été démarrée sans l’un des drapeaux d’activation ; redémarrez avec l’un pour l’activer :
--dangerously-skip-permissions est équivalent.
Sur Linux et macOS, Claude Code refuse de démarrer dans ce mode lors de l’exécution en tant que root ou sous sudo :
defaultMode: "bypassPermissions" ou "dontAsk" à partir de vos fichiers de paramètres, donc les paramètres archivés d’un référentiel ne peuvent pas démarrer une session cloud en mode bypass-permissions. Le paramètre est ignoré silencieusement et la session démarre dans le mode affiché dans la liste déroulante de mode à la place. Consultez Changer les modes de permission pour connaître les modes que les sessions cloud proposent.
Chemins protégés
Les écritures dans un petit ensemble de chemins ne sont jamais auto-approuvées, dans tous les modes saufbypassPermissions. Cela empêche la corruption accidentelle de l’état du dépôt et de la configuration propre de Claude.
| Mode | Écritures de chemins protégés |
|---|---|
default, acceptEdits, plan | Invitées |
auto | Acheminées vers le classificateur |
dontAsk | Refusées |
bypassPermissions | Autorisées |
permissions.allow dans les fichiers de paramètres ne pré-approuvent pas les écritures de chemins protégés. La vérification de sécurité s’exécute avant que Claude Code n’évalue les règles allow des paramètres, donc une entrée telle que Edit(.claude/**) dans ~/.claude/settings.json ou .claude/settings.json ne change pas le résultat par mode dans le tableau ci-dessus. Dans les modes qui invitent, l’invite pour une écriture .claude/ offre Oui, et autoriser Claude à modifier ses propres paramètres pour cette session, ce qui approuve les écritures .claude/ ultérieures dans cette session sans inviter à nouveau.
Répertoires protégés :
.git.config/git.vscode.idea.husky.cargo.devcontainer.yarn.mvn.claude, sauf pour.claude/worktreesoù Claude stocke ses propres git worktrees
.gitconfig,.gitmodules.bashrc,.bash_profile,.bash_login,.bash_aliases,.bash_logout,.zshrc,.zprofile,.zshenv,.zlogin,.zlogout,.profile,.envrc.npmrc,.yarnrc,.yarnrc.yml,.pnp.cjs,.pnp.loader.mjs,.pnpmfile.cjs,bunfig.toml,.bunfig.toml.bazelrc,.bazelversion,.bazeliskrc.pre-commit-config.yaml,lefthook.yml,lefthook.yaml,.lefthook.yml,.lefthook.yamlgradle-wrapper.properties,maven-wrapper.properties.devcontainer.json.ripgreprc,pyrightconfig.json.mcp.json,.claude.json
Voir aussi
- Permissions : règles d’autorisation, de demande et de refus ; politiques gérées
- Configurer le mode auto : indiquez au classificateur quelle infrastructure votre organisation fait confiance
- Hooks : logique de permission personnalisée via les hooks
PreToolUseetPermissionRequest - Ultraplan : exécutez le mode de planification dans une session Claude Code sur le web avec examen basé sur le navigateur
- Sécurité : garanties de sécurité et meilleures pratiques
- Sandboxing : isolation du système de fichiers et du réseau pour les commandes Bash
- Mode non-interactif : exécutez Claude Code avec le drapeau
-p
- Les actions correspondant à vos règles d’autorisation ou de refus se résolvent immédiatement, sauf les écritures dans les chemins protégés, qui sont acheminées vers le classificateur même quand une règle d’autorisation correspond
- Les actions en lecture seule et les modifications de fichiers dans votre répertoire de travail sont auto-approuvées, sauf les écritures dans les chemins protégés
- Tout le reste va au classificateur
- Si le classificateur bloque, Claude reçoit la raison et essaie une alternative
En entrant en mode auto, les règles d’autorisation larges qui accordent l’exécution de code arbitraire sont supprimées :
- Interpréteurs avec caractères génériques comme
- Commandes d’exécution du gestionnaire de paquets
- Règles
Les règles étroites commeBash(*)sans restrictionBash(python*)AgentBash(npm test)sont conservées. Les règles supprimées sont restaurées quand vous quittez le mode auto.Le classificateur voit les messages utilisateur, les appels d’outils et votre contenu CLAUDE.md. Les résultats des outils sont supprimés, donc le contenu hostile dans un fichier ou une page web ne peut pas le manipuler directement. Une sonde côté serveur séparée analyse les résultats des outils entrants et signale le contenu suspect avant que Claude ne le lise. Pour plus d’informations sur la façon dont ces couches fonctionnent ensemble, consultez l’annonce du mode auto et l’analyse technique approfondie.