Vous utilisez OpenAI Codex dans votre workflow de développement et vous vous demandez ce que l’agent peut lire dans votre dépôt ? La question est légitime. Un ticket ouvert sur le dépôt officiel met en lumière une lacune de sécurité que beaucoup de développeurs n’ont pas encore anticipée.
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.
Concrètement, 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.
Pourquoi c’est un enjeu de sécurité sérieux
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.
Ce qu’il faut retenir
- L’issue #2847 sur
openai/codexsignale l’absence d’un mécanisme natif pour exclure des fichiers sensibles du contexte envoyé au modèle. - La demande porte sur un fichier
.codexignoreà double niveau : dépôt et global utilisateur. - Des fichiers critiques comme
.env,.pem, les clés SSH ou les credentials AWS sont potentiellement lisibles par l’agent sans restriction configurée. - Une tentative précédente (issue #205) avait été fermée sans implémentation effective dans
codex-rs. - En l’état, aucune solution technique native n’existe : les contournements reposent sur la discipline des équipes, pas sur des garanties techniques.
Si vous utilisez Codex en production, c’est le moment d’auditer ce que l’agent peut atteindre dans vos dépôts. Si le sujet vous intéresse ou que vous avez mis en place des solutions concrètes, échangeons en commentaire ou suivez le blog pour les prochaines analyses.