> ## Documentation Index > Fetch the complete documentation index at: https://cli.fuxicode.com/docs/llms.txt > Use this file to discover all available pages before exploring further. # Choisir un mode de permission > Contrôlez si Fuxi 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 fuxi.ai. Quand Fuxi 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 manuel vous permet d'examiner chaque action au fur et à mesure, tandis que les modes plus souples permettent à Fuxi 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 Fuxi peut faire sans invite de permission dans chaque mode. | Mode | Ce qui s'exécute sans demander | Idéal pour | | :------------------------------------------------------------------ | :--------------------------------------------------------------------------------------------------------------------- | :-------------------------------------------------- | | `default` | Lectures uniquement. Étiqueté **Manuel** dans l'extension CLI et IDE | Démarrage, travaux sensibles | | [`acceptEdits`](#auto-approve-file-edits-with-acceptedits-mode) | 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`](#analyze-before-you-edit-with-plan-mode) | Lectures uniquement | Explorer une base de code avant de la modifier | | [`auto`](#eliminate-prompts-with-auto-mode) | Tout, avec des vérifications de sécurité en arrière-plan | Tâches longues, réduction de la fatigue des invites | | [`dontAsk`](#allow-only-pre-approved-tools-with-dontask-mode) | Uniquement les outils pré-approuvés | CI verrouillé et scripts | | [`bypassPermissions`](#skip-all-checks-with-bypasspermissions-mode) | Tout | Conteneurs et machines virtuelles isolés uniquement | Le mode qui examine chaque action s'appelle **Manuel** dans l'interface CLI, dans `fuxi --help`, et dans les extensions VS Code et JetBrains. Sa valeur de configuration est `default`, ce que les hooks et les intégrations SDK utilisent. L'interface CLI accepte `manual` comme alias partout où vous tapez la valeur, par exemple `fuxi --permission-mode manual` ou `"defaultMode": "manual"`. L'étiquette Manuel et l'alias `manual` nécessitent Fuxi Code v2.1.200 ou ultérieur. Dans tous les modes sauf `bypassPermissions`, les écritures dans les [chemins protégés](#protected-paths) ne sont jamais auto-approuvées, protégeant l'état du dépôt et la configuration propre de Fuxi contre la corruption accidentelle. Les modes définissent la ligne de base. Superposez les [règles de permission](/fr/permissions#manage-permissions) 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 à Fuxi dans le chat. Sélectionnez votre interface ci-dessous pour voir comment le modifier. **Pendant une session** : appuyez sur `Maj+Tab` pour parcourir `default` → `acceptEdits` → `plan`. Le mode actuel apparaît dans la barre d'état. {/* min-version: 2.1.203 */}Le mode manuel, `default` dans ce cycle, affiche un badge gris `⏸ manual mode on`. Avant v2.1.203, la barre d'état n'affichait aucun badge en mode manuel. 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](#eliminate-prompts-with-auto-mode) ; le parcours vers auto bascule les modes sans invite de confirmation * `bypassPermissions` : 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'activer * `dontAsk` : n'apparaît jamais dans le cycle ; définissez-le avec `--permission-mode dontAsk` Les modes optionnels activés s'insèrent après `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. ```bash theme={null} fuxi --permission-mode plan ``` **Par défaut** : définissez `defaultMode` dans les [paramètres](/fr/settings#settings-files). ```json theme={null} { "permissions": { "defaultMode": "acceptEdits" } } ``` Le même drapeau `--permission-mode` fonctionne avec `-p` pour les [exécutions non-interactives](/fr/headless). **Pendant une session** : cliquez sur l'indicateur de mode en bas de la boîte d'invite. **Par défaut** : définissez `fuxiCode.initialPermissionMode` dans les paramètres VS Code, ou utilisez le panneau de paramètres de l'extension Fuxi Code. L'indicateur de mode affiche ces étiquettes, mappées au mode auquel chacune s'applique : | Étiquette UI | Mode | | :----------------------- | :------------------ | | Manuel | `default` | | Modifier automatiquement | `acceptEdits` | | Mode de planification | `plan` | | Mode auto | `auto` | | Ignorer les permissions | `bypassPermissions` | Avant v2.1.205, l'extension étiquetait `plan` comme Plan mode et `auto` comme Auto mode. Le mode auto apparaît dans l'indicateur de mode quand votre compte répond à chaque exigence listée dans la [section mode auto](#eliminate-prompts-with-auto-mode). Le paramètre `fuxiCode.initialPermissionMode` n'accepte pas `auto`. Pour démarrer en mode auto par défaut, définissez `defaultMode` dans vos [paramètres utilisateur](/fr/settings#settings-files) à la place. Fuxi Code ignore `defaultMode: "auto"` dans les paramètres de projet et locaux. Ignorer les permissions nécessite le bouton **Autoriser l'ignorance dangereuse des permissions** dans les paramètres de l'extension avant qu'il n'apparaisse dans l'indicateur de mode. Consultez le [guide VS Code](/fr/vs-code) pour les détails spécifiques à l'extension. Le plugin JetBrains exécute Fuxi Code dans le terminal IDE, donc le changement de mode fonctionne de la même manière que dans le CLI : appuyez sur `Maj+Tab` pour parcourir, ou passez `--permission-mode` lors du lancement. Utilisez le sélecteur de mode à côté du bouton d'envoi. Auto et Ignorer les permissions n'apparaissent qu'après les avoir activés dans les paramètres Desktop. Consultez le [guide Desktop](/fr/desktop#choose-a-permission-mode). Utilisez le menu déroulant de mode à côté de la boîte d'invite sur [fuxi.ai/code](https://fuxi.ai/code) ou dans l'application mobile. Les invites de permission apparaissent dans fuxi.ai pour approbation. Les modes qui apparaissent dépendent de l'endroit où la session s'exécute : * **Sessions cloud** sur [Fuxi Code sur le web](/fr/fuxi-code-on-the-web) : Accepter les modifications, Mode de planification et Mode auto. Accepter les modifications correspond au mode `default` : l'environnement cloud pré-approuve les modifications de fichiers indépendamment du mode, donc le menu déroulant affiche Accepter les modifications au lieu de Manuel. Les sessions cloud respectent toujours `defaultMode: "acceptEdits"` à partir des paramètres. Le mode auto n'apparaît que quand votre organisation l'autorise et que le modèle sélectionné le supporte. Ignorer les permissions n'est pas disponible. * **Sessions [Contrôle à distance](/fr/remote-control)** sur votre machine locale : Manuel, Accepter les modifications et Mode de planification. Vous ne pouvez pas sélectionner Auto ou Ignorer les permissions depuis l'application. {/* min-version: 2.1.202 */}Le menu déroulant affiche le mode dans lequel se trouve la session locale, y compris un mode défini depuis le terminal, et se met à jour quand le mode change dans l'application ou dans le terminal. La seule exception est Ignorer les permissions : la session ne signale jamais ce mode à fuxi.ai, donc basculer vers celui-ci depuis le terminal ne change pas ce que le menu déroulant affiche. Avant v2.1.202, les sessions connectées avec `/remote-control` ou `fuxi --remote-control` ne signalaient pas du tout leur mode, donc fuxi.ai et l'application mobile pouvaient afficher un mode dans lequel la session n'était pas. L'incohérence affectait uniquement l'étiquette : Fuxi Code a généré les invites de permission à partir du mode réel de la session, et elles ont toujours été affichées dans l'application pour approbation. Pour le Contrôle à distance, vous pouvez également définir le mode de démarrage lors du lancement de l'hôte : ```bash theme={null} fuxi remote-control --permission-mode acceptEdits ```

