Codex удаляет файлы: причина и как защититься

Пользователи Codex сообщали об удалении локальных файлов, и OpenAI это подтвердила. Механика оказалась предельно прозаичной, и именно поэтому её стоит разобрать: агент пытался переопределить переменную окружения HOME, создав себе временный каталог, — и вместо подмены удалял содержимое настоящего домашнего каталога. Чаще всего это происходило в режиме полного доступа, когда агент работал без изоляции. Никакого злого умысла, никакого выхода из-под контроля: обычная ошибка в работе с путями, из тех, что живут в скриптах десятилетиями. Разница в том, что скрипт делает это один раз и предсказуемо, а агент — в непредсказуемый момент и на вашей рабочей машине. Разбираем, что из этого следует для настроек по умолчанию.

Что именно сломалось

Разберём механику, потому что она поучительнее самого инцидента.

Переменная окружения HOME указывает на домашний каталог пользователя. Множество программ строит от неё пути: туда пишутся настройки, кэши, временные файлы.

Агенту понадобилось изолировать свою работу — создать отдельное место под временные файлы и указать программам туда, а не в настоящий домашний каталог. Намерение правильное и даже похвальное: это попытка не наследить.

Реализация не удалась. Вместо того чтобы направить программы в новый каталог, операция затронула тот, который должна была заменить. Классическая ошибка порядка действий: сначала очистить цель, потом переназначить — и если переназначение не сработало, очищенной оказывается не та цель.

Ключевое условие — режим полного доступа без изоляции. В песочнице та же ошибка стёрла бы временный каталог песочницы, и никто бы её не заметил.

Почему это не история про восстание машин

Разграничение важное, потому что от него зависит, чему учиться.

Мы за месяц разобрали несколько сюжетов, где модель делала не то, что от неё ждали: инъекция в судебном документе, побег агента из песочницы, самораспространяющиеся идеи, атака на движок инференса. Все они про то, как система ведёт себя вопреки ожиданиям.

Этот случай устроен иначе, и он банальнее. Модель не решала удалять файлы. Она выполняла последовательность действий, в которой была ошибка, — ровно такая, какую совершает человек, пишущий скрипт в спешке.

Отсюда вывод, менее эффектный и более практичный: опасность агента определяется не его намерениями, а его правами. Ошибка в коде случится обязательно — вопрос только в том, до чего этот код сможет дотянуться в момент ошибки.

Что не так с режимом полного доступа

Раздел, ради которого стоит читать дальше.

Полный доступ включают, потому что без него неудобно. Агент постоянно спрашивает разрешения, работа прерывается, и соблазн выключить это раз и навсегда огромен. Особенно на своей машине, где «всё равно я один».

Проблема в том, что полный доступ — это не «немного больше свободы». Это отсутствие границы вообще. Агент получает те же права, что у вас: домашний каталог, настройки, ключи в переменных окружения, доступ в сеть, соседние проекты.

Три следствия, которые обычно не проговаривают:

Ошибка масштабируется до прав. Мелкая ошибка в путях при ограниченных правах испортит рабочий каталог. При полных — всё, до чего дотянется.

Проверить последствия нельзя заранее. Вы не знаете, какую последовательность агент выполнит в следующий раз, потому что она генерируется на ходу.

Восстановление ложится на вас. Ни один агент не гарантирует откат: он не знает, что именно было ценным.

Что делать

Практический минимум, отсортированный по отношению эффекта к трудозатратам.

1. Не включайте полный доступ по умолчанию. Если постоянные подтверждения мешают, разрешайте классы действий, а не всё сразу. Хороший пример такого разделения — четыре уровня риска в OpenWorker, где вы один раз соглашаетесь на категорию, а не на каждое действие.
2. Запускайте агента в отдельном каталоге. Не в домашнем, не в корне проекта со всеми ветками, а в рабочей копии, которую не жалко.
3. Держите систему контроля версий с зафиксированным состоянием. Незакоммиченные изменения — единственное, что агент способен уничтожить безвозвратно.
4. Уберите секреты из окружения процесса. Агент читает переменные окружения как обычный текст; это не только риск удаления, но и риск утечки.
5. Изолируйте, если агент выполняет код. Обычный контейнер тут не граница безопасности — почему.

