Я, Арина Михална, рекомендую такой подход для защиты файлов от удаления ИИ агентом Claude Code: не давайте агенту широкие права на всю машину, перехватывайте команды удаления и держите проект в Git с резервной копией. Один запрет в настройках не спасёт, если агент уже успел выполнить команду через терминал. Нормальной считаю только такую схему, где ошибка агента превращается в неприятные пять минут, а не в вечер с холодным потом и поиском «как восстановить папку».

3 слоязащиты проекта
1 веткана работу агента

Три слоя защиты файлов от удаления ИИ-агентом в проекте

Почему агент может снести файлы, хотя вы просили «только поправить»

ИИ-агент не сидит внутри чата и не пишет советы в пустоту. В Claude Code он может менять файлы, запускать тесты, выполнять команды и коммитить изменения. Это его сильная сторона: не надо вручную переносить двадцать правок из ответа в редактор.

И тут же слабое место.

Ты пишешь: «Убери старый модуль, он больше не нужен». Агент видит папку, находит похожие файлы, строит план и начинает чистить. Если задача сформулирована криво, структура проекта ему незнакома или он неверно связал зависимости, последствия бывают шире одного модуля.

В новости The Decoder речь шла не о Claude Code, а об ошибке OpenAI Codex: пользователи сообщали об удалении реальных файлов без разрешения. Это не повод кричать «все агенты опасные, возвращаемся в Excel». Это нормальное напоминание: агент с доступом к файловой системе надо считать очень быстрым стажёром. Он может сделать много полезного. И он не должен получать ключи от серверной, пароль от кассы и право жать красную кнопку.

Самая противная ловушка тут такая: человек защищает проект от «плохого кода», но не от удаления. Линтер заметит ошибку в TypeScript. Тест может поймать поломку страницы. А вот команда, которая убрала каталог с черновиками, медиа или локальной базой данных, пройдёт тихо. Потом открываешь папку, а там ветер гуляет. Красота, конечно.

Claude Code читает проектные инструкции из CLAUDE.md при старте новой сессии. В статье про файл CLAUDE.md я разбирала, как использовать его для правил проекта. Но текстовая инструкция вроде «ничего важного не удаляй» — это только напоминание агенту. Она не является физическим запретом.

Матрица защиты: какие файлы беречь сильнее всего

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

Разложи проект хотя бы на четыре группы. От этого зависит, где ставить запреты и как часто делать копию.

Что лежит в папке Риск при удалении Что разрешать агенту Как страховать
Исходный код приложения Средний Менять в отдельной ветке, запускать тесты Git-коммиты, pull request, удалённый репозиторий
Конфиги .env, ключи, токены, сертификаты Очень высокий Не читать и не менять без ручной задачи Исключить из доступа, хранить вне рабочей папки, резервная копия
Данные клиентов, выгрузки, база Очень высокий Работать только с обезличенной копией Отдельное хранилище, бэкап, права только на чтение
Контент, картинки, документы Средний или высокий Создавать новые версии, не перезаписывать оригиналы Версии в облаке или Git LFS, папка archive
Временные файлы сборки Низкий Можно чистить по правилам Пересобираются автоматически

Если ты не разработчик, всё равно не пропускай эту таблицу. Сейчас сайты, боты и внутренние штуки собирают в вайбкодинге люди, которые вчера не открывали терминал. И это окей. Не окей — думать, что «раз я не пишу код, мне не нужны правила доступа».

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

Первый слой: не пускай Claude Code туда, где цена ошибки высокая

Принцип простой: агент должен иметь ровно те права, которые нужны для конкретной задачи. Не «на всякий случай доступ ко всему диску». Не «пусть сам разберётся». А папка и набор действий под один понятный результат.

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

Вот рабочий порядок:

  1. Создай отдельную ветку под задачу агента.
  2. Запускай его из папки конкретного репозитория.
  3. Убери из этой папки секреты и единственные копии важных файлов.
  4. Скажи агенту, какие каталоги он может менять, а какие только читать.
  5. Попроси сначала показать план и список файлов, которые он собирается затронуть.
  6. После работы посмотри изменения до слияния с основной веткой.

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

В CLAUDE.md можно закрепить проектные правила. Пиши их не как манифест на восемь экранов, а как короткие условия, которые можно проверить.

Работай только с файлами внутри {{папки проекта}}.
Не удаляй файлы и директории. Если считаешь удаление
необходимым, сначала покажи список путей и дождись моего
явного подтверждения.
Не изменяй `.env`, файлы с ключами, конфигурацию продакшена,
резервные копии и каталог {{папка с данными клиентов}}.
Все изменения делай в текущей ветке Git. Перед завершением
покажи `git diff` и перечисли изменённые файлы.

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

