Choisir un mode de permission

Contrôlez si Claude demande avant de modifier les fichiers ou d'exécuter des commandes. Changez de mode avec Maj+Tab dans le CLI ou utilisez le sélecteur de mode dans VS Code, Desktop et claude.ai.

Quand Claude veut modifier un fichier, exécuter une commande shell ou effectuer une demande réseau, il s'arrête et vous demande d'approuver l'action. Les modes de permission contrôlent la fréquence de cette pause. Le mode que vous choisissez façonne le flux d'une session : le mode par défaut vous permet d'examiner chaque action au fur et à mesure, tandis que les modes plus souples permettent à Claude de travailler dans des étapes plus longues et ininterrompues et de faire un rapport quand c'est terminé. Choisissez une supervision plus importante pour les travaux sensibles, ou moins d'interruptions quand vous faites confiance à la direction.

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.

Dans tous les modes sauf 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.

claude --permission-mode plan

{
"permissions": {
"defaultMode": "acceptEdits"
}
}

claude remote-control --permission-mode acceptEdits

Approuver automatiquement les modifications de fichiers avec le mode acceptEdits

Le mode acceptEdits 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 :

claude --permission-mode acceptEdits

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 sur Maj+Tab ou en préfixant une seule invite avec /plan. Vous pouvez également démarrer en mode de planification depuis le CLI :

claude --permission-mode plan

Appuyez sur 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

Approuver un plan quitte le mode de planification et bascule la session vers le mode de permission que chaque option d'approbation décrit, de sorte que Claude commence à modifier. Pour planifier à nouveau, revenez au mode de planification avec 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éfinissez defaultMode dans .claude/settings.json :

{
  "permissions": {
    "defaultMode": "plan"
  }
}

Éliminer les invites de permission avec le mode auto

Le mode auto permet à Claude d'exécuter sans invites de permission de routine. Un modèle classificateur séparé examine les actions avant qu'elles ne s'exécutent, bloquant tout ce qui escalade au-delà de votre demande, cible une infrastructure non reconnue ou semble entraîné par du contenu hostile que Claude a lu. Les règles d'ask explicites forcent toujours une invite.

Le mode auto instruit également Claude à continuer à travailler sans s'arrêter pour des questions de clarification, bien que Claude pose toujours des questions quand votre invite ou une compétence s'y appuie explicitement. Pour un comportement autonome plus fort tout en conservant les invites de permission, définissez plutôt le style de sortie proactif.

Le mode auto n'est disponible que quand votre compte répond à toutes ces exigences :

• 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.disableAutoMode sur "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 ou ultérieur. Sur Amazon Bedrock, Google Cloud Vertex AI, Microsoft Foundry et les sessions de passerelle d'applications Claude signées, uniquement Claude Sonnet 5, 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, Microsoft Foundry et les sessions de passerelle d'applications Claude signées, le mode auto est désactivé jusqu'à ce que vous définissiez CLAUDE_CODE_ENABLE_AUTO_MODE.

Si Claude Code signale le mode auto comme indisponible, l'une de ces exigences n'est pas remplie ; ce n'est pas une panne transitoire. Un message séparé qui nomme un modèle et dit que le mode auto « ne peut pas déterminer la sécurité » d'une action est une panne transitoire du classificateur ; consultez la référence d'erreur.

Si vous définissez 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, Microsoft Foundry et les sessions de passerelle d'applications Claude signées, le mode auto n'apparaît pas dans le cycle Shift+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 Sonnet 5, 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": {
    "CLAUDE_CODE_ENABLE_AUTO_MODE": "1"
  }
}

Pour l'activer pour votre organisation, ajoutez le même bloc 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. Cela ne s'applique pas à une session de passerelle d'applications Claude signée, qui est sa propre classe de fournisseur et nécessite la variable d'activation. Le paramètre disableAutoMode s'applique de la même manière dans l'une ou l'autre 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
• {/* min-version: 2.1.182 */}git reset --hard, git checkout -- ., git restore ., git clean -fd, git stash drop, ou git stash clear, que le classificateur présume élimineraient les modifications non validées
• git commit --amend quand le commit à HEAD n'a pas été créé dans cette session
• terraform destroy, pulumi destroy, cdk destroy, ou terragrunt destroy, et l'application d'un plan qui détruit les ressources

