OpenAI avertit que l'accès complet de Codex peut entraîner une perte de données

Introduction

L'agent de codage Codex d'OpenAI peut lire des fichiers, modifier des dépôts de code, exécuter des commandes et interagir avec les outils de développement sur la machine de l'utilisateur. Ces fonctionnalités le rendent adapté aux travaux d'ingénierie à long terme, mais signifient également que sa sécurité dépend en grande partie des autorisations et des limites du bac à sable choisies par l'utilisateur.

Selon un rapport d'AIBase, OpenAI a enquêté sur quelques cas où Codex a supprimé des fichiers du répertoire personnel de l'utilisateur. D'après ce rapport, les sessions concernées s'exécutaient avec l'accès complet activé et sans protection par bac à sable.

L'explication technique spécifique rapportée par AIBase implique une interaction erronée entre la logique du répertoire temporaire et la variable d'environnement $HOME. OpenAI n'a pas encore publié d'analyse post-mortem publique confirmant ce processus exact.

Ce qu'OpenAI a confirmé publiquement est plus large et reste important : sa documentation officielle de Codex avertit que l'accès complet supprime les limites du répertoire de projet, ce qui peut entraîner des opérations destructrices inattendues et donc une perte de données.

Par conséquent, la recommandation directe est la suivante : à moins qu'un accès illimité ne soit réellement nécessaire et protégé par une autre couche d'isolement, Codex doit être limité à un espace de travail en bac à sable.

Que implique le problème de suppression de fichiers rapporté

Le rapport AIBase fourni décrit le problème comme se produisant sous une combinaison spécifique de paramètres :

1. Codex s'est vu accorder un accès complet à la machine locale.
2. Les limites du bac à sable ont été désactivées.
3. Les mécanismes de protection par approbation ou révision automatique n'étaient pas activés.
4. La tâche tentait de créer ou d'utiliser un répertoire de travail temporaire.
5. Une erreur impliquant la variable d'environnement $HOME aurait conduit le répertoire personnel de l'utilisateur à être considéré comme une cible de suppression.

Sous macOS et Linux, $HOME pointe généralement vers le répertoire personnel de l'utilisateur actuel. Ce répertoire peut contenir :

• Dossiers Bureau et Documents.
• Dépôts de code source.
• Configuration SSH et clés.
• Paramètres d'applications.
• Fichiers de configuration du Shell.
• Bases de données locales.
• Fichiers personnels.
• Dossiers de synchronisation cloud.

Par conséquent, une suppression récursive visant un mauvais chemin pourrait affecter bien plus que le projet actif en cours.

Ce que dit l'avertissement officiel d'OpenAI

La documentation actuelle du bac à sable Windows d'OpenAI indique qu'exécuter Codex avec un accès complet signifie que l'agent n'est plus limité au répertoire du projet. Il peut effectuer des opérations destructrices inattendues entraînant une perte de données.

La documentation sur les autorisations d'OpenAI définit trois profils d'autorisation intégrés :

Profil d'autorisation	Comportement du système de fichiers	Cas d'utilisation
:read-only	L'exécution des commandes locales reste en lecture seule	Inspection de dépôt, planification et révision
:workspace	Autorise l'écriture dans le répertoire racine de l'espace de travail actif et dans le répertoire temporaire système	Codage courant et maintenance de dépôt
:danger-full-access	Supprime les restrictions du bac à sable local	Uniquement lorsque un accès illimité est intentionnel et isolé séparément

La documentation officielle décrit également le mode suivant comme étant à haut risque :

codex --dangerously-bypass-approvals-and-sandbox

Un alias permet également d'obtenir le même comportement :

codex --yolo

Ces commandes désactivent à la fois le bac à sable et les invites d'approbation. Elles sont listées ici pour permettre aux utilisateurs d'identifier et d'éviter cette configuration dangereuse, et non pour recommander leur utilisation.

OpenAI qualifie ce mode de "sans bac à sable, sans approbation" et déclare qu'il n'est pas recommandé pour une utilisation normale.

Pourquoi l'accès complet change-t-il radicalement le niveau de risque