Когда агент уже умеет трогать проект, ему пора выдать правила, а не безлимитный пропуск.

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

Забрать рабочие разборы в канале

Второй слой: ловим удаление до команды, а не после паники

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

Удаление опаснее по трём причинам:

  • файл может исчезнуть вместе с историей, если он не был в Git;
  • команда может затронуть целую папку, а не один файл;
  • агент иногда использует очистку как способ «начать с чистого листа».

Поэтому в правилах и хуках отдельно перечисляй признаки удаления: rm, rmdir, unlink, очистку каталогов, массовое перемещение в неизвестное место. Не надо запрещать все команды терминала. Тогда Claude Code превратится в дорогой блокнот, а не помощника. Блокируй именно разрушительные действия и те пути, за которые тебе страшно.

Claude Code поддерживает настройки и механизмы управления действиями в проекте. Конкретный синтаксис правил и хуков зависит от версии инструмента, поэтому сверяй его с официальной документацией Claude Code, а не копируй случайный JSON из телеграм-канала трёхлетней давности. В безопасности очень грустноиграть в «а вдруг сработает» с устаревшими примерами.

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

Если команда содержит rm, rmdir, unlink, del, git clean -fd
или массовое перемещение файлов —
останови выполнение.
Покажи человеку: саму команду, путь, количество затронутых
файлов.
Продолжай только после явного «да» от человека, а не от
другого агента.

Смысл в том, чтобы разрушительная команда никогда не проходила молча. Даже если агент прав в 99 случаях из 100, тебе нужен именно тот один случай, где он ошибся — и хук — это точка, где ошибку можно остановить руками, а не разгребать последствия.

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

Третий слой: Git и бэкап — то, что спасает, когда первые два не сработали

Если первый слой не ограничил доступ, а второй не поймал команду, остаётся третий: возможность откатить проект назад. Это не «план на случай апокалипсиса», это обязательная часть работы с любым инструментом, который что-то меняет автоматически.

Для файлов, которые лежат в Git, восстановление обычно решается быстро:

  • git status и git diff — посмотреть, что изменилось прямо сейчас, до коммита;
  • git checkout -- <файл> — вернуть конкретный файл к последней сохранённой версии;
  • git revert <коммит> — безопасно отменить неудачный коммит новым коммитом, без переписывания истории;
  • git reflog — найти состояние проекта, если ветка потеряна или указатель сдвинулся не туда.

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

Для того, что в Git не живёт — медиафайлы, локальные базы, выгрузки, содержимое .env — нужен отдельный бэкап. Не «когда-нибудь настрою», а автоматическая копия по расписанию в другое место: облачное хранилище, второй диск, отдельный сервер. Разница между «есть копия за вчера» и «копии нет» — это разница между потерянным часом и потерянным месяцем работы.

Матрица восстановления по типу инцидента такая:

Что случилось Файл в Git? Что делать
Агент удалил файл и не закоммитил Да, был в предыдущем коммите git checkout -- <файл>
Агент закоммитил удаление Да git revert <коммит с удалением>
Ветка потеряна или перезаписана Да, где-то в истории git reflog, найти нужный коммит, восстановить ветку
Удалён файл, который никогда не добавляли в Git Нет Восстановление только из внешнего бэкапа
Удалена папка с данными или медиа Обычно нет Внешний бэкап или подтверждение, что копии нет

Как собрать три слоя в одну привычку, а не в три разных панических файла

Три слоя работают вместе, а не по очереди «если первый не сработал, тогда включим второй». На практике это выглядит так: перед задачей — отдельная ветка и чистая папка без секретов (слой один); во время задачи — хук ловит опасные команды и просит подтверждение (слой два); после задачи — коммит и, если что-то пошло не так, откат (слой три).

Для новичка в вайбкодинге такая связка звучит как лишняя работа. На деле это 10–15 минут настройки один раз на проект, а не на каждую сессию. Дальше агент работает в тех же границах автоматически, и тебе не нужно каждый раз держать в голове «а вдруг он сейчас что-то сломает».

По нашим замерам, разбор реальных инцидентов с ИИ-агентами — например, случай со взломом сайта спортзала через агента — показывает одну и ту же причину: агенту дали больше прав и меньше присмотра, чем требовала задача. Подробный разбор такого кейса я делала в статье что происходит, когда агент выходит за рамки задачи. Логика та же самая, что и с удалением файлов: не в том, что агент «злой», а в том, что границы не были заданы заранее.

По материалам: документации Claude Code, разбора The Decoder про ошибку удаления файлов в OpenAI Codex и документации Git по git revert.

Читайте также

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