Workspace trust et ce qu’un dépôt fait faire à l’agent

Qu’est-ce que le workspace trust, et que change la confiance accordée à un dossier ?

Dans l’article sur les hooks, nous avons parlé des commandes qu’un agent exécute de lui-même ; dans l’article sur la sécurité MCP, des serveurs ajoutés à un dépôt ; et dans l’article sur la sandbox, de ce qui limite les commandes de l’agent. Cet article porte sur la question commune aux trois : quand vous ouvrez un dépôt avec un agent de codage, que peut le dépôt faire faire à l’agent ? La réponse courte :

Le workspace trust sert la première voie. La première fois que vous ouvrez un dossier, l’outil vous demande si vous lui faites confiance et, tant que ce n’est pas le cas, ne charge pas une partie de la configuration du dépôt. Selon la documentation de VS Code, le but est d’empêcher le code de s’exécuter tout seul ; c’est pourquoi le Restricted Mode désactive ou limite les agents, le terminal, les tâches, le débogage, les réglages de l’espace de travail et les extensions. Voici ce qui reste désactivé dans les cinq outils tant que vous n’avez pas fait confiance au dossier :

Source : documentation et notes de version des outils, 20 octobre 2026. « Non précisé dans la documentation » : dans les pages que nous avons lues ce jour-là, nous n’avons trouvé aucune phrase qui le décrive. Dans Gemini CLI, la décision est enregistrée dans ~/.gemini/trustedFolders.json.

Les outils ont un point commun : la confiance est accordée au dossier, pas à son contenu. Claude Code lie la confiance à la racine du dépôt, et elle couvre tout le dépôt. Dans Copilot CLI, une fois que vous faites confiance à un dossier pour les sessions futures, la question ne revient plus ; Gemini CLI ne demande lui aussi qu’une fois par dossier. Un hook arrivé plus tard dans un dépôt auquel vous faites confiance peut donc s’exécuter sans nouvelle question. Le ver npm décrit plus bas a emprunté exactement ce chemin.

Dans VS Code, faire confiance à un dossier parent revient à faire confiance à tous les dossiers qu’il contient. La documentation en tire une organisation : gardez les dépôts de confiance dans un dossier, ceux que vous ne connaissez pas dans un autre, et ne faites confiance qu’au premier. Si vous lancez Claude Code directement dans votre répertoire personnel, la confiance ne vaut que pour cette session et n’est pas écrite sur le disque.

Pour Gemini CLI, deux sources disent des choses différentes. La page Trusted Folders (mise à jour le 23 avril) indique que la fonction est désactivée par défaut ; les notes de version v0.59.0 (8 septembre) écrivent que la politique de confiance est désormais « fail-closed ». Vérifiez le réglage security.folderTrust.enabled dans votre propre installation. Le 18 juin 2026, Google a cessé de servir Gemini CLI aux utilisateurs gratuits et aux abonnés Google AI Pro et Ultra, et les a orientés vers Antigravity CLI ; avec une clé d’API payante, vous pouvez continuer à utiliser Gemini CLI.

Avec quels fichiers un dépôt peut-il exécuter du code ?

Quand un agent de codage ouvre un dossier, plusieurs fichiers peuvent exécuter du code d’eux-mêmes. La plupart entrent dans le dépôt par un commit et apparaissent dans le diff de la pull request. L’un d’eux n’apparaît dans aucun diff :

Plusieurs outils peuvent lire le même fichier : Copilot CLI lit aussi le .claude/settings.json du dépôt, et Cursor CLI fusionne les hooks de Claude Code avec les siens. Nous avons détaillé les hooks dans l’article sur les hooks et les fichiers MCP dans l’article sur MCP. Ici, nous regardons comment des attaquants se servent de ces fichiers ; les deux exemples datent d’août et de septembre.

Selon le rapport d’Aikido, le 4 août, des attaquants ont pris le contrôle du compte GitHub du mainteneur de la bibliothèque keyv et ont placé dans les paquets un ver qui vole des identifiants. Le lendemain, au moins 444 paquets et 1 381 versions étaient touchés. Si le ver trouvait un token de GitHub App parmi les identifiants volés, il commitait dans les dépôts qu’il pouvait atteindre, jusqu’à 50 branches par dépôt. Ces commits ajoutaient des hooks à .claude/settings.json et à .vscode/tasks.json ; leur auteur était claude, leur message chore: update config.