Les agents de codage ne se contentent pas de suggérer des commandes. En mode agent local, ils peuvent exécuter ces commandes directement.

Avec le bac à sable de l'espace de travail, le système d'exploitation et les politiques de Codex limitent la portée d'écriture des commandes. Une commande erronée pourrait encore endommager le projet en cours, mais ne devrait pas modifier arbitrairement des répertoires non liés.

Avec l'accès complet activé, la frontière technique disparaît. Le modèle et ses commandes Shell peuvent potentiellement accéder à :

• L'intégralité du répertoire personnel.
• D'autres dépôts de code.
• Des disques montés.
• Des dossiers de synchronisation cloud.
• Des fichiers d'identifiants.
• Des configurations de gestionnaire de paquets.
• Des données d'applications locales.
• Des outils externes accessibles par le compte utilisateur.

C'est pourquoi le simple libellé d'une invite ne suffit pas comme moyen de contrôle. Dire à l'agent "édite seulement ce dossier" est une instruction comportementale, tandis que le bac à sable est une frontière appliquée de force.

OpenAI considère le bac à sable et l'approbation comme des contrôles complémentaires :

• Le bac à sable détermine ce à quoi l'agent peut techniquement accéder.
• La politique d'approbation détermine quand l'agent doit s'arrêter et demander la permission.

La suppression de ces deux contrôles constitue la configuration au risque le plus élevé.

Les invites d'approbation et la révision automatique ne remplacent pas le bac à sable

Les invites d'approbation peuvent détecter les risques avant l'exécution d'opérations dangereuses, mais ne remplacent pas l'isolement du système de fichiers.

Un utilisateur pourrait approuver une commande erronée. Un réviseur automatique ne peut évaluer que les opérations transmises via le système d'approbation.

La documentation d'OpenAI indique que la révision automatique effectue une analyse des risques pour les demandes d'approbation éligibles, y compris les opérations destructrices, l'accès aux identifiants, le vol de données et l'affaiblissement persistant de la sécurité.

Une configuration typique de révision automatique est :

approval_policy = "on-request"
approvals_reviewer = "auto_review"

Cela permet de réduire la fatigue d'approbation tout en conservant une couche de révision.

Cependant, lorsque Codex est démarré en mode contournement de l'approbation et du bac à sable, le réviseur peut n'avoir aucune limite de périmètre à appliquer.

Un mode plus sûr est :

1. Maintenir le bac à sable de l'espace de travail activé.
2. Utiliser l'approbation à la demande ou la révision automatique.
3. Ajouter des exceptions étroitement ciblées uniquement si nécessaire.
4. Éviter d'ouvrir un accès illimité sur la machine hôte.

Mode par défaut recommandé par OpenAI

OpenAI recommande différents paramètres par défaut selon que le répertoire de travail est sous contrôle de version ou non :

• Dossier sous contrôle de version : Écriture dans l'espace de travail + approbation à la demande.
• Dossier non sous contrôle de version : Mode lecture seule.

Pour un dépôt courant, la commande CLI explicite est :

codex --sandbox workspace-write --ask-for-approval on-request

Pour inspecter sans éditer de fichiers :

codex --sandbox read-only --ask-for-approval

Approbation à la demande

Ces paramètres limitent Codex à des limites d'exécution définies tout en permettant à l'utilisateur d'approuver des opérations spéciales.

OpenAI documente également un compromis pour les tâches non supervisées. Il est possible de désactiver les invites d'approbation tout en maintenant le bac à sable actif :

codex --sandbox workspace-write --ask-for-approval never

Dans ce mode, Codex exécute la tâche de son mieux dans les limites de l'espace de travail, sans demander la permission d'opérations hors limites. C'est bien plus sûr que de désactiver à la fois l'approbation et le mécanisme de bac à sable.

Comment désactiver l'accès complet dans Codex

Les contrôles spécifiques varient légèrement dans l'application de bureau ChatGPT, le Codex CLI et les intégrations IDE, mais le principe est le même.

Étape 1 : Ouvrir le contrôle des autorisations

