Один символ у коді ШІ стер увесь диск розробника
- Розробник втратив усі дані на диску через помилку в скрипті від ChatGPT Codex для очищення кешу.
- Причиною катастрофи стало некоректне екранування символів у шляху до папки при виклику cmd через PowerShell.
- Замість видалення конкретних папок, скрипт інтерпретував шлях як корінь диска і почав рекурсивне стирання.
- Інцидент підсвітив небезпеку вайбкодингу, коли ШІ-код запускається без ретельної перевірки синтаксису.
- Експерти радять завжди тестувати автоматизацію в пісочницях та уникати прапорців примусового видалення під час тестів.
Життя розробника — це постійний баланс між автоматизацією та обережністю, проте іноді навіть рутинна задача може перетворитися на цифрову катастрофу через один зайвий символ.
Нещодавній інцидент, що став віральним на Reddit, описує сумний досвід програміста, який скористався допомогою ChatGPT Codex версії 5.3 для створення простого PowerShell-скрипта. Завдання було елементарним: видалити теку кешу Python (pycache) для очищення місця. Проте замість кількох системних тек скрипт без жодних попереджень «злизав» увесь вміст диска F, включаючи робочі проєкти та дані Docker.
GPT 5.3 Codex wiped my entire F: drive with a single character escaping bug
by u/Former-Airport-1099 in vibecoding
Технічна причина виявилася напрочуд підступною і крилася в особливостях екранування символів. ШІ використав зворотний слеш (\) для екранування лапок у рядку шляху. Це цілком робочий метод для багатьох командних оболонок, але все пішло не за планом, коли PowerShell викликав cmd.exe через команду cmd /c.
У цьому специфічному контексті екранування спрацювало некоректно, і замість цільової теки шлях скоротився до одного символу \, який Windows інтерпретує як корінь поточного диска. Оскільки команда містила прапорці для примусового та рекурсивного видалення без підтвердження, система миттєво почала стирати все підряд.
Ця ситуація стала яскравим прикладом явища, яке зараз називають «вайбкодингом» (vibecoding) — коли розробники покладаються на загальне відчуття правильності коду від ШІ, не перевіряючи кожну кому.
Головна проблема полягає в тому, що PowerShell та cmd.exe обробляють спеціальні символи по-різному: наприклад, у рідному середовищі PowerShell для екранування використовується зворотний апостроф ( `), а не слеш. Змішування цих середовищ створює небезпечні сценарії, які важко помітити неозброєним оком.
Хоча частину даних вдалося відновити з бекапів, цей випадок нагадує про золоте правило: будь-які скрипти, що взаємодіють із файловою системою, потрібно спочатку тестувати в ізольованому середовищі (пісочниці) та обов’язково прибирати прапорці автоматичного видалення під час першого запуску.