Selon l’analyse d’Elastic Security Labs, ce qui était ajouté pour Claude Code était un hook SessionStart, exécuté à chaque nouvelle session, et pour VS Code une tâche folderOpen, exécutée à l’ouverture du dossier. La conclusion d’Elastic : il suffit au développeur d’ouvrir le dépôt pour être infecté. Selon Aikido, même npm install n’était pas nécessaire.

La question de confiance peut très bien ne pas intervenir ici : la confiance est accordée une fois à un dossier, alors que le nouveau hook arrive par un commit dans un dépôt que vous ouvrez tous les jours. VS Code a une barrière de plus : les tâches automatiques ne s’exécutent jamais dans un dossier non fiable et, dans un dossier de confiance, elles demandent par défaut une autorisation une fois. Dans une pull request, c’est le diff lui-même qui permet de le repérer : une « mise à jour de config » qui ajoute un hook à .claude/settings.json. L’auteur et le message du commit avaient l’air ordinaires ; regardez le contenu.

Le second exemple est le fichier qui n’arrive pas par un commit. Selon GitSpawn, l’étude publiée par Manifold Security le 1er septembre, les agents de codage exécutent des commandes git en arrière-plan pour recueillir du contexte ; certains le faisaient avant même que vous ayez tapé quoi que ce soit, avant la question de confiance. En rafraîchissant l’index, des commandes comme git status exécutent le programme indiqué dans le réglage core.fsmonitor, et git lit ce réglage dans le propre .git/config du dépôt. Le résultat, tel que Manifold le décrit : le dépôt nomme une commande, et git l’exécute avec vos droits, hors de la sandbox et sans aucune demande d’approbation.

La manière dont le fichier arrive compte. Selon Manifold, cloner le dépôt depuis une adresse malveillante ne déclenche pas la faille, pas plus que fetch ou pull ; git ne transmet pas ce réglage. Pour que l’attaque fonctionne, le dépôt doit arriver avec son propre dossier .git : dans un fichier zip, sur un lecteur partagé, dans un dossier synchronisé ou sur une clé USB. La règle de l’étude tient en une phrase : tout réglage qui nomme un programme peut l’exécuter. Le jour de la publication, 4 des 8 constats étaient corrigés ; consultez les notes de version de votre outil. Ce fichier n’apparaît dans aucun diff et peut s’exécuter avant la question de confiance ; vous ne pouvez l’examiner qu’au moment où le dossier vous parvient.

Un agent qui tourne en CI pose-t-il la question de confiance ?

Non ; il n’y a personne à qui la poser. Les outils diffèrent par ce qu’ils font à la place : certains utilisent la configuration du projet, d’autres ne la chargent pas du tout, d’autres s’arrêtent. Si un agent examine vos pull requests en CI, regardez ce tableau :

Source : documentation et notes de version des outils, 20 octobre 2026. « Non précisé dans la documentation » : dans les pages que nous avons lues ce jour-là, nous n’avons trouvé aucune phrase qui le décrive. Cursor CLI se comporte ainsi depuis janvier 2026. Quand la confiance dans les dossiers est activée, Gemini CLI arrête une exécution non interactive avec FatalUntrustedWorkspaceError.

La documentation des autorisations de Claude Code montre ce cas dans un tableau à part. Lors d’une exécution claude -p dans un dossier qui n’a jamais reçu la confiance, les règles allow ne sont pas utilisées, mais les hooks du fichier de réglages et le bloc env le sont. Nous avons traité le côté MCP dans l’article sur MCP. La documentation dit aussi quoi faire avec un dépôt que vous n’avez pas écrit : avec --setting-sources user, Claude Code ne lit pas du tout les fichiers de réglages du projet ; avec --bare, il ne lit dans le projet ni hooks, ni skills, ni sous-agents, ni plugins, mais le bloc env du projet s’applique toujours. Pour couper les hooks, passez disableAllHooks à cette exécution avec --settings. Selon la documentation, l’écrire seulement dans vos propres réglages utilisateur ne suffit pas, car les réglages du projet peuvent l’emporter sur les vôtres et le remettre à false.