Dans l'interface de bureau ou IDE, ouvrez le sélecteur d'autorisations près du rédacteur d'invites.

Sélectionnez le mode de restriction de l'espace de travail ou le mode bac à sable par défaut, plutôt que l'accès complet.

Étape 2 : Utiliser l'accès à l'espace de travail pour le codage normal

Sélectionnez le mode qui permet à Codex d'écrire uniquement dans le projet actif ou la racine de l'espace de travail.

Dans le CLI, utilisez :

codex --sandbox workspace-write --ask-for-approval on-request

Étape 3 : Utiliser le mode lecture seule pour les révisions préliminaires

Lorsque vous ouvrez un dépôt inconnu, commencez par :

codex --sandbox read-only --ask-for-approval on-request

Laissez Codex examiner le code et proposer des plans avant d'accorder des droits d'écriture.

Étape 4 : Confirmer les limites actuelles

Dans Codex

Pendant l'opération, utilisez l'interface des états ou des autorisations pour confirmer quels répertoires sont considérés comme des racines d'espace de travail accessibles en écriture.

Ne présumez pas que le dossier affiché dans l'éditeur est le seul répertoire accessible par l'agent.

Étape 5 : Maintenez l'approbation activée pour les opérations hors limites

Pour les commandes nécessitant des droits d'accès supplémentaires, utilisez une approbation à la demande.

Pour réduire les frictions dans le flux de travail, envisagez une révision automatique plutôt que de supprimer complètement l'approbation.

Étape 6 : Redémarrez les sessions d'accès complet existantes

La modification des fichiers de configuration peut ne pas restreindre rétroactivement les processus en cours d'exécution.

Après avoir modifié les paramètres :

1. Arrêtez la session Codex en cours.
2. Confirmez la configuration.
3. Redémarrez Codex depuis le répertoire de projet prévu.
4. Vérifiez à nouveau les autorisations actuelles avant de poursuivre.

Paramètres plus sécurisés de config.toml

Codex prend en charge la configuration via le chemin suivant :

~/.codex/config.toml

Pour un système de configuration sandbox déjà établi, les paramètres par défaut plus sécurisés sont :

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

La configuration de révision plus stricte est :

approval_policy = "on-request"
sandbox_mode = "read-only"

Il est possible d'ajouter une révision automatique sans supprimer le sandbox :

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

OpenAI documente également le système de profils d'autorisations en tant que nouveau système de configuration en version bêta. Une configuration simple d'espace de travail est :

default_permissions = ":workspace"

La configuration par défaut en lecture seule est :

default_permissions = ":read-only"

Avertissement de configuration : OpenAI indique que le nouveau système de profils d'autorisations est incompatible avec l'ancien paramètre sandbox_mode. Veuillez configurer un seul de ces systèmes.

Autre chose : ne placez jamais les deux méthodes dans une même configuration active en espérant qu'elles se combinent automatiquement.

Exemple : Limiter l'écriture à l'espace de travail et interdire les fichiers .env

Pour les utilisateurs testant la version bêta du système de profils d'autorisations, OpenAI propose des politiques personnalisées permettant d'étendre les limites intégrées de l'espace de travail.

Le fichier de configuration du projet peut interdire l'accès aux fichiers d'environnement tout en maintenant l'espace de travail accessible en écriture :

default_permissions = "project-edit"

[permissions.project-edit]
extends = ":workspace"

[permissions.project-edit.filesystem.":workspace_roots"]
"**/*.env" = "deny"

[permissions.project-edit.network]
enabled = false

Cette politique :

• Maintient les fichiers de projet ordinaires accessibles en écriture.
• Préserve les mécanismes de protection intégrés de l'espace de travail.
• Interdit l'accès aux fichiers .env correspondants.
• Désactive l'accès réseau aux commandes.

Pour de nombreuses tâches de codage local, c'est un meilleur point de départ que d'accorder un accès étendu à l'ensemble de la machine.

Mesures de contrôle d'entreprise pour bloquer l'accès complet