Claude Code v2.1.195 et ultérieur bloquent plus de catégories par défaut. Plusieurs dépendent des entrées d'environnement, telles que les cibles distantes sensibles et les portées IaC protégées, que vous pouvez affiner à des noms concrets.

• Écriture dans un gestionnaire de secrets, ou modification des enregistrements DNS ou des certificats TLS
• Fusion d'une demande de tirage qu'aucun humain n'a approuvée, approbation de la propre demande de tirage de Claude, ou désactivation des vérifications CI
• Publication d'un commentaire qui est lui-même une commande pour l'automatisation, comme atlantis apply ou le /deploy ou /merge d'un bot
• Basculement, augmentation progressive ou suppression d'un drapeau de fonctionnalité de production
• Application de modifications d'infrastructure à une portée IaC protégée, ou vidage et suppression de nœuds de cluster
• Écritures dans un cluster de calcul partagé qui vont au-delà de la ressource que vous avez nommée, comme un sélecteur d'étiquette ou --all qui capture les tâches d'autres utilisateurs
• Création de ressources Kubernetes qui s'exécutent sur chaque nœud ou interceptent le trafic du cluster, comme les DaemonSets et les webhooks d'admission
• Shells interactifs ou port-forwards vers une cible distante sensible
• Ouverture d'un tunnel ou d'un shell inverse qui rend un service local accessible depuis l'internet public
• Impression d'une identifiant ou d'un jeton en direct dans la transcription ou un fichier
• Accès à un emplacement de données PII ou réglementées, ou copie de données hors de celui-ci
• Routage d'une installation de paquet autour de votre registre de paquets interne vers un registre public
• Exécution d'une commande avec un drapeau qui désarme une garde de sécurité, comme --insecure
• Actions du navigateur Claude in Chrome qui pourraient envoyer le contenu de la page, les cookies ou les identifiants hors-origine

Autorisé par défaut :

• 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 .env et 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 Code v2.1.195 et ultérieur autorisent également ceci par défaut :

• Suppression des tâches exactes que Claude a créées plus tôt dans la même session
• Lecture, examen ou écriture de code, de configurations et de modèles de menace liés à la sécurité dans le cadre de votre tâche
• Messages entre les agents travaillant ensemble dans la même session multi-agents
• Envoi de données aux domaines de confiance, aux compartiments et aux services que vous listez dans environment. Cela couvre le flux de données uniquement, pas les opérations destructrices ou d'identifiants sur la même infrastructure
• Navigation Claude in Chrome vers un domaine interne de confiance, localhost, ou une URL que vous avez nommée

Les demandes d'accès réseau sandbox sont acheminées via le classificateur plutôt que d'être autorisées par défaut. Exécutez 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.

1. Les actions correspondant à vos [règles d'autorisation ou de refus](/anthropic/claude-code/history/docs/fr/2026-06-29-2302..2026-06-30-2302/permissions/#manage-permissions) se résolvent immédiatement, sauf les écritures dans les [chemins protégés](#protected-paths), qui sont acheminées vers le classificateur même quand une règle d'autorisation correspond
2. 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](#protected-paths)
3. Tout le reste va au classificateur
4. 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 :

* `Bash(*)` sans restriction
* Interpréteurs avec caractères génériques comme `Bash(python*)`
* Commandes d'exécution du gestionnaire de paquets
* Règles `Agent`

Les règles étroites comme `Bash(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](https://claude.com/blog/auto-mode) et l'[analyse technique approfondie](https://www.anthropic.com/engineering/claude-code-auto-mode).

Autoriser uniquement les outils pré-approuvés avec le mode dontAsk

Le mode dontAsk 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 :

claude --permission-mode dontAsk

Ignorer toutes les vérifications avec le mode bypassPermissions

Le mode bypassPermissions 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 :

claude --permission-mode bypassPermissions

Le drapeau --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 :

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

La vérification est ignorée automatiquement à l'intérieur d'un sandbox reconnu. Pour fonctionner de manière autonome dans un conteneur, utilisez la configuration du devcontainer, qui exécute Claude Code en tant qu'utilisateur non-root.

Claude Code sur le web n'honore pas 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 sauf bypassPermissions. Cela empêche la corruption accidentelle de l'état du dépôt et de la configuration propre de Claude.

Les règles 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/worktrees où Claude stocke ses propres git worktrees

Fichiers protégés :

• .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.yaml
• gradle-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 PreToolUse et PermissionRequest
• 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