Le chercheur Oren Yomtov d'Accomplish AI a divulgué le 15 septembre 2026 deux sorties de sandbox Codex. BleepingComputer a rapporté les conclusions le 20 septembre et indiqué qu'OpenAI avait corrigé les problèmes en août. Le problème le plus grave, appelé Heapjack par le chercheur, a été décrit comme une exécution de commandes hors sandbox depuis le mode read-only. Le second, appelé Overpatch, élargissait l'autorité d'écriture de fichiers par le chemin de patch en mode workspace-write.
L'action immédiate pour l'utilisateur est simple: mettre à jour Codex CLI et Codex Desktop vers les versions corrigées ou plus récentes. La conséquence de gouvernance est plus large. Un agent de code qui examine des dépôts non fiables ne lit pas seulement du code. Il traverse des instructions, des helpers, des outils, des opérations de fichiers et des points d'intégration locaux. Si la frontière autour de ces composants est faible, une revue ordinaire peut devenir un chemin d'action au niveau de l'hôte.
Ce qui a été divulgué
Accomplish a déclaré avoir signalé les deux failles à OpenAI le 12 août 2026 et indiqué qu'elles avaient été corrigées en huit jours. Son article identifie Codex CLI 0.149.0 comme version minimale corrigée pour Overpatch et Codex Desktop build 26.818.21641 comme version minimale corrigée pour Heapjack. BleepingComputer a résumé indépendamment les mêmes chemins affectés et rapporté une déclaration d'OpenAI remerciant les chercheurs et indiquant que les problèmes avaient été traités.
Le dossier public examiné ici n'établit pas d'exploitation active. Il ne signifie pas non plus que toute installation Codex était vulnérable au moment de la publication. Il s'agit d'une histoire de divulgation et de réponse, pas de la preuve d'une compromission client confirmée.
Pourquoi Heapjack compte
Heapjack est la leçon de contrôle la plus importante parce qu'il cible une frontière de confiance dans un helper. Accomplish indique que l'outil JavaScript de Codex Desktop utilisait des contextes fiables et non fiables dans un seul processus Node.js. Le côté fiable utilisait un jeton pour prouver son autorité auprès d'un processus parent natif. Le problème, selon l'article, est que les deux contextes partageaient le même tas V8, si bien que le code non fiable pouvait rechercher le jeton dans les données mémoire et envoyer des requêtes au parent.
Ce schéma est fréquent dans les systèmes d'agents. Une équipe peut dire que le modèle est sandboxé, alors que des outils helpers, des ponts runtime, des extensions de navigateur ou des serveurs MCP portent une autorité hors de la sandbox. La revue de sécurité devrait demander où réside l'autorité réelle, quels chemins mémoire et IPC traversent la frontière et si l'agent peut influencer le processus qui applique ses limites.
Pourquoi Overpatch compte
Overpatch a une autre forme. Il concerne le chemin de patch qui décide où l'agent peut écrire. Accomplish décrit une technique où la mention d'un chemin tel qu'un répertoire parent élargissait l'accès en écriture, puis un chemin par lien symbolique permettait d'écrire hors de l'espace de travail prévu. Le plancher de version corrigée compte, mais la leçon de conception compte davantage: les outils qui modifient des fichiers sont des moteurs de politique, même lorsqu'ils ressemblent à une commodité de développement.
Pour les agents de code, la politique d'écriture doit être explicite et inspectable. Le guide Maetra des approbations traite des actions conséquentes, mais le même principe s'applique au développement local: une écriture hors de l'espace de tâche est une autre catégorie d'action et devrait porter une barrière plus forte.
Ce que les équipes devraient inventorier
La première tâche défensive n'est pas un slogan sur l'IA sûre. C'est l'inventaire. Les équipes devraient savoir quels agents de code sont installés, quels helpers de bureau sont activés, quelles versions CLI sont utilisées, quelle configuration globale a été écrite et quels dépôts sont traités comme non fiables. Le guide Maetra de découverte des agents donne un modèle pratique pour relier agents, propriétaires, outils et historique des changements.
La deuxième tâche est la preuve. Un correctif n'est pas complet parce qu'un gestionnaire de paquets indique un changement de version. Les équipes ont besoin d'enregistrements sur les versions installées, l'état de redémarrage, les changements de configuration et toute activité antérieure suspecte. Le guide Maetra des journaux d'audit IA explique pourquoi un réviseur ultérieur a besoin de la requête, de la politique, de l'appel d'outil et de l'effet observé, pas seulement du statut final du ticket.
Analyse Maetra
La divulgation Codex rappelle que les garde-fous d'agent ne peuvent pas tous vivre dans l'agent. Les règles de prompt, le comportement du modèle et les étiquettes d'espace de travail aident, mais les contrôles les plus solides résident hors du composant contenu. Pour les agents de code, cela signifie une politique d'outil versionnée, des helpers isolés, une confiance explicite dans les dépôts, des droits d'écriture étroits, des sockets surveillés et une trace de preuve qui subsiste après la fin de session.
Les équipes devraient éviter de surinterpréter la divulgation. Les problèmes signalés ont été corrigés rapidement, et aucune source publique examinée ici ne prouve une exploitation active. Le problème de contrôle sous-jacent reste durable: les machines de développement exécutent désormais des agents qui inspectent du code hostile et se connectent à des outils locaux puissants. Traitez ces agents comme une automatisation privilégiée, pas comme des fenêtres de chat à thème code.