Les organisations peuvent utiliser des exigences hébergées pour empêcher les utilisateurs de choisir un mode sandbox sans restriction.

OpenAI présente une liste d'autorisation similaire à ceci :

allowed_sandbox_modes = ["read-only", "workspace-write"]

Cela empêche l'accès complet d'être une option de sandbox disponible dans un environnement hébergé.

Le nouveau système de profils d'autorisations peut également être soumis à des restrictions centralisées. Les administrateurs peuvent définir des profils approuvés et omettre :danger-full-access de l'ensemble autorisé.

C'est utile car les politiques de sécurité ne doivent pas reposer entièrement sur le fait que chaque développeur se souvienne de choisir le bon mode.

Flux de travail plus sécurisés pour les opérations de codage quotidiennes

Un flux de travail pratique maintient la rapidité de Codex sans exposer l'ensemble du système hôte.

1. Travaillez dans un dépôt dédié

Lancez Codex depuis le répertoire du projet (et non depuis le répertoire personnel ou un dossier parent contenant des projets non pertinents).

Évitez les chemins larges, par exemple :

~

ou :

/

comme espace de travail actif.

2. Utilisez le contrôle de version avant de déléguer

OpenAI recommande d'utiliser des branches de fonctionnalités et de maintenir un git status propre avant de confier le travail à Codex.

Une procédure de préparation simple est :

git status
git switch -c codex/nom_de_la_tâche
git add -A
git commit -m "Point de contrôle avant la tâche Codex"

Adaptez le nom de la branche et le message de commit au projet.

3. Effectuez des commits fréquents

Les petits commits facilitent la vérification et le rollback des modifications individuelles.

N'attendez pas la fin d'une session autonome prolongée pour créer votre premier point de contrôle récupérable.

4. Examinez les commandes et les différences

Considérez la sortie de Codex comme une pull request :

• Vérifiez les commandes qu'elle propose.
• Examinez les différences de fichiers.
• Exécutez les tests.
• Confirmez les chemins de modification.
• Vérifiez les suppressions inattendues.
• Documentez les décisions importantes.

5. Utilisez des arbres de travail ou des conteneurs pour les tâches à risque

Pour les refontes importantes, les expérimentations de dépendances, les modifications du système de construction ou les tâches de nettoyage, isolez davantage l'agent.

Les options incluent :

• Arbres de travail Git.
• Machines virtuelles jetables.
• Conteneurs de développement.
• Conteneurs Docker.
• Comptes de développement temporaires avec des privilèges limités.

OpenAI fournit un exemple de conteneur de développement sécurisé, conçu pour les cas où les conteneurs sont destinés à...

Limites d'isolation externes.

6. Stockez les sauvegardes hors de portée de l'agent

Le contrôle de version protège les fichiers de dépôt suivis, mais ne protège pas tous les fichiers sur l'ordinateur.

Utilisez un système de sauvegarde que Codex ne peut pas modifier via le même compte utilisateur ou un système de fichiers monté. Les exemples incluent les sauvegardes hors ligne, les instantanés immuables ou les services de sauvegarde à distance prenant en charge l'historique des versions.

Mesures à prendre après une suppression accidentelle

Lorsqu'un fichier vient d'être supprimé, les opérations d'écriture ultérieures peuvent écraser les blocs de disque récupérables.

Veuillez prendre les précautions suivantes :

1. Arrêtez immédiatement la session Codex.
2. Arrêtez les outils de construction, les gestionnaires de paquets, les clients de synchronisation et tout autre processus écrivant des données sur le disque affecté.
3. Ne réinstallez pas de logiciel sur le disque affecté.
4. Vérifiez l'historique Git, les arbres de travail, l'historique local de l'éditeur, les instantanés et l'historique des versions dans le cloud.
5. Donnez la priorité à la restauration des données à partir d'une sauvegarde connue pour être intacte.
6. Pour les données irremplaçables, envisagez de faire appel à un service professionnel de récupération de données avant d'essayer des opérations de récupération DIY répétées.

Pour le code source suivi, commencez par une vérification non destructive :

git status
git diff
git log --oneline --all

