OpenAI renforce la sécurité de Codex avec un nettoyage plus sûr et un contrôle des permissions pour prévenir les actions destructrices

OpenAI renforce la sécurité de Codex avec de nouveaux mécanismes de nettoyage et de contrôle des permissions pour prévenir les opérations destructrices

Après avoir enquêté sur plusieurs rapports d'opérations destructrices dépassant l'intention de l'utilisateur, OpenAI a renforcé les mécanismes de contrôle de sécurité de Codex.

Le problème ne réside pas dans le fait que l'agent de programmation IA puisse exécuter des commandes — c'est précisément la valeur fondamentale de Codex. Le risque apparaît lorsque l'agent, disposant de permissions étendues, exécute des opérations de nettoyage ou de gestion de fichiers en interprétant incorrectement le chemin cible.

Selon Thibault « Tibo » Sottiaux, responsable de l'ingénierie de Codex chez OpenAI, l'entreprise a enquêté sur quelques cas où GPT-5.6 a exécuté dans Codex des opérations destructrices dépassant le cadre demandé. L'un des schémas récurrents impliquait le nettoyage de répertoires temporaires, en particulier lors de sessions exécutées avec des permissions d'accès étendues et une protection sandbox réduite.

Les dernières mesures d'atténuation d'OpenAI agissent simultanément sur plusieurs niveaux :

• Vérifier les cibles de suppression avant les opérations destructrices ;
• Utiliser des répertoires temporaires dédiés plutôt que de réutiliser des variables d'environnement sensibles ;
• Renforcer la détection et la supervision des commandes à haut risque ;
• Rendre le mode « accès complet » plus difficile à activer accidentellement ;
• Améliorer les fonctions de supervision automatique pour identifier plus fiablement les opérations destructrices ;
• Ajouter de nouvelles tâches d'évaluation et d'entraînement basées sur les cas d'échec observés par l'équipe.

Le changement clé n'est pas une simple liste d'interdictions. OpenAI resserre simultanément les instructions du modèle et l'environnement d'exécution qui l'entoure.

L'enquête se concentre sur le nettoyage des répertoires temporaires

L'enquête d'OpenAI a révélé qu'une partie des défaillances destructrices était liée à la logique de nettoyage des répertoires de travail temporaires.

Les agents de programmation créent fréquemment des emplacements temporaires au cours de leur travail. Les tâches peuvent impliquer la décompression d'archives, la génération de fichiers intermédiaires, l'exécution de tests, la mise en attente de correctifs ou la création d'artefacts de construction à usage unique. Nettoyer ces fichiers par la suite est généralement sûr.

Le danger apparaît lorsque les variables identifiant les répertoires temporaires sont ambiguës, réutilisées, mal formatées ou pointent accidentellement vers des emplacements importants.

Sottiaux a décrit un schéma de défaillance : le modèle réutilise des variables d'environnement système (comme $HOME) comme répertoire de travail temporaire. Si une commande de nettoyage ultérieure interprète incorrectement cette variable, la commande censée supprimer le répertoire temporaire peut cibler le véritable répertoire personnel de l'utilisateur.

Cette chaîne de défaillance peut se comprendre à un niveau élevé :

Création ou identification d'un espace de travail temporaire
↓
Réutilisation d'une variable système trop large
↓
Construction de la commande de nettoyage
↓
Résolution d'un chemin cible erroné
↓
Exécution d'une opération destructrice avec des permissions étendues
↓
Suppression de fichiers au-delà de la portée prévue

Dans les sessions sans restriction, ce risque est particulièrement grave.

Dans un environnement sandbox strictement limité, le système d'exploitation peut empêcher les commandes erronées d'atteindre des répertoires sans rapport. En mode accès complet, cette frontière est délibérément supprimée, de sorte qu'une erreur de résolution de chemin peut avoir une portée d'impact beaucoup plus large.

La documentation actuelle de Codex indique clairement cette distinction : le mode standard workspace-write limite les modifications courantes à l'espace de travail actuel,

tandis que danger-full-access supprime les frontières sandbox du système de fichiers et du réseau.

Codex vérifie désormais plus explicitement les cibles destructrices

La première mesure d'atténuation majeure est une validation plus stricte de la cible avant les opérations de suppression ou autres opérations destructrices.

Codex ne considère plus le nettoyage comme une simple étape finale de routine ; il est explicitement invité à confirmer que le chemin cible est bien celui qu'il a l'intention de modifier.

