À propos de l’incident où gpt-5.6-sol a failli supprimer le répertoire personnel d’un utilisateur à cause d’un conflit avec la variable `$HOME` de PowerShell

Je souhaite partager un grave incident de sécurité que je viens de vivre en utilisant dans Codex le tout dernier modèle flagship, gpt-5.6-sol. Même si le modèle Sol a affiché des performances presque incroyables dans les workflows d’agents et les benchmarks d’exécution d’outils, l’absence d’une simple isolation de l’environnement shell a failli conduire à une catastrophe.

Déroulement de l’incident :
L’agent tentait de définir un répertoire de référence temporaire pour une tâche de débogage. Pour cela, il a généré et exécuté un bloc de script PowerShell initialisant une variable locale nommée $home.

$home = Join-Path $env:TEMP 'temporary-build-folder'  
if (Test-Path -LiteralPath $home) { Remove-Item -LiteralPath $home -Recurse -Force }  

Cause du bug :
Dans PowerShell, $HOME est une variable automatique intégrée qui pointe directement vers le répertoire de profil de l’utilisateur courant (par ex. C:\Users\<username>).

Le problème vient du fait que PowerShell n’est pas sensible à la casse. À cause de cela, la variable dynamique en minuscules $home déclarée par l’agent est entrée en conflit avec la portée globale de $HOME. Lorsque le script a atteint la ligne Remove-Item, ce chemin a été évalué non pas comme le dossier temporaire, mais comme mon véritable répertoire racine utilisateur.

En conséquence, gpt-5.6-sol a exécuté la commande suivante :
Remove-Item -LiteralPath 'C:\Users\<username>' -Recurse -Force

Étendue des dégâts :
Heureusement, grâce aux verrous système appliqués aux fichiers actuellement actifs, la commande s’est interrompue en cours d’exécution avec l’erreur WriteError: Directory is not empty, ce qui a permis d’éviter l’effacement complet et la catastrophe qu’il aurait entraînée. Mais l’agent a immédiatement détecté sa propre erreur, a interrompu son travail, puis a procédé à un auto-audit. Après vérification, certains fichiers de configuration et dotfiles (.ssh, .config, .npm) avaient déjà été modifiés ou avaient disparu.

Enseignements :
gpt-5.6-sol se montre remarquablement persévérant et compétent pour mener à bien des tâches de longue haleine. Mais lorsque nous accordons à ce type de modèles de raisonnement avancé un accès direct au terminal hôte, les mécanismes de portée des variables et l’insensibilité à la casse dans des shells comme PowerShell deviennent un vecteur de risque majeur.

Si vous prévoyez de construire ou de déployer des agents CLI avec la nouvelle famille GPT-5.6, un sandboxing strict et une conteneurisation robuste ne sont plus une option, mais une nécessité absolue.

Quelqu’un parmi vous a-t-il déjà rencontré un comportement similaire de shadowing de variables ou d’utilisation destructive d’outils avec Sol ou d’autres modèles récents ?

Voici le lien vers la capture d’écran de la situation à ce moment-là : https://gist.github.com/xamong/e98478b333bb9951b175284f744eb0ed

[ggggnews]

Heureusement que codex ne procède pas de lui-même à une élévation de privilèges.

[1yoouoo]

Il faut se débrouiller tout seul.