Dans Copilot CLI, surveillez une variable : si COPILOT_ALLOW_ALL vaut exactement true, la CLI fait confiance au dossier sans demander et charge tout ce que contient le dépôt, y compris les hooks qui exécutent des commandes shell. Si vous voyez cette variable dans un workflow, vérifiez si le job tourne sur la branche de la pull request. La documentation de Codex fait aussi une mise en garde propre à la CI : dans les jobs qui récupèrent ou exécutent le code du dépôt, ne définissez pas la clé d’API comme variable d’environnement au niveau du job ; les scripts de build, les tests et les hooks d’installation des dépendances peuvent la lire.

Dans Gemini CLI, cette faille est devenue un avis de sécurité et a été corrigée. Selon l’avis GHSA-wpqr-6v78-jr5g sur GitHub (24 avril 2026, critique, CVSS 10,0), les anciennes versions faisaient automatiquement confiance au dossier lorsqu’elles tournaient en CI. L’avis nomme clairement le risque : les workflows de CI qui examinent des pull requests soumises par des utilisateurs. Des variables d’environnement placées dans le dossier .gemini/ d’un tel dépôt pouvaient mener à une exécution de code à distance. La faille a été corrigée dans Gemini CLI 0.39.1 et dans l’action run-gemini-cli 0.1.22 ; désormais, il faut faire explicitement confiance au dossier, y compris en exécution non interactive.

Qu’est-ce que la prompt injection, et une pull request peut-elle tromper un bot de review ?

La prompt injection consiste à glisser des instructions dans un texte que lit un modèle pour changer son comportement. L’OWASP en distingue deux formes : la prompt injection directe, faite par l’entrée de l’utilisateur lui-même, et la prompt injection indirecte, cachée dans une page web ou un fichier que le modèle lit depuis l’extérieur. Selon l’OWASP, le texte n’a même pas besoin d’être visible pour un humain ; il suffit que le modèle le lise. Pour un agent de codage, ce texte peut être un fichier du dépôt, la description d’une pull request, une issue ou un commentaire.

Le workspace trust ne ferme pas cette voie : dès que vous lancez l’agent dans un dossier, vous lui faites aussi lire le texte de ce dossier. C’est pourquoi la documentation de VS Code recommande d’ouvrir en Restricted Mode un projet que vous n’avez pas examiné. Tout fichier que l’agent fait entrer dans son contexte peut mener à une prompt injection ; en Restricted Mode, les agents ne tournent pas du tout. Contre le texte, il vous reste deux leviers : l’endroit d’où les règles sont lues et ce que l’agent a le droit de faire.

GitInject (7 juin 2026) a mesuré jusqu’où cela peut aller en CI, sur de vrais workflows GitHub. Les chercheurs ont testé les configurations de workflow de 4 fournisseurs d’IA et documenté 11 attaques. Elles se répartissent en quatre classes : injection dans les fichiers de configuration, exfiltration d’identifiants, manipulation du jugement et atteinte à la disponibilité. Chaque fournisseur testé s’est révélé vulnérable à au moins une classe dans sa configuration par défaut. Selon les auteurs, les failles les plus graves ne viennent pas du comportement du modèle, mais de la façon dont l’infrastructure de CI gère les identifiants et les fichiers de configuration.

Pour tromper un bot de review, il n’est même pas nécessaire d’écrire des instructions. PRWeaver (3 août 2026) a construit 208 attaques dans 10 dépôts réels, chacune validée en l’exécutant, et a fait examiner chacune sous quatre présentations (832 cas) par 3 agents de review sur 6 configurations de modèles. Quand les pull requests étaient examinées une par une, entre 50 % et 60 % des attaques ont été détectées ; quand 24 pull requests étaient examinées d’un coup, le taux tombait entre 16 % et 22 %. Glisser l’attaque dans un vrai changement, avec une description crédible qui explique les deux, a fait baisser le taux de détection de 10 à 18 points de pourcentage. Répartir l’attaque sur plusieurs commits a changé le résultat d’au plus 5 points.

La conclusion des auteurs : la dissimulation fonctionne le mieux quand des changements inoffensifs et malveillants se trouvent ensemble sous les yeux du relecteur, ou quand l’objectif annoncé dans la description rend le diff plausible. La liste de l’article sur l’examen du code généré par l’IA a un point pour cela : chaque affirmation de la description doit se retrouver dans le diff. Après PRWeaver, posez aussi la question inverse : chaque changement du diff a-t-il une raison dans la description ?

Le moyen d’orienter durablement un bot de review, c’est de changer ses règles. Si le fichier de règles est lu sur la branche de la pull request, la pull request peut aussi changer les règles de sa propre review. La documentation des outils dit des choses différentes à ce sujet :