N'exécutez pas de commandes de récupération Git destructrices avant d'avoir confirmé quels fichiers et commits sont encore disponibles.

Ce qu'OpenAI améliore

AIBase rapporte qu'OpenAI met à jour le contenu des avertissements d'accès complet et renforce les mesures de protection, tout en préparant des rapports d'analyse d'incidents plus détaillés.

La documentation publique actuelle d'OpenAI inclut déjà des avertissements explicites selon lesquels un accès complet peut entraîner une perte de données, tout en recommandant l'utilisation de limites de sandbox, de politiques d'exception strictes, de processus d'approbation, de profils d'autorisations, de points de contrôle de version et d'environnements de développement isolés.

Au moment de la rédaction de cet article, il n'existe pas encore de rapport d'analyse publique officiel concernant l'incident spécifique du mécanisme de suppression du répertoire $HOME.

Cela signifie que les utilisateurs doivent s'appuyer sur les mesures de contrôle actuellement disponibles, plutôt que d'attendre des explications futures :

• N'activez pas l'accès complet par défaut.
• Maintenez les limites du projet intactes.
• Conservez l'approbation pour les opérations escaladées.
• Utilisez le contrôle de version et les sauvegardes.
• Isolez les opérations d'automatisation à haut risque.

Distinctions importantes

Les erreurs de modèle ne sont pas le seul risque

Un comportement destructeur peut provenir de plusieurs niveaux :

• Le modèle a choisi une commande non sécurisée.
• L'expansion de variable a abouti à un chemin inattendu.
• Le shell a mal interprété les guillemets.

Le script de nettoyage pointe vers un mauvais répertoire.

• L'outil a été exécuté depuis un répertoire de travail inattendu.
• L'utilisateur a approuvé la commande sans vérification.
• Le bac à sable était désactivé.

Par conséquent, la sécurité ne peut pas reposer uniquement sur la précision du modèle.

La plupart des tâches de codage ne nécessitent pas un accès complet

L'édition courante, les tests, la recherche et l'exécution de commandes locales peuvent généralement être effectués dans les limites de l'espace de travail.

Lorsqu'une tâche nécessite un accès supplémentaire à un répertoire ou à une cible réseau, il est recommandé d'ajouter une exception précise plutôt que d'exposer l'ensemble du système.

La révision automatique réduit les frictions opérationnelles, mais ne change pas les conséquences

La révision automatique aide à catégoriser les demandes d'approbation, mais ne rend pas une exécution sans restriction inoffensive.

Le bac à sable reste le mécanisme de contrôle local le plus fort, car il limite les actions possibles d'une commande même lorsqu'elle contient des erreurs.

Questions fréquentes

Codex peut-il [début de question manquant] ?

Lorsque Codex dispose d'un accès en écriture, il peut modifier et supprimer des fichiers. En mode espace de travail, ces opérations sont limitées au répertoire racine en écriture configuré ; en mode accès complet, les restrictions du bac à sable local sont supprimées, augmentant ainsi l'impact potentiel des commandes erronées.

OpenAI a-t-il confirmé la vulnérabilité exacte de suppression dans $HOME ?

Le rapport AIBase attribue cette interprétation à l'enquête d'OpenAI. La documentation publique d'OpenAI confirme un risque plus large de perte de données en accès complet, mais au 17 juillet 2026, aucune analyse post-mortem technique publique n'a confirmé le mécanisme exact lié à $HOME.

Quel est le mode de permissions le plus sûr pour Codex ?

Lorsque Codex a uniquement besoin de consulter un dépôt, utilisez le mode :read-only. Pour le codage courant, le mode :workspace ou workspace-write avec approbation à la demande offre un équilibre pratique entre productivité et contrôle de sécurité.

L'utilisation de --yolo est-elle sûre ?

--yolo est un alias pour contourner l'approbation et le bac à sable. OpenAI le décrit comme un mode à haut risque sans bac à sable ni approbation ; il ne doit donc pas être utilisé sur un hôte normal contenant des fichiers importants.

Codex peut-il s'exécuter automatiquement sans invite d'approbation tout en maintenant un environnement en bac à sable ?