C'est important car les commandes shell destructrices ne sont généralement sûres que lorsque leurs paramètres sont corrects.

Par exemple, la différence entre supprimer un répertoire temporaire dédié et supprimer l'espace de travail parent peut tenir à une mauvaise expansion de variable, une erreur de citation, un problème de normalisation de chemin ou un paramètre manquant.

La nouvelle approche réduit la dépendance aux hypothèses implicites.

Avant d'exécuter une opération critique sur le système de fichiers, le système doit réfléchir plus soigneusement aux questions suivantes :

• Quel répertoire cette commande affecte-t-elle exactement ?
• Ce répertoire est-il un emplacement temporaire créé pour cette tâche ?
• Le chemin est-il résolu dans l'espace de travail prévu ?
• La cible est-elle accidentellement trop large ?
• La suppression est-elle irréversible ?
• La portée est-elle suffisamment claire pour continuer sans demander à l'utilisateur ?

C'est une amélioration de sécurité au niveau du comportement de l'agent.

Elle ne remplace pas le sandbox, mais elle réduit d'abord la probabilité qu'une commande dangereuse atteigne la frontière du sandbox.

Des répertoires temporaires dédiés remplacent la réutilisation risquée de variables

OpenAI modifie également la manière dont Codex gère le travail temporaire.

Le modèle plus sûr consiste à créer un répertoire temporaire entièrement nouveau et spécifique, plutôt que de réutiliser des variables système qui ont déjà une signification importante.

Les variables comme $HOME sont particulièrement sensibles car elles pointent généralement vers de véritables répertoires utilisateur contenant des fichiers de projet, des configurations, des identifiants, des données d'application et d'autres données personnelles.

L'utilisation d'un chemin temporaire dédié présente deux avantages.

Premièrement, la cible a une signification sémantique plus étroite : elle ne sert qu'aux données de tâches à usage unique.

Deuxièmement, le nettoyage devient plus facile à vérifier, car le système peut comparer la cible de suppression avec le répertoire temporaire exact créé au début de la tâche.

C'est un principe d'ingénierie direct, mais il devient encore plus important lorsque des agents autonomes peuvent exécuter des commandes shell à la vitesse de la machine.

Le modèle plus sûr est en réalité le suivant :

Créer un répertoire temporaire entièrement nouveau
↓
Stocker les fichiers temporaires spécifiques à la tâche à cet endroit
↓
Suivre le chemin exact
↓
Vérifier ce même chemin avant le nettoyage
↓
Supprimer uniquement le répertoire temporaire vérifié

L'objectif est d'éviter que de larges états d'environnement ne deviennent des cibles de nettoyage.

La détection et la supervision des commandes dangereuses sont renforcées

La validation des chemins n'est qu'une couche de défense.

OpenAI a également renforcé les mécanismes d'identification des commandes à risque et de leur transmission pour supervision.

Le journal des modifications de Codex documente déjà une détection plus stricte des opérations rm forcées, ainsi qu'une confirmation plus cohérente de l'accès complet. La stratégie actuelle de supervision automatique classe explicitement les opérations destructrices présentant un risque significatif de dommages irréversibles dans les catégories qu'elle vise à bloquer.

C'est important car une commande peut être syntaxiquement parfaitement valide mais néanmoins dangereuse.

Une commande de suppression peut être entièrement conforme aux règles syntaxiques du shell, mais rester dangereuse car elle peut :

• Cibler un répertoire à portée trop large ;
• Affecter des données en dehors de l'espace de travail ;
• Utiliser des variables non résolues ;
• Supprimer récursivement de grandes arborescences de répertoires ;
• Détruire un travail non sauvegardé ;
• Affaiblir les contrôles de sécurité ;
• Combiner plusieurs opérations dangereuses dans un seul appel shell.

Par conséquent, les mécanismes de sécurité mis à jour d'OpenAI ne déterminent pas seulement si une commande peut être exécutée.

Ils déterminent également si elle doit être exécutée, dans le cadre des permissions actuelles et de l'autorisation de l'utilisateur.

L'accès complet est plus difficile à activer accidentellement

Le texte original met également en avant les changements dans l'expérience d'accès complet de Codex.

L'accès complet est conçu délibérément pour être extrêmement puissant. La documentation actuelle des permissions d'OpenAI indique que dans ce mode, Codex peut modifier n'importe quel fichier sur l'ordinateur et exécuter des commandes avec accès réseau sans demander d'approbation.

