{"meta":{"title":"Présentation des stratégies de système de fichiers pour le bac à sable local dans GitHub Copilot CLI","intro":"Lorsque le bac à sable local est activé, Copilot CLI exécute chaque processus ou opération en bac à sable sous une stratégie de système de fichiers qui contrôle les fichiers et répertoires qu’il peut lire et écrire. Découvrez comment cette stratégie est générée et comment vérifier l’accès qu’elle accorde.","product":"GitHub Copilot","breadcrumbs":[{"href":"/fr/copilot","title":"GitHub Copilot"},{"href":"/fr/copilot/concepts","title":"Concepts"},{"href":"/fr/copilot/concepts/agents","title":"Agent"},{"href":"/fr/copilot/concepts/agents/copilot-cli","title":"Copilot CLI"},{"href":"/fr/copilot/concepts/agents/copilot-cli/understanding-local-sandboxing","title":"Comprendre le bac à sable local"}],"documentType":"article"},"body":"# Présentation des stratégies de système de fichiers pour le bac à sable local dans GitHub Copilot CLI\n\nLorsque le bac à sable local est activé, Copilot CLI exécute chaque processus ou opération en bac à sable sous une stratégie de système de fichiers qui contrôle les fichiers et répertoires qu’il peut lire et écrire. Découvrez comment cette stratégie est générée et comment vérifier l’accès qu’elle accorde.\n\n## Introduction\n\nLorsque vous activez le bac à sable local, Copilot CLI exécute les commandes qu’il appelle pour votre compte à l’intérieur d’un bac à sable du système d’exploitation. Le bac à sable applique une **politique du système de fichiers** : un ensemble de règles qui déterminent quels chemins d’accès un processus ou une opération exécuté dans le bac à sable peut lire, lesquels il peut écrire et auxquels il ne peut pas accéder du tout.\n\nLa plupart de cette stratégie est assemblée automatiquement, de sorte que les commandes quotidiennes continuent de fonctionner sans configuration. Cet article explique comment Copilot détermine la stratégie et comment vérifier les autorisations qu’elle accorde dans un répertoire donné.\n\nPour obtenir une vue d’ensemble du bac à sable local, notamment comment l’activer et l’désactiver, consultez [À propos des environnements isolés dans le cloud et locaux pour GitHub Copilot](/fr/copilot/concepts/about-cloud-and-local-sandboxes) et [Utiliser le sandbox local](/fr/copilot/how-tos/cloud-and-local-sandboxes/using-local-sandboxing). Pour plus d’informations sur la configuration du bac à sable local, consultez [Configuration des paramètres de bac à sable local](/fr/copilot/how-tos/cloud-and-local-sandboxes/configuring-local-sandbox-settings).\n\n## À quoi s’applique la stratégie\n\nLa stratégie de système de fichiers couvre le travail Copilot en votre nom, mais elle est appliquée de différentes manières en fonction du type de travail :\n\n* **Les commandes shell et les recherches intégrées** s’exécutent comme des processus enfants isolés, de sorte que le système d’exploitation applique directement la politique. Les outils `grep` et `glob`, par exemple, exécutent ripgrep comme processus enfant isolé.\n* **Les processus MCP locaux et les serveurs de langage (LSP)** s’exécutent dans le sandbox par défaut. Par conséquent, le système d’exploitation leur applique également la stratégie. Vous pouvez modifier ce paramètre dans les paramètres du bac à sable, sauf si une stratégie gérée l’exige.\n* **Les outils intégrés de lecture et de modification de fichiers** font partie de Copilot CLI lui-même, plutôt que de s’exécuter comme un processus enfant isolé. Ils vérifient la même politique de système de fichiers avant de lire ou d’écrire un fichier, mais comme la sandbox du système d’exploitation n’a jamais connaissance de ces opérations, ce contrôle ne constitue qu’une protection logicielle, et non une protection appliquée par le système d’exploitation.\n* **Les serveurs MCP distants** s’exécutent à l’extérieur de votre machine, il n’existe donc aucun processus enfant local à sandboxer et la politique du système de fichiers ne s’applique pas à eux. Leurs connexions depuis le CLI peuvent toujours être limitées par la stratégie réseau lorsque **Sandbox MCP servers** est activé.\n* **Les subagents** utilisent d’autres outils pour effectuer leur travail. Le fait de savoir si la politique s’applique, et de quelle manière, dépend de l’outil qu’un sous-agent invoque.\n\nUn **processus** isolé dans un bac à sable est donc contraint par le système d’exploitation, tandis qu’une **opération** au sein du processus applique la même politique au niveau logiciel, c’est pourquoi cet article parle d’un processus isolé ou d’une opération au sein du processus plutôt que seulement de commandes.\n\n## Niveaux d’autorisation\n\nLe bac à sable est **refusé par défaut** : sauf si un chemin d’accès est explicitement accordé, une commande ne peut pas l’utiliser. Chaque chemin d’accès de la stratégie comporte l’un des trois niveaux d’autorisation suivants :\n\n* **Lecture/écriture** : la commande peut lire et modifier des fichiers à ce chemin d’accès.\n* **Lecture seule** : la commande peut lire des fichiers sur ce chemin d’accès, mais pas les modifier.\n* **Refusé** : la commande ne peut pas lire ou écrire sur ce chemin, même si une règle plus large l’autoriserait autrement.\n\nPuisque l’accès est refusé tant qu’il n’a pas été accordé, Copilot doit accorder à une commande l’accès à tout ce dont elle a légitimement besoin — les fichiers de votre projet, les outils qu’elle exécute et des emplacements annexes tels que les répertoires temporaires — tout en laissant tout le reste inaccessible.\n\n> \\[!NOTE]\n> Ces niveaux d’autorisation s’appliquent à chaque processus ou opération en bac à sable (sandbox), mais ils sont appliqués différemment : pour les processus enfants en bac à sable,le système d’exploitation les applique directement, tandis que les propres outils de lecture de fichiers et de modification de fichiers intégrés de l’interface CLI vérifient les mêmes niveaux dans les logiciels, sans sauvegarde du système d’exploitation.\n\n## Création de la stratégie\n\nAvant le démarrage de chaque processus isolé, Copilot CLI détermine la stratégie effective pour ce processus à l’aide du répertoire de travail actuel, de l’environnement, des paramètres et des autorisations automatiques. Cela inclut les emplacements courants nécessaires aux outils, de sorte que vous n’avez pas besoin de les autoriser un par un vous-même. Les outils peuvent également recevoir l’accès aux fichiers de session sélectionnés et aux compétences installées dont ils ont besoin pour fonctionner.\n\n### Votre répertoire de travail\n\nLorsque **l’option Inclure le répertoire de travail** est activée dans les paramètres du système de fichiers pour le bac à sable local (comme c’est le cas par défaut), le répertoire de travail actuel reçoit un accès en lecture/écriture. Dans un référentiel Git, Copilot ajoute également les subventions Git associées. La désactivation de ce paramètre supprime toutes ces subventions automatiques afin d’ajouter manuellement des règles d’autorisation pour le projet requis et les chemins Git. Consultez « [Configuration des paramètres de bac à sable local](/fr/copilot/how-tos/cloud-and-local-sandboxes/configuring-local-sandbox-settings) ».\n\n> \\[!NOTE]\n> Si vous obtenez Copilot d’une organisation appartenant à l’entreprise, un administrateur peut désactiver le paramètre **Inclure le répertoire de travail** et le verrouiller. Vous ne pouvez donc pas le réactiver. Consultez « [Paramètres gérés par l’entreprise](/fr/copilot/reference/enterprise-administrators/enterprise-managed-settings#sandbox) ».\n\n### Outils dans votre variable PATH\n\nPour exécuter un programme tel que `python` ou `git`, le bac à sable doit laisser la commande voir le répertoire dans lequel se trouve le programme. Lorsque **l’accès à l’outil de développement** est activé, tel qu’il est par défaut,Copilot accorde un accès en **lecture seule** aux répertoires répertoriés dans votre `PATH` variable d’environnement, ainsi que les répertoires nommés par des variables d’outil associées telles que `GOPATH`, `JAVA_HOME`et `PYTHONPATH`. Le mode lecture seule est le niveau d’accès approprié pour les outils externes : une commande doit être exécutée sur `git`, sans le modifier. Si vous désactivez **l’accès à l’outil de développement** , ces répertoires ne sont plus accordés automatiquement et doivent provenir de vos propres règles d’autorisation. Pour obtenir la liste complète des variables d’environnement et de chaîne d’outils que le `PATH` bac à sable inspecte, et comment chacun d’eux est interprété, consultez [Référence de commande CLI pour GitHub Copilot](/fr/copilot/reference/copilot-cli-reference/cli-command-reference#sandbox-tool-directory-grants).\n\n### Emplacements du système et du profil\n\nSur macOS, les emplacements système standard reçoivent une autorisation en lecture seule afin que les commandes puissent charger des bibliothèques partagées et lire la configuration du système sans pouvoir les modifier. Les répertoires d’application dans votre profil utilisateur (par exemple, les sous-répertoires d’Windows `%LOCALAPPDATA%\\Programs` ou les `~/.local/bin``~/.local/lib` répertoires sur macOS et Linux) sont également autorisés en lecture seule lorsque **l’accès aux outils de développement** est activé, afin que les commandes puissent lire les outils que vous avez installés sans pouvoir les modifier.\n\n### Caches du gestionnaire de package\n\nQuand **autoriser l’accès aux outils de développement** est activé, Copilot accorde l’accès aux caches et registres utilisés par les gestionnaires de package courants et les chaînes d’outils. La plupart des emplacements sont en lecture seule. Les emplacements sélectionnés, tels que le cache de npm, les caches de build et certains magasins de dépendances, sont accessibles en écriture afin que les installations et les builds puissent fonctionner.\n\nCes autorisations dépendent de la commande et des outils détectés dans votre projet. Ils peuvent suivre les emplacements de cache que vous avez configurés en dehors des répertoires habituels. Certains fichiers de configuration autorisés contiennent des identifiants du registre, et des caches accessibles en écriture peuvent être partagés avec des commandes que vous exécutez en dehors du sandbox. Désactivez **l’accès aux outils de développement** si vous préférez accorder ces accès vous-même.\n\nDans le `/sandbox policy` rapport, la section **Outils de développement** répertorie les outils détectés et leurs chemins d’accès. Les caches accessibles en écriture sélectionnés sont créés lorsqu’une commande en a besoin. Ils peuvent donc ne pas apparaître dans le rapport avant la première utilisation.\n\n### Référentiels Git\n\nLorsque vous travaillez dans un sous-répertoire d’un référentiel Git, Copilot accorde l’accès **en lecture** au référentiel entier afin que les commandes puissent voir le projet complet, tout en limitant les **écritures** dans votre répertoire de travail actuel et les métadonnées Git du référentiel (son `.git` répertoire). Cela permet à une commande de lire dans le référentiel, mais conserve les modifications axées sur l’endroit où vous travaillez.\n\nÉtant donné que l’accès en lecture s’étend sur l’ensemble du référentiel, une commande en bac à sable peut lire des fichiers en dehors de votre sous-répertoire actuel, y compris tout élément sensible stocké ailleurs dans le projet. Pour rendre certains chemins d’accès inaccessibles, vous pouvez ajouter des règles de refus d’accès. Consultez « [Configuration des paramètres de bac à sable local](/fr/copilot/how-tos/cloud-and-local-sandboxes/configuring-local-sandbox-settings) ».\n\n## Lorsque les règles d’accès se chevauchent\n\nÉtant donné que Copilot accorde plusieurs emplacements, et que vous pouvez ajouter les vôtres, les règles peuvent se chevaucher. Lorsque les octrois en lecture seule et en lecture/écriture se chevauchent, le **chemin plus spécifique gagne**. Par exemple, si `/project` est accessible en écriture, mais que vous marquez `/project/secrets` en lecture seule, tout ce qui se trouve dans `/project` reste accessible en écriture, sauf `/project/secrets`. Les chemins refusés sont prioritaires sur les deux types d’autorisation.\n\nLes autorisations de répertoire d’outils découvertes sont remplacées par un accès en lecture/écriture qui les couvre déjà. Considérez un projet Python avec un environnement virtuel local (`.venv`) qui apparaît sur votre `PATH`. Considérer ce répertoire comme un emplacement d’outil ordinaire en lecture seule le rendrait en lecture seule, même s’il se trouve dans votre projet accessible en écriture, et une commande telle que `pip install` pourrait alors échouer lorsqu’elle tenterait de mettre à jour l’environnement.\nCopilot laisse cela modifiable en écriture dans le cadre de votre espace de travail. Les autres règles en lecture seule, y compris celles que vous configurez vous-même, ne sont pas ignorées de cette façon.\n\nLes règles que **vous** configurez ne sont pas supprimées uniquement parce que le même chemin d’accès a été découvert automatiquement. Vous pouvez les utiliser pour restreindre l’accès à un emplacement sensible, tel qu’un `.env` fichier existant. Les chemins manquants et les liens symboliques nécessitent des soins supplémentaires, comme décrit dans [Résolution des problèmes d’accès au système de fichiers](#troubleshooting-filesystem-access).\n\n## Vérification de ce que la stratégie actuelle autorise\n\nÉtant donné que la stratégie est définie pour chaque répertoire et chaque commande, le moyen le plus simple de connaître les accès dont vous disposez est d’interroger Copilot CLI. Dans une session, saisissez :\n\n```shell copy\n/sandbox policy\n```\n\nCopilot imprime la politique **effective** pour votre répertoire actif. Les chemins d’accès sont regroupés par source, tels que **les chemins configurés par l’utilisateur** et **les outils de développement**, et par niveau d’accès. Le rapport inclut également les paramètres réseau et une section **Capacités** couvrant les paramètres tels que le contournement, le bac à sable MCP/LSP et l’authentification. Il s’agit du résultat de la combinaison de l’octroi automatique, de vos paramètres et des restrictions gérées, et pas seulement d’une copie de vos paramètres enregistrés.\n\nPour inspecter l’accès à l’outil développeur pour une commande particulière, ajoutez la commande après `policy`. Par exemple:\n\n```shell copy\n/sandbox policy npm install\n```\n\nCela ne s’exécute pas `npm install`. Il montre le niveau d’accès que la commande recevrait. L’aperçu ne crée aucun répertoire, y compris les chemins d’accès manquants ou refusés et les caches d’outils.\n\nVoici quelques points à garder à l’esprit lorsque vous lisez le rapport :\n\n* Elle reflète votre **répertoire actif**. Comme les autorisations sont détectées par répertoire, les mêmes paramètres peuvent correspondre à des chemins différents selon l’endroit où vous exécutez la commande.\n* Consultez **Notes** pour les chemins d’accès configurés qui n’ont pas pu être inclus. Les autorisations en lecture/écriture ou en lecture seule manquantes sont omises. Sur Linux, les chemins refusés manquants sont omis de cet aperçu, mais la préparation du lancement les crée avant d’appliquer la stratégie. L’aperçu les conserve sur macOS et sur des hôtes Windows qui prennent en charge les chemins interdits.\n* Si le sandboxing est désactivé, `/sandbox policy` vous l’indique au lieu d’afficher une politique, puisqu’aucune restriction ne s’applique.\n\nPour vérifier uniquement si le bac à sable est actuellement activé, utilisez `/sandbox status`. Pour plus d’informations sur ces commandes, consultez [Utiliser le sandbox local](/fr/copilot/how-tos/cloud-and-local-sandboxes/using-local-sandboxing).\n\n## Résolution des problèmes d’accès au système de fichiers\n\nSi un chemin d’accès en lecture/écriture ou en lecture seule configuré n’existe pas, créez-le en dehors du sandbox avant de recommencer la commande. Un processus enfant en cours d’exécution conserve la stratégie reçue lors du lancement. La création ultérieure d’un chemin d’accès n’ajoute pas d’autorisation manquante à ce processus. Redémarrez un serveur exécuté depuis longtemps s’il a besoin de l’accès mis à jour.\n\nAvant qu’un processus en bac à sable démarre, Copilot CLI crée les chemins d’accès interdits manquants et leurs répertoires parents sur votre ordinateur. Cela inclut les chemins d’accès destinés aux fichiers, de sorte qu’un `.env` manquant devient un répertoire. Les répertoires restent une fois le processus terminé.\n\nSi un chemin non autorisé ne peut pas être préparé, le processus ne démarre pas. L’aperçu en lecture seule `/sandbox policy` n’effectue pas cette préparation, c’est pourquoi les chemins refusés absents y sont omis sur Linux. Pour la résolution des problèmes, consultez [Utiliser le sandbox local](/fr/copilot/how-tos/cloud-and-local-sandboxes/using-local-sandboxing#troubleshooting-blocked-paths-that-do-not-exist).\n\nUn lien symbolique à l’intérieur d’un répertoire autorisé ne garantit pas l’accès à une cible en dehors de ce répertoire. Si un message de refus nomme une telle cible, inspectez-le et accordez l’accès uniquement si cela est voulu. L’ajout d’un lien symbolique résolvable lui-même via `/sandbox config` ajoute également sa cible actuelle pour l’accès en lecture/écriture ou en lecture seule. Les règles de chemin définies manuellement et les octrois d’outils de développement détectés automatiquement n’ajoutent pas automatiquement cette cible.\n\nLes chemins refusés sont gérés différemment des autorisations : l’interface CLI résout leur chemin d’accès écrit et leur cible actuelle. Sur Linux, un lien symbolique refusé protège sa cible, mais n’empêche pas de manière fiable le lien lui-même d’être remplacé. Préférez interdire l'accès au répertoire sensible réel plutôt que de recourir à une règle de liaison symbolique seule.\n\nPour les défaillances réseau, les restrictions gérées et les choix de contournement, consultez [Résolution des problèmes liés aux commandes bloquées](/fr/copilot/how-tos/cloud-and-local-sandboxes/using-local-sandboxing#troubleshooting-blocked-commands).\n\n## Personnalisation de la stratégie\n\nVous pouvez accorder des chemins d’accès en lecture/écriture ou en lecture seule, refuser des chemins d’accès et modifier d’autres comportements de système de fichiers, à partir de la `/sandbox config` boîte de dialogue ou dans votre fichier de paramètres. Après avoir apporté une modification, exécutez `/sandbox policy` pour confirmer le résultat. Pour obtenir des instructions pas à pas, consultez [Configuration des paramètres de bac à sable local](/fr/copilot/how-tos/cloud-and-local-sandboxes/configuring-local-sandbox-settings).\n\n## Stratégies gérées par l’entreprise\n\nSi vous obtenez Copilot via une organisation détenue par l’entreprise, un administrateur peut appliquer une stratégie relative au système de fichiers via des paramètres gérés. Les paramètres managés agissent comme une base de référence restrictive : ils peuvent nécessiter le bac à sable, ajouter des chemins refusés et limiter les chemins que vous êtes autorisés à accorder. Lorsqu’un paramètre managé s’applique, la `/sandbox config` boîte de dialogue l’affiche sous la forme d’une valeur verrouillée **(gérée)** et `/sandbox policy` la reflète dans la stratégie résolue. Si la stratégie effective autorise le contournement du bac à sable, un utilisateur peut désactiver explicitement le bac à sable pour le reste de la session active, à partir d’une invite d’autorisation de contournement active ou en exécutant `/sandbox disable`. Cette désactivation pour cette session n’assouplit pas la stratégie enregistrée.\n\nContrairement à la plupart des configurations, où une seule source prévaut, la politique de sandbox est définie par toutes les sources en vigueur simultanément. Les paramètres gérés peuvent arriver simultanément par plusieurs canaux — gérés par le serveur, MDM et basés sur des fichiers — et ils se combinent entre eux, ainsi qu’avec vos propres paramètres, selon l’option **la plus restrictive**, au lieu qu’une source en remplace une autre : une option requise reste activée, les chemins interdits provenant de toutes les sources s’additionnent, et les chemins que vous êtes autorisé à accorder ne peuvent qu’être davantage restreints. Pour plus d’informations, consultez « [Paramètres gérés par l’entreprise](/fr/copilot/reference/enterprise-administrators/enterprise-managed-settings#sandbox) ».\n\n## Lectures complémentaires\n\n* [À propos des environnements isolés dans le cloud et locaux pour GitHub Copilot](/fr/copilot/concepts/about-cloud-and-local-sandboxes)\n* [Utiliser le sandbox local](/fr/copilot/how-tos/cloud-and-local-sandboxes/using-local-sandboxing)\n* [Configuration des paramètres de bac à sable local](/fr/copilot/how-tos/cloud-and-local-sandboxes/configuring-local-sandbox-settings)"}