Oui. La documentation d'OpenAI indique que --ask-for-approval never est compatible avec le mode bac à sable. Par exemple, codex --sandbox workspace-write --ask-for-approval never évite les invites d'approbation interactives tout en maintenant les limites de l'espace de travail.

Git peut-il me protéger contre tous les types de perte de données avec Codex ?

Non. Git peut restaurer les fichiers de dépôt suivis et commités, mais ne protège pas automatiquement les fichiers non suivis, les identifiants, les documents personnels, les bases de données externes ou les dossiers non liés. Pour toute donnée non stockée en toute sécurité dans un système de versionnement, utilisez une solution de sauvegarde indépendante.

La révision automatique peut-elle remplacer le bac à sable ?

Non. La révision automatique évalue les demandes d'approbation éligibles, tandis que le bac à sable applique des limites sur le système de fichiers et le réseau. Dans la mesure du possible, ces deux contrôles doivent être conservés simultanément, sans considérer l'un comme un substitut à l'autre.

Dois-je utiliser le mode accès complet dans un conteneur ?

C'est raisonnable lorsque le conteneur ou la machine virtuelle est spécifiquement conçu comme une frontière de sécurité externe et ne contient pas de données montées sensibles. Examinez attentivement les points de montage, les identifiants, l'accès réseau et l'intégration avec l'hôte, car le mode accès complet peut toujours endommager ou divulguer tout ce qui est accessible dans cet environnement.

Outils associés

• Codex CLI : L'agent de codage en ligne de commande local d'OpenAI pour le travail sur dépôt et l'automatisation.
• Permissions Codex : Documentation officielle des modes lecture seule, espace de travail et accès complet.
• Bac à sable Codex : Explication de l'application des limites sur le système de fichiers et le réseau.
• Dépôt GitHub Codex : Dépôt officiel open source de Codex CLI.
• Visual Studio Code Dev Containers : Exécution de flux de travail de développement dans un environnement de conteneur isolé.
• Git : Fournit un historique de versions, des branches, des différences et des fonctions de restauration pour les fichiers source suivis.

Liens associés

Approbations et sécurité des agents : Guide officiel sur les modes de bac à sable, les stratégies d'approbation, la révision automatique et les paramètres dangereux.

• Permissions Codex : Référence officielle des profils de permissions minimales.
• Bac à sable Codex : Explication des limites de projet et du comportement du bac à sable sur toute la plateforme Codex.
• Bac à sable Windows pour Codex : Contient un avertissement explicite d'OpenAI : l'accès complet peut entraîner des opérations destructrices et une perte de données.
• Exécution sécurisée de Codex chez OpenAI : Décrit les mécanismes de contrôle utilisés en interne chez OpenAI pour l'exécution restreinte et la révision.
• Documentation Codex CLI : Instructions officielles d'installation et d'utilisation locale.
• Dépôt GitHub OpenAI Codex : Code source, signalement de problèmes, stratégie de sécurité et informations de version.

Résumé

L'incident signalé de suppression de fichiers par Codex s'est produit dans les conditions d'exécution les plus risquées : accès complet et absence de frontière de bac à sable. AIBase décrit un échec de nettoyage suspecté lié à $HOME, tandis que la documentation publique d'OpenAI confirme un fait plus large : l'accès sans restriction peut entraîner des opérations destructrices inattendues et une perte de données.

Pour la plupart des développeurs, le travail courant sur un dépôt de code ne nécessite pas un accès complet. L'écriture restreinte dans l'espace de travail, l'approbation à la demande, les points de contrôle de versionnement et l'environnement isolé offrent un mode d'exécution plus sûr sans affaiblir les capacités de codage de base de Codex.

Lors de l'exécution de tâches non supervisées, les utilisateurs peuvent désactiver les invites d'approbation tout en conservant le bac à sable de l'espace de travail. C'est beaucoup plus sûr que de contourner ces deux protections.

La règle pratique est simple : n'accordez à Codex que l'accès aux projets nécessaires, et non à la machine entière.