Source : documentation des outils, 20 octobre 2026. « Non précisé dans la documentation » : dans les pages que nous avons lues ce jour-là, nous n’avons trouvé aucune phrase qui le décrive.

GitHub Agentic Workflows est un exemple de droits restreints pour l’agent : l’agent tourne avec des droits en lecture seule, et les écritures, comme une pull request qu’il ouvrirait, ne sont pas appliquées tout de suite mais mises en attente. Selon la documentation, un job distinct s’exécute avant leur application et cherche dans la sortie des tentatives de prompt injection, des secrets divulgués et du code malveillant. Un agent trompé ne peut faire que les dégâts que permettent les droits que vous lui avez donnés.

Que faire face à un dépôt ou une pull request que vous ne connaissez pas ?

En résumé : la question de confiance est posée une fois, jamais en CI, et elle ne filtre pas le texte. Ce qu’il faut faire dépend du cas :

• Un dépôt que vous ne connaissez pas. Ne lui faites pas confiance. VS Code recommande, en cas de doute, de laisser le dossier en Restricted Mode, et Cursor d’ouvrir un dépôt non fiable dans un simple éditeur de texte. Si vous devez y travailler avec un agent, ouvrez-le dans une machine virtuelle ou un conteneur ; la documentation de Claude Code recommande elle aussi les machines virtuelles. Une sandbox seule ne suffit pas : dans Claude Code, la sandbox ne couvre que les commandes shell, et les hooks et les serveurs MCP restent en dehors. Les détails sont dans l’article sur la sandbox.
• Un dossier qu’on vous a transmis. Si un dossier arrivé en zip, sur un lecteur partagé ou sur une clé USB contient .git, comme le recommande Manifold, lisez .git/config avant de l’ouvrir avec un agent, ou clonez à nouveau le dépôt depuis sa source.
• Un agent qui examine en CI des pull requests venues de forks. Ne laissez pas l’agent charger la configuration du projet : passez --setting-sources user dans Claude Code, et n’utilisez pas COPILOT_ALLOW_ALL dans Copilot CLI ni --trust dans Cursor CLI sur la branche de la pull request. Le guide de GitHub du 7 mai 2026 juge permissions: read-all raisonnable par défaut et dit de ne jamais passer la sortie du modèle à eval. Ne mettez aucun secret dans l’étape de l’agent.
• Une pull request qui touche un fichier de réglages ou de règles. Lisez un diff qui touche l’un des fichiers de la deuxième section comme un changement de sécurité ; le guide de GitHub considère lui aussi tout changement qui affaiblit la CI comme bloquant. Si votre bot de review lit ses règles sur la branche de la pull request, un changement du fichier de règles décide aussi de la façon dont cette pull request sera examinée ; lisez-le, lui aussi, comme du code.

Nous avons posé les mêmes questions à notre propre service de review. Notre outil de revue de code par IA, diffox, clone le dépôt à neuf depuis GitHub dans un dossier vide à chaque review ; comme un clone ne transporte pas .git/config, le chemin utilisé par GitSpawn ne nous atteint pas. Comme nous l’avons décrit dans l’article sur l’architecture, les règles sont lues sur la branche dans laquelle la pull request sera fusionnée. L’auteur d’une pull request venue d’un fork peut écrire le diff et les noms de fichiers comme il veut ; mais le texte qui en passe dans notre commentaire ne peut ni ouvrir une balise HTML ni devenir un lien. Cette règle est là pour empêcher qu’un lien d’hameçonnage apparaisse sous notre nom, que quelqu’un ferme la section repliée pour écrire une fausse section « aucun problème », et que des données fuient par une image.

Questions fréquentes

Qu’est-ce que le workspace trust ?

C’est l’outil de codage ou l’éditeur qui vous demande, la première fois que vous ouvrez un dossier, si vous lui faites confiance, et qui ne charge pas une partie de la configuration du dossier tant que ce n’est pas le cas. Le but est d’empêcher les hooks, les tâches et les serveurs MCP placés dans un dépôt de s’exécuter avant que vous les ayez regardés. Claude Code, Codex, GitHub Copilot, Cursor et Antigravity CLI en disposent ; dans l’éditeur de Cursor, il est désactivé par défaut. La confiance est accordée une fois à un dossier, et elle n’empêche pas le texte du dossier d’orienter l’agent.