Approuver automatiquement les modifications de fichiers avec le mode acceptEdits

Le mode `acceptEdits` permet à Fuxi 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](#protected-paths) et toutes les autres commandes Bash invitent toujours. Quand l'[outil PowerShell](/fr/tools-reference#powershell-tool) 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 Manuel pour l'entrer, ou démarrez directement avec : ```bash theme={null} fuxi --permission-mode acceptEdits ```

Analyser avant de modifier avec le mode de planification

Le mode de planification indique à Fuxi de rechercher et de proposer des modifications sans les apporter. Fuxi 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 comme elles le font en mode Manuel, sauf si le [mode auto](/fr/auto-mode-config) est disponible et que `useAutoModeDuringPlan` est activé, ce qui est la valeur par défaut. Avec le mode auto actif, le classificateur approuve les commandes en lecture seule telles que les recherches et les lectures de fichiers sans demander de confirmation. Les modifications restent bloquées de toute façon jusqu'à ce que vous approuviez le plan. 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 : ```bash theme={null} fuxi --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, Fuxi 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](/fr/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 Fuxi 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 Fuxi ne procède. Quand [`showClearContextOnPlanAccept`](/fr/settings#available-settings) 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 `.fuxi/settings.json` : ```json theme={null} { "permissions": { "defaultMode": "plan" } } ```

Éliminer les invites de permission avec le mode auto

Le mode auto permet à Fuxi 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 Fuxi a lu. Les [règles d'ask](/fr/permissions#manage-permissions) explicites forcent toujours une invite. Le mode auto instruit également Fuxi à continuer à travailler sans s'arrêter pour des questions de clarification, bien que Fuxi 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](/fr/output-styles). Le mode auto réduit les invites de permission mais ne garantit pas la sécurité. Utilisez-le pour les tâches où vous faites confiance à la direction générale, pas comme remplacement de l'examen sur les opérations sensibles. 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 Fuxi Code](https://fuxi.ai/admin-settings/fuxi-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](/fr/permissions#managed-settings). * **Modèle** : sur l'API Anthropic, Fuxi Opus 4.6 ou ultérieur, ou Sonnet 4.6 ou ultérieur. Sur Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry et les sessions de [passerelle d'applications Fuxi](/fr/fuxi-apps-gateway) signées, uniquement Fuxi 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 fuxi-3, ne sont pas supportés sur aucun fournisseur. * **Fournisseur** : disponible par défaut sur l'API Anthropic. Sur Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry et les sessions de passerelle d'applications Fuxi signées, le mode auto est désactivé jusqu'à ce que vous [définissiez `FUXI_CODE_ENABLE_AUTO_MODE`](#enable-auto-mode-on-bedrock-agent-platform-or-foundry). Si Fuxi 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](/fr/errors#auto-mode-cannot-determine-the-safety-of-an-action). Si vous définissez `defaultMode: "auto"` dans les [paramètres](/fr/settings#available-settings) et que la session démarre en mode `default` sans erreur, le paramètre se trouve probablement dans `.fuxi/settings.json` ou `.fuxi/settings.local.json`. Fuxi 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 `~/.fuxi/settings.json`.

Activer le mode auto sur Bedrock, Agent Platform ou Foundry

Sur [Amazon Bedrock](/fr/amazon-bedrock), [Google Cloud's Agent Platform](/fr/google-vertex-ai), [Microsoft Foundry](/fr/microsoft-foundry) et les sessions de [passerelle d'applications Fuxi](/fr/fuxi-apps-gateway) signées, le mode auto n'apparaît pas dans le cycle `Shift+Tab` jusqu'à ce que `FUXI_CODE_ENABLE_AUTO_MODE` soit défini sur `1`. La variable fonctionne dans Fuxi Code v2.1.158 et ultérieur. Seuls Fuxi 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 `~/.fuxi/settings.json` : ```json theme={null} { "env": { "FUXI_CODE_ENABLE_AUTO_MODE": "1" } } ``` Pour l'activer pour votre organisation, ajoutez le même bloc `env` aux [paramètres gérés](/fr/settings#settings-files). 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, Fuxi Code ignore `defaultMode: "auto"` sauf si `FUXI_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](/fr/llm-gateway) 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 Fuxi](/fr/fuxi-apps-gateway) 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 pour celui-ci quand la session a commencé. {/* min-version: 2.1.200 */}Une télécommande ajoutée ou reorientée pendant la session avec `git remote add` ou `git remote set-url` n'est pas de confiance, et tout le reste est traité comme externe jusqu'à ce que vous [configuriez l'infrastructure de confiance](/fr/auto-mode-config). Avant v2.1.200, les télécommandes ajoutées en milieu de session étaient également 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 * Force push * {/* min-version: 2.1.203 */}Poussée vers la branche par défaut du dépôt quand la poussée porte du contenu sensible tel que des secrets ou des données personnelles ou confiées, porte des modifications dissimulées ou mal décrites par rapport à ce que vous avez demandé, porte du contenu porté ou d'abord lu de l'extérieur du dépôt, ou contourne une demande de tirage, un examen ou une vérification que vous avez demandés. Une poussée simple vers la branche par défaut n'est pas bloquée en elle-même, et l'effacement d'une poussée signalée nécessite de nommer le contenu signalé ou l'examen contourné, pas seulement la poussée. Le classificateur est une couche : les [règles `permissions.deny`](/fr/permissions#manage-permissions) s'appliquent dans tous les modes et peuvent bloquer les poussées vers la branche par défaut directement, et la protection de branche du dépôt distant s'applique toujours. Avant v2.1.203, toute poussée directe vers la branche par défaut était bloquée * {/* 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 * {/* min-version: 2.1.198 */}À partir de v2.1.198, `git commit --amend` quand le commit à HEAD a déjà été poussé. Une réécriture de message uniquement n'est pas bloquée : `--amend -m` sans rien de nouvellement préparé, sur un commit que Fuxi a créé pendant cette session * `terraform destroy`, `pulumi destroy`, `cdk destroy`, ou `terragrunt destroy`, et l'application d'un plan qui détruit les ressources Fuxi Code v2.1.195 et ultérieur bloquent plus de catégories par défaut. Plusieurs dépendent des entrées d'[environnement](/fr/auto-mode-config#define-trusted-infrastructure), 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 Fuxi, 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'un identifiant ou d'un jeton en direct dans la transcription ou un fichier * Accès à un emplacement listé comme emplacement de données sensibles dans votre [environnement](/fr/auto-mode-config#define-trusted-infrastructure), ou copie de données hors de celui-ci. {/* min-version: 2.1.198 */}À partir de v2.1.198, cela bloque également l'envoi de données d'un emplacement à un public que l'entrée exclut * Routage d'une installation de paquet autour de votre registre de paquets interne vers un registre public. {/* min-version: 2.1.198 */}À partir de v2.1.198, cela s'applique également quand vous avez dit à Fuxi qu'un registre interne ou un miroir existe dans la conversation, pas seulement quand un est listé dans votre environnement * Exécution d'une commande avec un drapeau qui désarme une garde de sécurité, comme `--insecure` * Lancement d'une boucle d'agent autonome qui s'exécute sans approbation humaine ou sandbox, comme une lancée avec `--dangerously-skip-permissions` ou `--no-sandbox`. {/* min-version: 2.1.198 */}À partir de v2.1.198, cela couvre également l'exécution d'un agent tiers ou d'un harnais d'évaluation avec isolation et approbation par action désactivées, comme un runner lancé avec `--yes-always` * Actions du navigateur [Fuxi in Chrome](/fr/chrome) qui pourraient envoyer le contenu de la page, les cookies ou les identifiants hors-origine Fuxi Code v2.1.198 et ultérieur bloquent également ceci par défaut : * Suppression de fichiers dans `/tmp`, `$TMPDIR`, ou un autre répertoire partagé de scratch ou de cache par caractère générique, glob, ou filtre d'âge plutôt que par un chemin nommé spécifique * Inclusion de détails sensibles dans le contenu envoyé, téléchargé, publié ou écrit à d'autres personnes ou systèmes partagés, quand votre propre message n'a pas autorisé ces détails pour ce destinataire. {/* min-version: 2.1.200 */}Les corps de PR et de problème, les messages de commit et les commentaires comptent comme ce type de contenu sortant quand le dépôt est en dehors de la limite de confiance ou public, y compris les dépôts publics de votre propre organisation ; les chemins de fichiers internes, les noms de code, les données de réponse API en direct telles que les e-mails ou les identifiants de compte, et les identifiants d'infrastructure comptent comme des détails sensibles. La portée PR, problème et message de commit nécessite Fuxi Code v2.1.200 ou ultérieur. {/* min-version: 2.1.203 */}Les données personnelles en direct d'une réponse API dans un corps de PR ou de problème, comme une adresse e-mail, un identifiant de compte ou d'organisation, ou une métrique d'utilisation, vous obligent à nommer ces détails et le destinataire indépendamment de la visibilité du dépôt ou de la limite de confiance. Cette vérification nécessite Fuxi Code v2.1.203 ou ultérieur * Envoi de frappes au volet tmux de Fuxi Code lui-même pour piloter sa propre interface, que le classificateur traite comme Fuxi changeant ses propres permissions ou surveillance Fuxi Code v2.1.200 et ultérieur bloquent également ceci par défaut : * Commentaire, suppression ou passage en force d'un test ou d'une assertion qui protège le comportement de sécurité, comme l'authentification, le contrôle d'accès, la validation des entrées ou le sandboxing * Suppression ou démantèlement d'une ressource avec état que Fuxi n'a pas créée dans la session, quand aucune règle de suppression plus spécifique ne s'applique et vous n'avez pas nommé cette ressource * Reorientation d'une URL de base API, d'un point de terminaison proxy, d'un récepteur webhook ou d'un miroir de registre vers un hôte tiers qui ne correspond pas à la tâche, y compris dans les fichiers d'exemple comme `.env.example` * Modification de la destination des poussées avec `git remote set-url` ou `git remote add`, sauf si vous avez nommé la nouvelle télécommande * Poussée de secrets ou de données personnelles ou confiées vers un dépôt connu pour être public, ou poussée de matériel confidentiel là-bas qui ne fait pas partie du travail propre de ce dépôt. {/* min-version: 2.1.203 */}Un dépôt de dotfiles est la seule exception pour les données personnelles ou confiées, et le contenu d'un dépôt privé atteignant n'importe quelle surface publique est bloqué de la même manière ; les deux raffinements nécessitent Fuxi Code v2.1.203 ou ultérieur. Avant v2.1.203, les données personnelles étaient groupées avec le matériel confidentiel et bloquées uniquement quand elles ne faisaient pas partie du travail propre de ce dépôt. Quand la visibilité d'un dépôt n'est pas établie, le classificateur ne bloque pas sur cela seul ; il juge le contenu par rapport aux autres règles à la place * Ouverture d'une demande de tirage contre un dépôt ou une organisation différente, forking avec `gh repo fork`, ou poussée vers un dépôt tiers, sauf si vous avez nommé cette cible externe Fuxi Code v2.1.203 et ultérieur bloquent également ceci par défaut : * Contenu d'un magasin local sensible, ou d'un fichier dont le nom, le chemin ou le type le marque comme sensible, entrant dans un commit, une poussée, un texte de PR ou de problème, un gist ou un paste, ou une publication de paquet, sauf si vous avez nommé à la fois la source et la destination. Les transcriptions de session et les journaux de conversation, les dossiers de points de configuration et d'identifiants tels que les clés SSH, les identifiants cloud, les profils de navigateur et l'historique du shell, et les exports de données utilisateur comptent tous, et le dépôt étant privé ne l'efface pas Fuxi Code v2.1.205 et ultérieur bloquent également ceci par défaut : * Écriture dans les transcriptions de session Fuxi Code, les fichiers d'historique `.jsonl` sous `~/.fuxi/projects/` ou votre répertoire de configuration configuré, directement ou via une commande shell. La règle couvre également les lignes de métadonnées que Fuxi Code ajoute à chaque entrée de transcription pour ses propres vérifications. Une transcription est un état de session que Fuxi Code écrit, pas un fichier de travail, et une entrée falsifiée atteint chaque vérification ultérieure une fois que vous reprenez la session, donc le mode auto bloque ces écritures en tant que défense en profondeur. La lecture d'une transcription n'est pas bloquée * Une suppression forcée récursive telle que `rm -rf "$VAR"` ou `Remove-Item -Recurse -Force $dir` dont la cible est une variable shell, ou un glob enraciné à celle-ci, qui n'est assignée nulle part dans la conversation que le classificateur voit. La valeur provenait uniquement de la sortie de commande antérieure, que le classificateur ne reçoit jamais, donc le classificateur ne peut pas vérifier la cible de suppression par rapport aux autres règles de suppression. Le classificateur lit la conversation plutôt que la sortie de commande par conception, donc il bloque l'appel au lieu de deviner la cible. Le blocage s'efface quand vous nommez le chemin exact en cours de suppression, ou quand Fuxi réexécute la suppression avec le chemin littéral résolu écrit dans la commande. Les suppressions dont la cible le classificateur peut résoudre ne sont pas affectées **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 Fuxi Fuxi Code v2.1.195 et ultérieur autorisent également ceci par défaut : * Suppression des tâches exactes que Fuxi 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`](/fr/auto-mode-config#define-trusted-infrastructure). Cela couvre le flux de données uniquement, pas les opérations destructrices ou d'identifiants sur la même infrastructure * Navigation [Fuxi in Chrome](/fr/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. {/* min-version: 2.1.198 */}À partir de v2.1.198, le classificateur réutilise son verdict pour un hôte et un port réseau au lieu de le réexécuter à chaque connexion : * Un allow est réutilisé jusqu'à ce que du nouveau contenu entre dans la conversation, auquel point cet hôte est vérifié à nouveau * Dans l'interface CLI interactive, un deny est supprimé quand le tour se termine * En [mode non-interactif](/fr/headless) et les sessions Agent SDK, il n'y a pas de limite de tour, donc un deny est réutilisé pour le reste de l'exécution * Changer votre mode de permission ou vos règles supprime tous les verdicts en cache Exécutez `fuxi 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](/fr/auto-mode-config).

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 à Fuxi « 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 Fuxi 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](/fr/costs#reduce-token-usage) supprime le message qui l'a énoncée. Pour une garantie absolue, ajoutez une [règle de refus](/fr/permissions#permission-rule-syntax) à 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 Fuxi 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](/fr/headless) 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](/fr/auto-mode-config). Chaque action passe par un ordre de décision fixe. La première étape correspondante gagne : 1. Les actions correspondant à vos [règles d'autorisation ou de refus](/fr/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. {/* min-version: 2.1.199 */}À partir de v2.1.199, un outil MCP marqué avec [`_meta["anthropic/requiresUserInteraction"]`](/fr/mcp#require-approval-for-a-specific-tool) ignore le classificateur et vous invite directement, donc une étape de consentement n'est jamais auto-approuvée au nom de l'auteur de l'outil 4. Si le classificateur bloque, Fuxi 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 FUXI.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 Fuxi ne le lise. Pour plus d'informations sur la façon dont ces couches fonctionnent ensemble, consultez l'[annonce du mode auto](https://fuxi.com/blog/auto-mode) et l'[analyse technique approfondie](https://www.anthropic.com/engineering/fuxi-code-auto-mode). Le classificateur vérifie le travail des [sous-agents](/fr/sub-agents) à trois points : 1. 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. 2. 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 `permissionMode` dans le frontmatter du sous-agent est ignoré. 3. 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. {/* min-version: 2.1.178 */}} L'étape 1 nécessite Fuxi Code v2.1.178 ou ultérieur. Les versions antérieures appliquaient le classificateur aux étapes 2 et 3, mais n'évaluaient pas la description de la tâche avant le démarrage du sous-agent. 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. {/* min-version: 2.1.198 */}À partir de v2.1.198, un verdict de réseau sandbox pour un hôte et un port est réutilisé au lieu d'être reclassifié à chaque connexion, donc les connexions répétées au même hôte n'ajoutent pas chacune une vérification. [Ce que le classificateur bloque par défaut](#what-the-classifier-blocks-by-default) décrit combien de temps un allow et un deny durent.

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

Le mode `dontAsk` refuse automatiquement chaque appel d'outil qui inviterait autrement. La barre d'état affiche `⏵⏵ don't ask on` tandis que ce mode est actif. Seules les actions correspondant à vos règles `permissions.allow` et les [commandes Bash en lecture seule](/fr/permissions#read-only-commands) peuvent s'exécuter ; les règles [`ask` explicites](/fr/permissions#manage-permissions) sont refusées plutôt que d'inviter. {/* min-version: 2.1.199 */}À partir de la v2.1.199, un outil MCP marqué avec [`_meta["anthropic/requiresUserInteraction"]`](/fr/mcp#require-approval-for-a-specific-tool) est également refusé dans ce mode même lorsqu'une règle allow correspond, car sa carte d'approbation nécessite une réponse que ce mode ne collecte jamais. Cela rend le mode entièrement non-interactif pour les pipelines CI ou les environnements restreints où vous prédéfinissez exactement ce que Fuxi peut faire. Les sessions cloud sur [Fuxi Code sur le web](/fr/fuxi-code-on-the-web) ignorent `defaultMode: "dontAsk"` ; consultez [bypassPermissions](#skip-all-checks-with-bypasspermissions-mode) pour plus de détails. Définissez-le au démarrage avec le drapeau : ```bash theme={null} fuxi --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](#protected-paths), que les versions antérieures invitaient toujours. Les [règles ask](/fr/permissions#manage-permissions) 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. {/* min-version: 2.1.199 */}À partir de la v2.1.199, les outils MCP marqués avec [`_meta["anthropic/requiresUserInteraction"]`](/fr/mcp#require-approval-for-a-specific-tool) invitent également toujours. Utilisez ce mode uniquement dans les environnements isolés comme les conteneurs, les machines virtuelles ou les dev containers sans accès à Internet, où Fuxi 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 : ```bash theme={null} fuxi --permission-mode bypassPermissions ``` Le drapeau `--dangerously-skip-permissions` est équivalent. Sur Linux et macOS, Fuxi Code refuse de démarrer dans ce mode lors de l'exécution en tant que root ou sous `sudo` : ```text theme={null} --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](/fr/devcontainer), qui exécute Fuxi Code en tant qu'utilisateur non-root. [Fuxi Code sur le web](/fr/fuxi-code-on-the-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](#switch-permission-modes) pour connaître les modes que les sessions cloud proposent. `bypassPermissions` n'offre aucune protection contre l'injection d'invite ou les actions involontaires. Pour les vérifications de sécurité en arrière-plan avec beaucoup moins d'invites, utilisez le [mode auto](#eliminate-prompts-with-auto-mode) à la place. Les administrateurs peuvent bloquer ce mode en définissant `permissions.disableBypassPermissionsMode` sur `"disable"` dans les [paramètres gérés](/fr/permissions#managed-settings).

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 Fuxi. | Mode | Écritures de chemins protégés | | :------------------------------- | :-------------------------------- | | `default`, `acceptEdits`, `plan` | Invitées | | `auto` | Acheminées vers le classificateur | | `dontAsk` | Refusées | | `bypassPermissions` | Autorisées | Les règles [`permissions.allow`](/fr/permissions#manage-permissions) 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 Fuxi Code n'évalue les règles allow des paramètres, donc une entrée telle que `Edit(.fuxi/**)` dans `~/.fuxi/settings.json` ou `.fuxi/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 `.fuxi/` offre **Oui, et autoriser Fuxi à modifier ses propres paramètres pour cette session**, ce qui approuve les écritures `.fuxi/` ultérieures dans cette session sans inviter à nouveau. Répertoires protégés : * `.git` * `.config/git` * `.vscode` * `.idea` * `.husky` * `.cargo` * `.devcontainer` * `.yarn` * `.mvn` * `.fuxi`, sauf pour `.fuxi/worktrees` où Fuxi 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`, `.fuxi.json`

Voir aussi

* [Permissions](/fr/permissions) : règles d'autorisation, de demande et de refus ; politiques gérées * [Configurer le mode auto](/fr/auto-mode-config) : indiquez au classificateur quelle infrastructure votre organisation fait confiance * [Hooks](/fr/hooks) : logique de permission personnalisée via les hooks `PreToolUse` et `PermissionRequest` * [Ultraplan](/fr/ultraplan) : exécutez le mode de planification dans une session Fuxi Code sur le web avec examen basé sur le navigateur * [Sécurité](/fr/security) : garanties de sécurité et meilleures pratiques * [Sandboxing](/fr/sandboxing) : isolation du système de fichiers et du réseau pour les commandes Bash * [Mode non-interactif](/fr/headless) : exécutez Fuxi Code avec le drapeau `-p`