OpenAI Codex : les développeurs réclament un .codexignore

Un ticket ouvert sur le dépôt officiel d'OpenAI Codex cristallise une inquiétude que beaucoup de développeurs n'avaient pas formulée explicitement : l'agent de codage ne dispose d'aucun mécanisme natif pour empêcher la lecture de fichiers sensibles. Créé le 28 août 2025 par l'utilisateur mkusaka, le ticket demande l'introduction d'un fichier `.codexignore` -- symétrique au `.gitignore` -- qui permettrait de désigner explicitement les chemins que l'agent ne doit ni lire ni transmettre au modèle. Les exemples cités sont concrets : fichiers `.env`, certificats `.pem`, clés SSH et identifiants AWS stockés dans `.aws/` ou `.ssh/`.

La demande a rapidement migré vers Hacker News, où la discussion a atteint 219 points et déclenché 136 commentaires. Le débat qui s'y est déployé est plus nuancé que le simple constat d'un manque : plusieurs intervenants estiment que confier cette responsabilité à l'outil revient à placer la frontière de sécurité au mauvais endroit. L'argument le plus percutant : si l'agent exécute une commande comme `rg foo` et que la chaîne recherchée se trouve dans un fichier sensible, le contenu de ce fichier remonte dans la sortie de l'outil et est transmis aux serveurs d'OpenAI, quelle que soit la restriction déclarée dans un hypothétique `.agentignore`. La liste d'exclusion offrirait selon ces commentateurs une fausse impression de sécurité plutôt qu'une protection réelle.

Les alternatives proposées dans le fil sont plus radicales : permissions Unix classiques, isolation par conteneur avec Docker ou Firecracker, ou outils spécialisés comme bubblewrap et smolvm. Ces solutions existent et sont robustes, mais elles supposent un niveau de connaissance que tous les profils d'utilisateurs de Codex ne maîtrisent pas. Un commentateur a relevé que le fil lui-même illustre l'étendue du fossé de compétences entre les différents types d'utilisateurs qui se tournent aujourd'hui vers ces agents.

Ce que la discussion ne précise pas -- et c'est le point aveugle à garder en tête -- c'est la position officielle d'OpenAI sur le sujet : aucune réponse de l'équipe n'est visible dans le fil au moment de l'écriture. La question de savoir si codex-rs, la réimplémentation Rust de l'outil, embarquera ce type de contrôle reste ouverte. Pour les équipes qui utilisent Codex dans des dépôts contenant de vrais secrets, l'isolation au niveau du système d'exploitation reste, en attendant, la seule garantie qui ne repose pas sur une convention.