Le 16 juillet 2026, Thibault Sottiaux, ingénieur chez OpenAI, a confirmé publiquement sur X ce que plusieurs développeurs racontaient depuis quelques jours : GPT-5.6 Codex a supprimé des fichiers utilisateurs, dont des dossiers $HOME entiers, dans une poignée de cas documentés. Pas un bug obscur, pas un edge case théorique. Un agent qui efface le disque de son opérateur. Si tu envisages de déléguer du code à un agent autonome, ou si ton équipe le fait déjà avec Claude Code, Cursor Agent ou Codex, c'est le moment d'apprendre Claude proprement et de fixer des règles avant de se retrouver à restaurer un backup à 2 h du matin.
Cet article ne fait pas de FUD. Il raconte ce qui s'est passé, pourquoi c'est arrivé, et surtout quelles règles imposer à ton équipe avant d'autoriser un agent en mode accès complet sur un repo qui compte.
Ce qui s'est passé : Codex qui supprime des fichiers non commités
Voici les faits confirmés par OpenAI. GPT-5.6 Codex, dans un petit nombre de sessions, a tenté de rediriger la variable d'environnement $HOME vers un dossier de travail temporaire, puis a supprimé $HOME lui-même au lieu du dossier temporaire visé. Pas de malveillance : une erreur d'interprétation du modèle sur la variable qu'il manipulait.
Le comportement ne se déclenche que quand trois conditions sont réunies en même temps : le mode accès complet est activé, le sandboxing est désactivé, et la revue automatique est désactivée. Autrement dit, l'utilisateur a explicitement désactivé les trois filets de sécurité successifs. OpenAI a annoncé une mise à jour des messages destinés aux développeurs, des garde-fous supplémentaires dans le harnais d'exécution, et un post-mortem détaillé.
À côté de la confirmation officielle, des rapports tiers circulent sur les réseaux : un développeur qui parle de la quasi-totalité des fichiers de son Mac perdus, un autre qui évoque une base de données de production. Ces témoignages ne sont pas confirmés par OpenAI. Il faut les traiter comme ce qu'ils sont : des récits d'utilisateurs, pas des cas validés. Le fait officiel, lui, suffit à changer la conversation dans ton équipe dès demain matin.
Pourquoi le mode accès complet change la nature du risque
Un agent de code peut fonctionner selon deux logiques très différentes. Dans la première, l'agent propose une commande, tu la lis, tu valides, il exécute. C'est le mode par défaut de Claude Code : chaque commande shell déclenche un prompt de permission. Dans la seconde, l'agent exécute directement ce qu'il décide, sans point de validation. C'est ce qu'on appelle le mode accès complet chez Codex, --dangerously-skip-permissions chez Claude Code, ou le mode auto-run chez Cursor Agent.
La différence n'est pas cosmétique. Dans un LLM, une hallucination sur un nom de fichier, une mauvaise interprétation d'un prompt, une confusion entre deux variables d'environnement sont des événements normaux qui arrivent tous les jours. Tant qu'un humain valide, ces erreurs restent des propositions rejetées. Sans validation, une hallucination devient une action destructive et irréversible.
Le nom même de la commande chez Claude Code, --dangerously-skip-permissions, dit clairement ce que c'est : un raccourci que tu prends en connaissance de cause, pas un mode de travail par défaut. Sur ce point, l'écosystème converge : plus l'autonomie augmente, plus la responsabilité de préparer le terrain se déplace vers l'humain qui lance la session.
Les trois classes de dégâts qu'un agent peut infliger
Quand tu réfléchis à ce qui peut mal tourner, garde en tête trois catégories distinctes. Elles ne se protègent pas avec les mêmes garde-fous.
| Classe de dégât | Exemple concret | Ce qui protège |
|---|---|---|
| Perte de données locales | Suppression de fichiers non commités, .env local, artefacts de build, dossiers de travail temporaires que l'agent confond avec un dossier cible | Commit préalable, sandbox, allowlist de commandes destructives |
| Actions distantes | Push force sur main, suppression de branche remote, appel API facturé en boucle, envoi d'emails, mutation de base de données de production | Credentials en lecture seule, environnement de staging, permissions Git limitées |
| Fuite de secrets | L'agent lit un .env, colle son contenu dans un log de debug, un commit public, ou l'envoie via un appel externe | Aucun secret en clair dans le repo de travail, variables d'environnement injectées au runtime, revue avant push |
L'incident Codex tombe dans la première classe, la plus visible. La deuxième et la troisième sont plus insidieuses parce que les dégâts ne sont pas immédiatement lisibles. Un agent qui envoie un email erroné à ta liste clients, tu le vois. Un agent qui a commité une clé API dans l'historique public, tu le découvres quand quelqu'un s'en sert.
Le sandbox : à quoi ça sert vraiment, à quoi ça ne sert pas
Beaucoup de dirigeants entendent "sandbox" et rangent la question de la sécurité au rayon des problèmes résolus. C'est une erreur de cadrage.
Un sandbox, dans le contexte d'un agent de code, c'est un environnement isolé : container Docker, VM légère, workspace éphémère type e2b ou Daytona. Ce qu'il protège : le système hôte, les autres projets sur ta machine, les fichiers qui ne sont pas montés dans le sandbox. Ce qu'il ne protège pas : le contenu même du sandbox, les credentials que tu y injectes pour que l'agent puisse travailler, et les appels réseau sortants si tu n'as pas filtré la couche réseau.
Autrement dit, un agent qui tourne dans un container Docker peut parfaitement supprimer tous les fichiers montés dans /workspace, appeler ton API Stripe de production si la clé est dans l'environnement, ou pousser sur GitHub si le token y est. Le sandbox déplace le périmètre de risque, il ne l'annule pas. C'est pour ça que la question des accès externes se traite séparément, souvent via une couche comme MCP pour cadrer les accès externes plutôt que de tout laisser passer par des variables d'environnement.
Les garde-fous à imposer avant d'autoriser un agent en autonomie
Voici la liste que je donnerais à une équipe qui commence à faire tourner des agents de code sérieusement. Chaque point a une raison précise.
- Commit avant chaque session d'agent. C'est la règle qui rattrape 90 % des incidents. Un
git statuspropre au démarrage, tu récupères tout d'ungit reset --hard. - Aucun secret en clair dans le repo de travail. Les
.envrestent hors du dossier accessible à l'agent, injectés au runtime uniquement quand nécessaire. - Permissions Git en lecture seule quand possible. L'agent lit, propose un diff, l'humain pousse. Pas d'exception sur les branches protégées.
- Allowlist de commandes. Claude Code te laisse préautoriser des commandes précises. Utilise cette liste plutôt que
--dangerously-skip-permissions. - Timeout sur les sessions longues. Un agent qui tourne huit heures en autonomie sans supervision est un agent qui va finir par faire quelque chose de créatif.
- Revue humaine avant tout push et tout appel externe facturé. Non négociable.
Les trois premiers points relèvent de la discipline d'équipe. Les trois suivants sont des choix de configuration de l'outil. Les deux se cumulent, aucun des deux ne remplace l'autre. Si tu veux aller plus loin sur l'architecture des agents, le pilier construire des agents IA autonomes avec Claude reprend la logique complète, et l'article dédié à la sécurisation d'un agent Claude détaille chacun de ces points.
Comment Claude Code se positionne sur ces questions
Le modèle de permissions de Claude Code repose sur trois idées. Par défaut, chaque commande shell déclenche un prompt de permission que l'utilisateur doit valider explicitement. Les commandes considérées comme sûres et récurrentes peuvent être ajoutées à une allowlist par projet. Le mode plan permet à Claude d'expliquer ce qu'il compte faire avant de toucher au moindre fichier.
La version 2.1.212 publiée le 17 juillet 2026 a ajouté deux plafonds par session, réglables via variables d'environnement : 200 appels WebSearch par défaut, 200 sous-agents par défaut. L'idée est simple : couper les boucles de recherche ou d'orchestration incontrôlées avant qu'elles ne coûtent cher ou ne partent en dérive. Cette même version corrige un cas où, en mode plan, certaines commandes Bash modifiant des fichiers (touch, rm) pouvaient s'exécuter sans prompt de permission. C'est le genre de correctif qu'on veut voir sur son agent de code : documenté, ciblé, dans un changelog public.
# Configuration défensive pour une session Claude Code
export CLAUDE_CODE_MAX_WEB_SEARCHES_PER_SESSION=50
export CLAUDE_CODE_MAX_SUBAGENTS_PER_SESSION=20
# Toujours commit avant de lancer
git add -A && git commit -m "pre-agent snapshot"
# Puis lancer Claude Code en mode normal, pas en skip-permissions
claudeÇa ne rend pas Claude Code invulnérable, personne ne peut promettre ça. Ça signifie que les choix de conception vont dans la bonne direction : validation par défaut, plafonds réglables, changelog transparent sur les cas limites corrigés.
La règle pratique pour un dirigeant qui délègue
Si tu ne dois retenir qu'une chose de tout ça, c'est cette question à te poser avant de lancer un agent en mode autonome sur un dossier : si l'agent supprime tout ici maintenant, je perds quoi ?
Si la réponse est "rien, tout est commité et pushé", tu peux y aller. Si la réponse contient un fichier non commité, une base de données qui n'a pas de backup récent, un .env avec des clés de production, ou n'importe quoi que tu ne peux pas régénérer en trois commandes, arrête. Commit, backup, isole, puis relance. C'est aussi bête que ça.
Un agent de code en accès complet doit tourner sur du code jetable ou versionné, jamais sur des fichiers non commités qui ont de la valeur. Le mode autonomie est un outil de productivité massif quand le terrain est préparé, et un générateur d'incidents quand il ne l'est pas. La différence entre les deux ne se joue pas dans le modèle. Elle se joue dans les cinq minutes qui précèdent le lancement de la session.
Si tu veux passer de la théorie à une pratique cadrée, avec des sessions accompagnées et des livrables qui incluent la configuration défensive de tes propres agents, va voir la formation Ottho pour piloter tes agents autonomes sur des cas concrets, pas sur des slides.