Qu’active la confiance accordée à un dossier dans Claude Code ?

Claude Code lie la confiance à la racine du dépôt, et elle couvre tout le dépôt. Une fois la confiance accordée, les règles allow et les répertoires supplémentaires du .claude/settings.json du projet, les hooks et les serveurs MCP des sous-agents et les plugins venus du dépôt sont utilisés ; les hooks et le bloc env du fichier de réglages s’exécutent aussi dans la session. Les serveurs de .mcp.json ont leur propre demande. La question n’apparaît qu’en session interactive ; claude -p et le SDK ne demandent jamais. Si vous le lancez dans votre répertoire personnel, la confiance ne vaut que pour cette session.

Comment retirer un dossier de confiance ?

Cela dépend de l’outil. Dans VS Code, ouvrez l’éditeur Workspace Trust (Workspaces: Manage Workspace Trust) et retirez le dossier de la liste des dossiers de confiance. Dans Copilot CLI, modifiez la liste trustedFolders dans ~/.copilot/config.json. Dans Gemini CLI, tapez /permissions dans ce dossier ; toutes les décisions sont dans ~/.gemini/trustedFolders.json. Dans Codex, mettez le trust_level de ce projet à untrusted dans ~/.codex/config.toml. Claude Code enregistre la confiance dans le champ hasTrustDialogAccepted de ~/.claude.json ; une commande pour l’annuler n’est pas précisée dans la documentation. La documentation de Cursor et celle d’Antigravity n’en parlent pas non plus.

Peut-on désactiver le workspace trust dans VS Code ?

Oui : le réglage security.workspace.trust.enabled (activé par défaut) désactive complètement la fonction, tandis que l’option --disable-workspace-trust ne le fait que pour cette session. VS Code conseille lui-même l’inverse : en cas de doute, laissez le dossier en Restricted Mode ; vous pourrez accorder la confiance plus tard. En Restricted Mode, les agents, les tâches, le débogage et le terminal sont désactivés. Vous pouvez regrouper les dépôts que vous ouvrez souvent dans un dossier parent et ne faire confiance qu’à ce dossier, et garder les dépôts que vous ne connaissez pas dans un autre.

Qu’est-ce que la prompt injection ?

C’est le fait de cacher des instructions dans un texte que lit un modèle pour changer son comportement. L’OWASP en distingue deux formes : la prompt injection directe, faite par l’entrée de l’utilisateur lui-même, et la prompt injection indirecte, cachée dans une page web, un fichier ou un commentaire que le modèle lit depuis l’extérieur. Avec les agents de codage, c’est la seconde qui ressort : un fichier du dépôt, la description d’une pull request ou le texte d’une issue entre dans le contexte de l’agent. Selon l’OWASP, le texte n’a même pas besoin d’être visible pour un humain ; il suffit que le modèle le lise.

Une pull request peut-elle tromper un outil de revue de code par IA ?

Les études montrent que oui. Dans PRWeaver, des agents de review IA ont détecté entre 50 % et 60 % des attaques dissimulées quand les pull requests étaient examinées une par une, et entre 16 % et 22 % quand 24 pull requests étaient examinées ensemble ; une description crédible a fait baisser le taux encore davantage. Dans GitInject, les 4 fournisseurs testés étaient tous vulnérables à au moins une classe d’attaques dans leur configuration par défaut. Vérifiez si votre outil lit ses règles sur la branche de la pull request ou sur la branche dans laquelle elle sera fusionnée. Chez diffox, les règles sont lues sur la branche dans laquelle la pull request sera fusionnée, et le texte de la pull request qui passe dans son commentaire ne peut devenir ni une balise ni un lien.

La question de confiance apparaît-elle avec claude -p ou en CI ?

Non. Selon la documentation de Claude Code, claude -p et les sessions SDK n’affichent jamais la question de confiance ; les hooks du fichier de réglages du dépôt, le bloc env et apiKeyHelper sont utilisés, et les serveurs de .mcp.json se connectent sans demander. Dans un dépôt que vous n’avez pas écrit, lancez-le avec --setting-sources user ou --bare ; pour couper les hooks, passez disableAllHooks avec --settings. Le mode -p de Copilot CLI ne charge pas les hooks du dépôt dans un dossier non fiable ; Cursor CLI s’arrête tant que vous ne passez pas --trust.