Une vulnérabilité corrigée dans Roo Code avant la version 3.20.3 a été évaluée à 8,1 sur 10 selon le score CVSS, car une écriture de fichier approuvée automatiquement pouvait contribuer à une exécution de code via une configuration MCP malveillante. (github.com)
Symptôme → Roo Code vous demande constamment l’autorisation de lire, modifier, exécuter ou appeler un outil externe.
Solution la plus rapide → n’activez pas toutes les approbations automatiques : commencez par la lecture, ajoutez les écritures réversibles, testez ensuite les commandes et gardez les secrets, déploiements, suppressions et outils MCP sensibles derrière une confirmation humaine.
Cette méthode s’adresse à trois profils précis
Cet article vous concerne si vous êtes développeur et que les demandes de confirmation interrompent vos tâches répétitives, si vous préparez un environnement de développement distant pour un agent continu, ou si vous devez contrôler les permissions d’un assistant capable de toucher au dépôt, au terminal et aux services externes.
Il ne s’agit pas d’un guide général de Roo Code, ni d’une promesse selon laquelle un bac à sable supprimerait tous les risques. Le but est de vous donner une séquence d’acceptation vérifiable, avec un point d’arrêt clair à chaque étape.
Le principe de sécurité : l’approbation suit l’impact, pas la commodité
Roo Code distingue plusieurs familles d’outils. Sa documentation décrit notamment les groupes de lecture, d’édition, de commande et d’intégration MCP, tandis que les modes peuvent recevoir des ensembles d’outils différents. (github.com)
La première erreur consiste à considérer « automatique » comme une permission unique. En réalité, vous devez séparer au moins cinq niveaux :
| Niveau d’action | Exemple | Décision initiale | Note de risque |
|---|---|---|---|
| Lecture | Rechercher un symbole ou lire un fichier du dépôt | Autoriser dans un périmètre limité | 1/5 |
| Édition réversible | Modifier un fichier source sur une branche de test | Autoriser après vérification du diff | 2/5 |
| Commande locale | Lancer des tests ou une compilation déterministe | Autoriser au cas par cas | 3/5 |
| Navigateur ou réseau | Ouvrir une page, envoyer une requête ou télécharger une ressource | Confirmation manuelle au départ | 4/5 |
| MCP à effet externe | Écrire dans un service, publier, supprimer ou accéder à une ressource sensible | Refuser l’automatisation par défaut | 5/5 |
Les opérations suivantes doivent rester manuelles, même si elles semblent ponctuelles : lecture de clés privées ou de jetons, modification de fichiers dans .roo/, changement d’un répertoire système, installation d’un paquet depuis une source non vérifiée, suppression récursive, publication, migration de base de données et déclenchement d’un pipeline.
Le correctif de sécurité publié pour les versions antérieures à 3.20.3 est un rappel concret : une approbation automatique d’écriture ne se limite pas à la ligne modifiée. Elle peut changer la configuration de l’agent, notamment lorsque MCP est activé et que le dépôt contient des fichiers contrôlant son fonctionnement. (github.com)
Pour une vue plus large des principes de permissions minimales appliqués aux agents, vous pouvez également consulter notre guide sur la réduction des privilèges des agents de programmation.
Étape 1 : préparer un périmètre qui puisse être détruit
Avant de modifier les réglages de Roo Code, créez un dépôt de test ou une branche dédiée. Le dépôt doit contenir une petite fonctionnalité représentative, un jeu de tests et un fichier dont la restauration est facile. Évitez d’y placer des clés, des fichiers .env réels, des certificats ou des scripts de déploiement fonctionnels.
Procédez dans cet ordre :
- Vérifiez le chemin exact du dossier de travail transmis à Roo Code.
- Confirmez que le dépôt est bien suivi par Git et que l’état initial est propre.
- Retirez les identifiants hérités de l’environnement du terminal.
- Créez une branche réservée aux essais d’automatisation.
- Préparez une commande de restauration, par exemple une réinitialisation vers un commit connu, après avoir vérifié qu’elle ne supprimera pas de données utiles.
- Activez uniquement les outils nécessaires au premier scénario.
- Capturez les réglages avant le test, puis conservez le diff et les journaux après le test.
Le premier contrôle ne consiste pas à demander à Roo Code de « faire quelque chose d’utile ». Demandez-lui plutôt de lister les fichiers visibles, de lire un fichier autorisé et de tenter de lire un chemin situé hors du dépôt. Le test réussi comporte deux éléments : la lecture prévue fonctionne et l’accès hors périmètre est refusé ou reste soumis à une demande explicite.
Point de vigilance : un chemin symbolique, un montage partagé ou un script appelé depuis le dépôt peut élargir le périmètre réel. La restriction affichée dans l’interface ne remplace donc pas la vérification du système de fichiers et du compte utilisé par l’agent.
Étape 2 : ouvrir l’édition seulement après avoir vérifié le retour arrière
La deuxième phase consiste à laisser Roo Code modifier quelques fichiers, mais sans lui donner un accès indistinct à tout le dépôt.
Utilisez trois scénarios :
- correction d’un fichier source connu ;
- ajout d’un test dans un répertoire autorisé ;
- modification volontairement demandée d’un fichier exclu.
Après chaque action, examinez le diff, les nouveaux fichiers et les permissions. Vérifiez également que Git peut restaurer l’état précédent sans intervention complexe. Une modification dans le code est généralement récupérable ; une modification dans les réglages de l’agent, les scripts de construction ou les fichiers de secrets ne doit pas être traitée comme une simple édition.
| Contrôle d’édition | Critère de passage | Critère d’arrêt | Preuve à conserver |
|---|---|---|---|
| Fichier source autorisé | Le diff correspond à la demande | Fichiers supplémentaires modifiés | Diff Git et capture du réglage |
| Branche de test | Aucun changement sur la branche stable | Tentative de changement de branche ou de publication | Nom de branche et journal |
| Fichier exclu | Demande refusée ou confirmée manuellement | Modification silencieuse | Journal de refus |
| Restauration | Retour à l’état initial vérifié | Fichier impossible à restaurer | Commit de référence et résultat |
| Configuration Roo Code | .roo/ et fichiers de contrôle restent protégés |
Écriture automatique non prévue | Diff de configuration |
Les consignes officielles indiquent que les modes personnalisés peuvent limiter les groupes d’outils et les fichiers éditables. Utilisez cette séparation comme une barrière de conception, mais ne la considérez pas comme une preuve suffisante : la validation doit porter sur les fichiers réellement touchés. (github.com)
Étape 3 : tester les commandes avec leurs paramètres réels
L’exécution du terminal est le moment où une automatisation confortable devient rapidement dangereuse. Une commande de test peut être prévisible dans un dossier et modifier un autre emplacement si son répertoire courant, ses variables ou ses paramètres changent.
Testez séparément les familles suivantes :
| Famille | Exemple de scénario de test | Automatisation envisageable | Ce qui doit rester bloqué |
|---|---|---|---|
| Compilation | Construire le projet dans le dépôt de test | Oui, si le chemin est fixe | Construction avec script téléchargé |
| Tests unitaires | Exécuter la suite locale sans réseau | Oui, si les tests sont déterministes | Tests qui publient ou modifient une base externe |
| Installation | Installer des dépendances verrouillées | Avec prudence | Paquet non verrouillé, script distant ou privilèges élevés |
| Nettoyage | Supprimer des artefacts générés | Oui, avec dossier explicitement limité | Suppression récursive ou chemin calculé |
| Déploiement | Simuler une livraison vers une cible factice | Non au début | Publication, migration et redémarrage de service |
Pour chaque commande, notez le binaire appelé, le dossier courant, les variables d’environnement, les chemins écrits et les connexions réseau. Testez aussi un argument mal formé ou une variable absente : vous devez savoir si l’échec arrête l’agent ou s’il déclenche une nouvelle tentative avec une portée différente.
Roo Code prévoit un réglage de limitation des requêtes automatiquement approuvées ; sa documentation donne notamment l’exemple d’un plafond de 5 appels, avec arrêt avant l’appel suivant, ou d’un mode illimité. Utilisez un plafond fini durant la validation, car une boucle de correction ne doit pas pouvoir consommer indéfiniment des appels ou modifier le dépôt sans nouvelle revue. (github.com)
La version en ligne de commande documente également un mode exigeant une approbation manuelle pour les actions, les commandes, le navigateur et MCP. Son mode interactif par défaut peut, lui, approuver automatiquement ces catégories ; vous devez donc vérifier le mode de lancement au lieu de supposer que l’interface graphique et la ligne de commande appliquent les mêmes règles. (github.com)
Étape 4 : traiter le navigateur et MCP comme des sorties du dépôt
Le navigateur n’est pas une permission de lecture neutre. Il peut ouvrir une page contrôlée par un tiers, envoyer des données, télécharger un fichier ou exposer le contenu d’une session connectée. Durant la première série de tests, autorisez seulement une navigation vers une ressource sans compte et vérifiez les journaux réseau.
Pour Roo Code MCP, séparez deux décisions :
- le serveur est-il activé et accessible ?
- quels outils de ce serveur peuvent être approuvés sans confirmation ?
La présence d’un serveur fiable ne rend pas automatiquement fiables toutes ses fonctions. Un serveur peut proposer simultanément une lecture, une écriture, une suppression et une action distante. La liste d’autorisation doit donc contenir des noms d’outils précis, jamais une confiance générale accordée au serveur.
| Type d’outil MCP | Exemple d’effet | Autorisation recommandée | Vérification obligatoire |
|---|---|---|---|
| Lecture de données | Lire un schéma ou rechercher un document | Possible après limitation de la ressource | Données accessibles et absence de secret |
| Écriture locale ou distante | Créer un ticket ou modifier un document | Validation manuelle au départ | Paramètres, propriétaire et journal |
| Action externe | Déclencher un travail ou publier un artefact | Refus automatique par défaut | Cible, identité et procédure d’arrêt |
| Ressource sensible | Lire des secrets, données clients ou dépôts privés | Jamais en approbation permanente | Identifiant injecté, durée et révocation |
Dans la configuration MCP, examinez les listes d’outils approuvés, l’état activé ou désactivé du serveur, les variables d’environnement et les éventuels en-têtes d’authentification. Les exemples de configuration publiés autour de Roo Code montrent que des outils individuels peuvent être placés dans une liste d’approbation automatique ; cela doit être interprété comme une permission fine, et non comme une garantie de sécurité fournie par le serveur. (github.com)
Pour préparer votre propre contrôle, utilisez notre liste de vérification pour l’intégration des outils MCP, puis documentez pour chaque outil la donnée lue, la donnée écrite, le compte utilisé et la méthode de révocation.
Étape 5 : effectuer un essai distant avec succès et échec volontaire
Un agent qui fonctionne sur votre poste n’est pas automatiquement acceptable sur une machine distante. Dans un environnement de développement distant, ajoutez une vérification distincte des permissions du compte, du réseau sortant, des volumes montés et des journaux.
Planifiez deux tâches :
- une tâche autorisée et réversible, comme modifier un test puis lancer la compilation ;
- une tâche volontairement interdite, comme lire un fichier de secret, écrire hors du dépôt ou appeler un outil MCP non autorisé.
Le premier scénario doit produire un diff contrôlable et une restauration réussie. Le second doit laisser une trace exploitable, ne pas atteindre la cible protégée et arrêter l’action avant un effet externe.
Sur un Mac distant, contrôlez en plus les autorisations macOS, l’accès aux trousseaux, les agents de session, les outils de développement et la présence éventuelle de Xcode. Une machine capable de compiler une application audio, vidéo ou de design peut disposer d’outils et de bibliothèques supplémentaires ; cette richesse augmente aussi le nombre de chemins qu’un agent peut exploiter. Pour une prise en main distante, notre guide sur l’accès VNC à un Mac aide à distinguer l’accès visuel du contrôle réellement accordé au processus.
Le score de l’essai peut rester simple :
| Domaine évalué | 0 point | 1 point | 2 points |
|---|---|---|---|
| Limitation du dépôt | Accès non maîtrisé | Limitation déclarée mais non testée | Accès testé et refus hors périmètre |
| Retour arrière | Impossible | Partiel ou manuel | Restauration vérifiée |
| Commandes | Portée inconnue | Quelques commandes testées | Paramètres et échecs contrôlés |
| MCP | Serveurs largement ouverts | Liste partielle | Outils et données documentés |
| Secrets | Présents dans l’environnement | Masqués sans rotation | Séparés, minimaux et révocables |
| Journaux et arrêt | Absents | Disponibles après incident | Conservés, horodatés et arrêt testés |
Ne passez à l’étape suivante que si vous obtenez au moins 10 points sur 12 et si aucun contrôle critique — secrets, suppression, déploiement ou écriture hors dépôt — n’a échoué. Ce seuil est une règle de gouvernance proposée pour votre validation, pas une garantie officielle de Roo Code.
Après une mise à jour, la validation recommence
L’approbation automatique n’est pas une configuration permanente. Recommencez la vérification lorsqu’un événement modifie le périmètre ou le comportement possible de l’agent :
- mise à jour de Roo Code ou changement de mode ;
- ajout, remplacement ou modification d’un serveur MCP ;
- changement d’un script de construction ou de test ;
- ajout d’une nouvelle clé ou variable d’environnement ;
- déplacement du dépôt vers une autre machine ;
- changement de compte macOS, de volume monté ou de sortie réseau.
Conservez l’approbation si les actions restent limitées, réversibles, journalisées et prévisibles. Réduisez-la si les commandes ont gagné des paramètres, si les outils MCP ont changé ou si les journaux sont incomplets. Révoquez-la immédiatement après une écriture hors périmètre, une tentative de lecture de secret, un échec de restauration ou une action externe non prévue.
Roo Code documente aussi des différences entre les modes et les groupes d’outils ; un changement de mode peut donc modifier les capacités disponibles même si le dépôt n’a pas changé. (github.com)
Votre configuration actuelle est-elle vraiment adaptée ?
Un poste local quotidien est pratique, mais il mélange souvent le dépôt de production, les sessions connectées, les clés de développement, les volumes personnels et les outils nécessaires à l’audio, à la vidéo ou au design. Une machine distante mal isolée ne règle pas ce problème : elle peut simplement déplacer les mêmes secrets vers un autre système, avec une visibilité moindre sur les journaux et les processus.
Pour un besoin temporaire de test, de préproduction ou d’exécution continue, louer un Mac auprès de SSHMac peut offrir une séparation plus nette entre votre poste habituel et l’environnement Roo Code, à condition de conserver des identifiants dédiés, un dépôt de test et une politique de permissions minimale. Si vous évaluez une machine distante, examinez surtout l’accès, la durée d’utilisation, la conservation des données et la procédure de remise à zéro, plutôt qu’une promesse vague d’automatisation.
La bonne décision n’est donc pas de chercher le réglage qui supprime toutes les confirmations. C’est de commencer par une tâche réversible dans un environnement isolé, de vérifier les refus et la restauration, puis d’élargir uniquement les autorisations dont les preuves sont encore valides.