Codex lit le dépôt. L’exclusion des fichiers sensibles n’est toujours pas un vrai contrôle : la communauté le demande, le contournement reste artisanal.
OpenAI Codex et les fichiers sensibles : le problème concret
Le 28 août 2025, un développeur nommé mkusaka a ouvert l’issue #2847 sur le dépôt GitHub officiel openai/codex. La demande est claire: il n’existe pas de mécanisme natif pour empêcher l’agent Codex de lire ou d’envoyer au modèle des fichiers sensibles présents dans un projet.
Codex peut accéder à des fichiers comme .env, .pem, des clés privées SSH ou des répertoires .aws/ et .ssh/. Il n’existe aucune configuration déterministe pour l’en empêcher. C’est un angle mort de sécurité réel pour tout développeur qui utilise Codex sur une base de code contenant des secrets.
Le ticket est toujours ouvert au moment de la publication de cet article. Il est labellisé enhancement et sandbox, ce qui indique qu’OpenAI reconnaît le sujet sans avoir encore fourni de solution.
Ce que demande la communauté
L’auteur de l’issue propose un mécanisme inspiré de .gitignore: un fichier .codexignore configurable à deux niveaux.
- Niveau dépôt: un fichier
.codexignorelocal, partageable avec l’équipe via le contrôle de version. - Niveau global: un fichier de configuration utilisateur, applicable à tous les projets sur une même machine.
L’idée est de permettre des règles fines. Par exemple, autoriser Codex à explorer node_modules/ pour vérifier des implémentations, tout en lui interdisant formellement de lire .env, .env.*, id_rsa, .aws/ ou .ssh/. La configuration doit être déterministe, partageable et ne pas reposer sur des conventions informelles de documentation.
L’auteur précise également qu’une issue similaire (#205) avait été fermée en faveur d’une implémentation dans codex-rs (la réécriture en Rust). Or, au 28 août 2025, cette fonctionnalité n’existe toujours pas dans codex-rs. L’issue #2847 vise à relancer la discussion et à converger vers un design concret.
Les assistants IA pour le code ont accès à beaucoup plus
Les assistants IA pour le code ont accès à beaucoup plus de contexte qu’un simple éditeur de texte. Quand un agent lit un fichier pour l’envoyer à un modèle distant, les données transitent sur des infrastructures tierces. Sans mécanisme d’exclusion explicite, plusieurs risques émergent.
- Fuite de secrets: clés API, tokens OAuth, credentials de base de données.
- Exposition de certificats privés et de clés SSH.
- Envoi involontaire de fichiers de configuration contenant des informations d’infrastructure.
- Impossibilité d’auditer ce que le modèle a réellement reçu comme contexte.
Ce n’est pas un risque théorique. Les fichiers .env sont présents dans la majorité des projets modernes. L’absence d’un .codexignore force les équipes à faire confiance aux conventions plutôt qu’à une configuration technique vérifiable.
Ce qui existe aujourd'hui comme contournement
En l’absence de solution native, les développeurs doivent improviser. Quelques approches courantes, mais aucune n’est satisfaisante à l’échelle d’une équipe.
- Stocker les secrets hors du répertoire de travail, dans des emplacements non indexés.
- Utiliser des variables d’environnement injectées au runtime plutôt que des fichiers
.envcommittés ou présents sur disque. - Restreindre les permissions système du processus Codex via des solutions de sandboxing externes.
- Documenter les fichiers à ne pas exposer dans le README, ce qui repose sur la discipline humaine et non sur une contrainte technique.
Aucune de ces options ne remplace un mécanisme intégré, déterministe et auditable.
Où en est OpenAI sur ce sujet ?
Le ticket reste ouvert sans assignation ni réponse officielle documentée dans les données publiques disponibles. OpenAI n’a pas publié d’annonce de roadmap précisant quand ou si cette fonctionnalité sera implémentée. Le label sandbox suggère que le sujet est dans le radar de l’équipe produit, mais sans engagement public sur un délai.
Le dépôt openai/codex cumule plus de 94 000 étoiles sur GitHub, ce qui témoigne d’un usage massif. Une lacune de sécurité sur un outil aussi répandu mérite une réponse rapide et documentée.
L'issue #2847 sur openai/codex signale l'absence d'un mécanisme natif pour exclure des fichiers sensibles du contexte envoyé au modèle.