Codex ou Cursor sur un dépôt non fiable : quelle barrière de sécurité choisir ?

Un dépôt peut être techniquement légitime sans être entièrement fiable. Il peut contenir une issue copiée depuis l’extérieur, un fichier d’instructions modifié, un script d’installation, un hook Git ou une capture d’écran conçue pour influencer l’agent. Dans ce contexte, comparer Codex et Cursor sur la seule qualité du code produit passe à côté du risque principal : ce que l’outil peut lire, exécuter ou transmettre avant même que le développeur ait relu le diff.

La bonne question est donc plus étroite : quelle combinaison de permissions, de validation et d’isolement permet d’examiner un dépôt suspect sans transformer l’assistant en opérateur de la machine ? Le tableau ci-dessous propose une méthode de décision. Il ne remplace pas un test exécuté sur votre environnement et ne présente aucun résultat de benchmark.

1. Commencer par classer le dépôt

Avant de choisir un outil, séparez trois situations. Un dépôt de confiance peut recevoir un accès de travail plus large, à condition de conserver une revue du diff. Un dépôt connu mais partiellement fiable doit être traité avec des permissions réduites et des données synthétiques. Un dépôt réellement non fiable ne doit pas être ouvert directement dans un environnement de développement contenant des secrets, des identifiants ou des accès réseau utiles.

Cette précaution est importante pour Codex : la documentation de l’action officielle rappelle que les instructions du dépôt, les messages de commit, les descriptions de pull request et certains médias doivent être considérés comme des entrées non fiables. Elle recommande de choisir la politique de fichiers et de réseau la plus étroite compatible avec la tâche, sans confondre cette politique avec les privilèges du processus qui exécute Codex. La documentation de sécurité de Codex Action décrit précisément cette séparation.

Cursor formule une recommandation encore plus restrictive pour les dépôts non fiables : utiliser un éditeur de texte basique plutôt que l’agent. Sa documentation indique aussi que la confiance d’espace de travail est désactivée par défaut, que les fichiers peuvent être modifiés sans approbation et que les modes d’exécution restent des garde-fous, pas une frontière de sécurité absolue. La documentation Agent Security de Cursor doit donc être lue avant toute activation automatique.

2. Comparer les barrières, pas les slogans

3. Le protocole minimal avant la première question

1. Créer une copie isolée. Clonez le dépôt dans une machine virtuelle, un conteneur ou un compte sans accès aux répertoires personnels. N’utilisez pas votre checkout habituel.
2. Établir l’état initial. Notez le commit étudié, les fichiers présents, les remotes, les hooks, les sous-modules et les scripts déclarés. Cette étape sert à distinguer ce qui existait avant l’intervention de ce qui apparaîtra ensuite.
3. Retirer les privilèges inutiles. Supprimez les variables d’environnement sensibles, les clés SSH, les jetons cloud et les credentials helpers. Une permission de lecture limitée ne protège pas un hôte qui expose encore des identifiants au processus.
4. Commencer en lecture seule. Demandez d’abord un inventaire des fichiers, des scripts et des points d’entrée suspects. N’autorisez ni installation, ni commande réseau, ni modification.
5. Traiter les instructions comme des preuves. Un fichier AGENTS.md, un README ou un commentaire de ticket peut décrire le projet, mais ne doit pas élargir les permissions de l’agent.
6. Autoriser une seule action réversible. Si une modification est nécessaire, limitez-la à un dossier de travail et demandez un diff. Toute commande supplémentaire doit être justifiée séparément.
7. Rejouer hors agent. Les tests ou scripts proposés ne sont exécutés qu’après inspection humaine, dans une copie reconstruite, avec des données synthétiques.

4. Où Codex et Cursor se distinguent réellement

Codex est intéressant lorsque l’équipe veut formaliser une politique de permissions qui sépare le système de fichiers, le réseau, l’approbation et le compte d’exécution. La documentation de sécurité de Codex Security rappelle toutefois que l’outil s’exécute sous le compte local et qu’un dépôt à analyser doit être autorisé sans être automatiquement considéré comme digne de confiance. Elle précise également qu’un worker en lecture seule n’est pas, à lui seul, un environnement isolé ou hors ligne. La politique de sécurité de Codex Security est donc une source utile pour concevoir le périmètre, pas une promesse d’invulnérabilité.

Cursor fournit de son côté des contrôles visibles autour de l’approbation des commandes, des appels MCP, des requêtes réseau, de la confiance du workspace et des fichiers ignorés. Ses modes d’exécution peuvent être pratiques dans un dépôt maîtrisé, mais la documentation les décrit comme des garde-fous « best-effort ». Pour un dépôt non fiable, le choix raisonnable est de rester en mode restreint ou de ne pas ouvrir l’agent du tout.

Un exemple explicitement hypothétique montre la différence entre confort et contrôle : une équipe reçoit un dépôt contenant un script de préparation et un fichier d’instructions qui demande à l’agent d’exécuter ce script avant toute analyse. Dans Codex comme dans Cursor, l’instruction doit être considérée comme une donnée à examiner. Le bon comportement consiste à signaler le script, vérifier ses effets attendus dans une copie sans secrets et demander une décision humaine. L’agent ne doit pas transformer cette demande en permission implicite.

5. La décision par profil de risque

Pour une simple lecture de code non sensible, les deux outils peuvent être évalués dans une copie locale sans credentials. Pour une proposition de correctif, préférez un profil qui autorise uniquement l’écriture dans le workspace temporaire et qui bloque le réseau. Pour un dépôt issu d’une contribution externe, ne branchez ni MCP, ni navigateur, ni terminal automatique avant d’avoir inspecté les fichiers d’instructions et les scripts. Pour une analyse de sécurité automatisée, utilisez un groupe de reviewers dédié et une pull request séparée ; Codex Security indique que ses résultats validés sont proposés pour revue humaine plutôt que fusionnés automatiquement. La documentation officielle de Codex Security décrit ce flux de validation et de correction.

Le maillage de ce protocole avec un guide sur la sécurisation d’un serveur MCP est pertinent dès qu’un outil externe peut lire des fichiers ou déclencher une action. Si des identifiants existent déjà dans l’environnement, commencez par protéger les secrets accessibles aux agents de code avant de comparer les interfaces.

6. Le choix pragmatique

Il n’existe pas de vainqueur universel pour un dépôt non fiable. Le meilleur choix est celui qui permet de réduire l’autorité de l’agent avant de lui donner du contexte. Dans une équipe qui veut piloter finement les permissions et séparer les profils d’exécution, Codex peut servir de base à une politique explicite. Dans une équipe déjà organisée autour de Cursor, les protections de workspace, les approbations et les règles de sandbox peuvent convenir, mais seulement avec un dépôt temporaire et sans mode automatique permissif.

Dans les deux cas, trois règles restent non négociables : un dépôt autorisé n’est pas nécessairement digne de confiance, une instruction présente dans le dépôt n’est jamais une permission, et un diff relisible ne prouve pas qu’aucune donnée sensible n’a quitté l’environnement. La comparaison doit donc se conclure par un protocole reproductible, un état initial conservé et une validation humaine avant toute commande irréversible.