C'est utile dans les machines virtuelles temporaires, les environnements de développement dédiés ou d'autres systèmes strictement contrôlés où l'opérateur souhaite délibérément une automatisation sans restriction.

Cependant, sur une station de travail ordinaire, ce mode augmente considérablement les conséquences d'une erreur.

OpenAI a désormais relevé le seuil pour activer ce mode.

La documentation actuelle de Codex stipule que l'accès complet doit d'abord être explicitement activé dans les paramètres de l'application de bureau avant d'apparaître comme mode de permission optionnel. L'interface affiche également des avertissements plus forts concernant les pertes de données, les fuites et les comportements inattendus possibles.

Pour les modèles de sécurité à haut risque approuvés, OpenAI indique que l'application de bureau affiche un avertissement supplémentaire spécifique au modèle avant l'activation de l'accès complet, et recommande d'utiliser le mode plus sûr « approuver à ma place ».

Explication des principaux modes de permission

Le point clé : la supervision automatique et l'accès complet ne sont pas la même chose.

La supervision automatique conserve le mécanisme sandbox. Elle change qui évalue les demandes franchissant les limites du sandbox.

L'accès complet, quant à lui, supprime directement la frontière du sandbox elle-même.

La supervision automatique identifie désormais plus strictement les opérations destructrices

OpenAI a également mis à jour ses règles d'examen automatique afin de mieux détecter les opérations destructrices.

L'examen automatique est un agent de revue indépendant qui évalue les demandes éligibles lorsque l'agent Codex principal souhaite franchir la frontière du bac à sable.

Le flux normal est le suivant :

L'agent Codex principal travaille dans le bac à sable
↓
Une opération nécessite des autorisations supplémentaires
↓
Codex crée une demande d'approbation
↓
L'examen automatique évalue la demande
↓
Approbation → poursuite de l'exécution
Refus → Codex doit trouver une voie plus sûre ou demander à l'utilisateur

La documentation d'OpenAI indique que l'examen automatique peut évaluer des demandes portant sur :

• l'élévation des privilèges shell ou d'exécution ;
• l'accès réseau bloqué ;
• les modifications en dehors du répertoire racine inscriptible ;
• les appels d'outils MCP ou applicatifs externes ayant des effets secondaires ;
• l'accès informatique à de nouveaux sites Web ou domaines.

Sa politique vise à refuser ou à limiter les actions destructrices, notamment la détection d'identifiants, l'exfiltration de données, l'affaiblissement persistant des contrôles de sécurité et les comportements présentant un risque important de dommages irréversibles.

Cela fait de l'examen automatique une couche de sécurité importante pour l'utilisateur, réduisant les interventions manuelles sans pour autant donner à l'agent de codage principal un accès illimité.

Cependant, OpenAI précise clairement que l'examen automatique ne remplace pas le mécanisme du bac à sable.

Si l'utilisateur choisit l'accès complet et supprime le bac à sable, l'examinateur automatique ne peut pas recréer une frontière qui n'existe plus.

OpenAI rejoue les défaillances dans de nouvelles évaluations

Les mesures d'atténuation sont également répercutées dans les tests des modèles.

Sottiaux a indiqué qu'OpenAI a construit des évaluations ciblées qui rejouent les différents types de défaillances découverts au cours de l'enquête. L'entreprise ajoute également des tâches d'apprentissage par renforcement et des scoreurs ciblant ces risques.

C'est important, car si les erreurs destructrices rares ne sont évaluées que comme des cas isolés, il est difficile de les améliorer.

Transformer les défaillances réelles en tests reproductibles permet à l'équipe de se poser les questions suivantes :

• Le modèle peut-il identifier une cible de suppression accidentellement trop large ?
• Évite-t-il de réutiliser des variables d'environnement sensibles ?
• S'arrête-t-il lorsque le périmètre n'est pas clair ?
• Privilégie-t-il les opérations réversibles lorsque c'est possible ?
• L'examen automatique escalade-t-il ou refuse-t-il correctement l'opération ?
• Les futurs modèles reproduiront-ils la même défaillance ?

En d'autres termes, cet incident est converti en couverture de tests de régression.

L'objectif de sécurité n'est pas seulement de corriger un modèle de commande, mais de rendre moins probable la reproduction d'une catégorie plus large de défaillances dans les futures versions de Codex.

Le bac à sable et les autorisations comptent plus que les simples invites