Второй и третий пункты вместе закрывают большую часть риска и делаются за минуту.

Почему такие ошибки живучи

Стоит объяснить, почему проблема именно с путями возникает снова и снова — это помогает узнавать её в своём коде.

Работа с файловыми путями обманчиво проста. Строка выглядит понятной, операция удаления выглядит однозначной, и ошибка не проявляется до момента, когда переменная оказывается пустой или указывает не туда.

Классический сценарий: путь собирается из переменной и суффикса. Пока переменная заполнена, всё в порядке. Стоит ей оказаться пустой — и путь схлопывается к корню чего-нибудь важного. Ни компилятор, ни тесты этого не поймают, потому что синтаксически всё верно.

В обычной программе такой путь проходит через ревью и тесты, а сценарий, при котором переменная пуста, рано или поздно ловится. В агенте кода нет вовсе: последовательность действий генерируется на ходу, ревью нет, тестов нет, и та же ошибка попадает сразу в исполнение.

Отсюда полезное правило для любой обвязки, где действия порождаются моделью: опасные операции должны проходить проверку в вашем коде, а не приниматься на веру. Удаление, перемещение, перезапись — короткий список, для которого стоит написать отдельный обработчик, проверяющий, что путь находится внутри разрешённой области.

Что стоит проверить у себя сегодня

Пять вопросов, каждый занимает минуту.

В каком каталоге запускается ваш агент? Если в домашнем или в корне репозитория со всеми ветками — это первое, что стоит поменять.

Какие права у него на файловую систему? Только чтение, чтение и запись в один каталог, или всё подряд.

Что лежит в переменных окружения процесса? Ключи, токены, пароли от баз — всё это агент прочитает при первой попытке разобраться в среде.

Есть ли зафиксированное состояние? Незакоммиченная работа — единственное, что нельзя восстановить.

Проверяются ли пути перед опасными операциями? Если нет, это самый дешёвый рубеж, который можно добавить.

Ответы на эти пять вопросов дают больше, чем любые настройки самого агента, потому что они не зависят от того, какой инструмент вы используете и что в нём поменял вендор.

Что изменил вендор

Для полноты картины: заявлены правки инструкций для разработчиков, более настойчивое подталкивание к безопасным режимам разрешений и дополнительные защиты на уровне исполнения агента.

Формулировка «подталкивание к безопасным режимам» стоит внимания. Это признание, что настройка по умолчанию и настройка, которую выбирают пользователи, — разные вещи, и вторая опаснее. Инструмент можно сделать безопасным по умолчанию, но если удобство требует ослабления, ослаблять будут все.

Отсюда общий вывод про интерфейсы агентов: правильная конструкция не та, где безопасный режим стоит по умолчанию, а та, где безопасный режим достаточно удобен, чтобы его не выключали.

Чего мы не утверждаем

Мы не воспроизводили инцидент. Описание механики приводим по публикациям, перечисленным в источниках, включая объяснение представителя вендора.

Не утверждаем, что проблема не исправлена. Заявленные меры описаны; проверить их эффективность со стороны мы не можем.

Это не свойство конкретной модели. Ошибка была в слое исполнения агента, а не в том, как модель рассуждает. Другой агент с теми же правами может ошибиться иначе.

Наш контур этого не касается. KeyDealer передаёт запросы к моделям и не выполняет код; что именно хранится из запросов, перечислено в llms.txt. Права агента на вашей машине — целиком ваша зона.

Что держать в голове

Агент удалял домашний каталог не потому, что решил навредить, а потому что в его коде была ошибка порядка действий, а прав хватило, чтобы она стала катастрофической.

Практический вывод один и он повторяется из статьи в статью: ограничивайте не поведение, а возможности. Ошибки будут в любом случае; вопрос только в том, до чего они дотянутся.

Как мы отделяем проверенное от предполагаемого — на странице о проекте. Отдельный ключ с собственным лимитом под каждого агента: keydealer.ru/login.