L'enquête a également renforcé un point de vue plus large sur la sécurité des agents de codage.

Des instructions en langage naturel comme « manipulez les fichiers avec précaution » ne constituent pas une frontière de sécurité solide.

C'est le bac à sable d'exécution qui l'est.

Les propres guides de déploiement d'OpenAI décrivent le bac à sable et les approbations comme des contrôles complémentaires :

• Le bac à sable détermine où Codex peut écrire et à quelles ressources réseau il peut accéder ;
• La politique d'approbation détermine quand Codex doit s'arrêter avant de franchir cette frontière.

Pour la plupart des travaux locaux, OpenAI recommande actuellement une configuration au niveau de l'espace de travail plutôt qu'une exécution sans restriction.

Une configuration plus sûre représentative est la suivante :

sandbox_mode = "workspace-write"
approval_policy = "on-request"
approvals_reviewer = "user"

Les utilisateurs souhaitant recourir à l'examen automatique peuvent conserver le même bac à sable tout en changeant d'examinateur :

sandbox_mode = "workspace-write"
approval_policy = "on-request"
approvals_reviewer = "auto_review"

Ces configurations conservent une frontière au niveau du système d'exploitation autour de l'espace de travail normal.

En revanche, l'accès complet supprime délibérément cette protection et ne doit être utilisé que lorsque l'environnement fournit lui-même l'isolation nécessaire.

Ce que cette mise à jour de sécurité de Codex signifie pour les développeurs

Pour les développeurs, cette mise à jour ne signifie pas que Codex ne commettra plus jamais d'erreurs destructrices.

La propre documentation d'OpenAI avertit que l'examen automatique peut se tromper et qu'aucun mécanisme de sécurité au niveau de l'agent ne doit être considéré comme un substitut à des pratiques de développement récupérables.

Le changement réel est une défense en profondeur.

Les opérations à haut risque ont désormais plus de chances d'être bloquées :

1. Le modèle est invité à vérifier la cible.
2. Les travaux temporaires sont censés utiliser des chemins dédiés plus sûrs.
3. Les schémas de commandes à haut risque peuvent être identifiés par le cadre d'exécution.
4. La frontière du bac à sable peut empêcher l'accès en dehors de l'espace de travail.
5. L'approbation ou l'examen automatique peut évaluer les demandes franchissant la frontière.
6. L'accès complet nécessite une action utilisateur plus claire et plus délibérée.
7. Les cas de défaillance sont ajoutés aux évaluations et à la formation future.

C'est plus robuste que de dépendre d'une seule mesure de sécurité.

Pour le codage quotidien, le paramètre par défaut le plus sûr reste simple : laissez l'agent dans l'espace de travail, sauf si la tâche nécessite réellement un accès plus large.

Questions fréquentes

Pourquoi Codex supprime-t-il parfois des fichiers en dehors du répertoire cible ?

L'enquête d'OpenAI a identifié un mode de défaillance lié au nettoyage des répertoires temporaires. Dans certains cas, des variables système larges comme $HOME peuvent être réutilisées lors de travaux temporaires, et un chemin de nettoyage mal formaté peut pointer vers de véritables données utilisateur plutôt que vers un répertoire jetable.

Qu'est-ce qui a changé dans Codex après l'enquête ?

OpenAI indique que Codex vérifie désormais plus explicitement les cibles de suppression, utilise des modèles de répertoires temporaires plus sûrs, renforce la détection des opérations destructrices, améliore l'examen automatique et rend l'accès complet plus difficile à activer accidentellement. L'entreprise a également créé des évaluations ciblées à partir des défaillances observées.

Qu'est-ce que l'accès complet de Codex ?

L'accès complet supprime les restrictions habituelles du bac à sable, permettant à Codex de modifier largement des fichiers et d'exécuter des commandes avec accès réseau, sans les frontières d'approbation habituelles. OpenAI avertit que cela augmente considérablement les risques de perte de données, d'exfiltration et de comportements inattendus.

L'examen automatique est-il identique à l'accès complet ?

Non. L'examen automatique conserve le bac à sable existant et envoie les demandes d'escalade éligibles à un agent de revue. L'accès complet supprime la frontière du bac à sable, de sorte que les deux modes offrent des niveaux de protection très différents.

L'examen automatique bloque-t-il les commandes destructrices ?

La politique actuelle d'OpenAI indique que l'examen automatique est conçu pour identifier et bloquer les opérations destructrices présentant un risque de dommages irréversibles importants, ainsi que des risques comme la détection d'identifiants et le vol de données. Il n'examine que les opérations qui nécessitent déjà une approbation dans le cadre de la politique de bac à sable et d'approbation actuelle.

Quel mode d'autorisation la plupart des utilisateurs de Codex devraient-ils choisir ?

OpenAI recommande à la plupart des utilisateurs de commencer par un mode basé sur une approbation classique pour les travaux locaux. Cela permet des modifications courantes dans l'espace de travail tout en exigeant un examen avant que Codex ne franchisse cette frontière ou n'accède à des ressources restreintes.

Codex peut-il encore faire des erreurs après ces modifications ?

Oui. Ces mesures réduisent les risques mais ne garantissent pas une absence totale d'erreurs. Le contrôle de version, les sauvegardes, des autorisations d'espace de travail restreintes et une approbation délibérée des opérations à haut risque restent essentiels.

Où puis-je vérifier les autorisations et les paramètres du bac à sable de Codex ?

Dans l'application de bureau ChatGPT ou l'extension IDE, utilisez les contrôles d'autorisation associés à la tâche. Dans Codex CLI, /permissions affiche les modes disponibles, tandis que la documentation officielle de configuration décrit sandbox_mode, approval_policy et approvals_reviewer.

Outils connexes

• OpenAI Codex : documentation officielle de Codex pour les flux de travail locaux, IDE, de bureau et cloud.
• Codex CLI : l'agent de codage en ligne de commande open source d'OpenAI et son historique de versions.
• Autorisations Codex : explications officielles sur « demande d'approbation », « examen automatique », « accès complet » et les modes d'autorisation associés.
• Examen automatique Codex : documentation sur l'examen automatique des demandes d'approbation à la frontière du bac à sable.
• Bac à sable Codex : documentation sur le bac à sable.

Référence officielle pour read-only, workspace-write et danger-full-access.

• Règles Codex : contrôle des politiques de commandes permettant, invitant ou bloquant des schémas de commandes sélectionnés.

Liens connexes

• Mise à jour de sécurité Codex par Thibault Sottiaux : mise à jour d'ingénierie OpenAI Codex décrivant l'enquête et les nouvelles mesures d'atténuation publiées.
• Exécuter Codex en toute sécurité chez OpenAI : aperçu d'OpenAI sur la sandboxisation, l'approbation, le contrôle réseau, la configuration hébergée et l'auditabilité.
• Approbations et sécurité de l'agent : guide détaillé sur les limites de sandbox, les politiques d'approbation, les chemins protégés et l'examen des approbations automatiques.
• Examen automatique Codex : documentation officielle couvrant les conditions de déclenchement, le processus d'examen, les politiques pour les opérations destructrices et les comportements en cas d'échec.
• Permissions Codex : description officielle des modes de permission destinés aux utilisateurs et des avertissements concernant l'accès complet.
• Journal des modifications Codex : historique des versions documentant la détection rm renforcée, les confirmations d'accès complet et les améliorations de sécurité associées.
• Dépôt GitHub OpenAI Codex : code source, problèmes, notes de version et implémentation CLI Codex open source.

Résumé

Après avoir enquêté sur de rares cas où quelques opérations de nettoyage destructrices ont affecté des fichiers au-delà de la portée prévue par l'utilisateur, OpenAI a renforcé Codex. Les principaux modes de défaillance impliquaient la gestion des répertoires temporaires, des variables d'environnement trop larges, une validation insuffisante des cibles, ainsi que des sessions avec des permissions trop étendues où des commandes erronées pouvaient causer des dommages importants.

Les nouvelles mesures de sécurité ajoutent des vérifications des chemins cibles, une gestion plus sûre des répertoires temporaires, un examen renforcé des commandes destructrices, des avertissements plus clairs pour l'accès complet et des politiques d'examen automatique améliorées. OpenAI convertit également les échecs observés

en tâches d'évaluation et d'entraînement reproductibles.

Ces modifications réduisent la probabilité qu'un agent de codage transforme une erreur de nettoyage banale en un incident majeur sur le système de fichiers, mais elles ne rendent pas l'exécution non restreinte sans risque.

Pour la plupart des développements locaux, l'approche la plus sûre reste de garder Codex dans le sandbox de l'espace de travail et de n'élever les permissions que lorsque la tâche l'exige réellement.