Claude Code игнорирует запреты из CLAUDE.md: что вынести в permissions и хуки

Вы написали в CLAUDE.md «не удаляй данные без запроса», а агент всё равно удалил. Это не редкий баг: в issue #46779 автор жалуется, что Claude Code раз за разом стирал данные сверх задачи, хотя запрет был записан прямо. Разбор на Habr предлагает понятный способ мыслить об этом: правило должно жить там, где его цена нарушения оправдана.

Почему текст не держит

CLAUDE.md загружается в начале каждой сессии, и после сжатия диалога Claude Code перечитывает его. Казалось бы, правило всегда в контексте. Но проблема не в памяти. В бенчмарке StateTrack-Bench с EMNLP 2026 авторы отнесли 88,6% сбоев в длинных диалогах к дрейфу поведения: модель помнит ограничение, но перестаёт ему следовать. Microsoft Research добавляет общий фон: у топовых моделей качество в многоходовом диалоге в среднем на 39% ниже, чем в одноходовом.

Anthropic в своей документации честно пишет: инструкция вида «никогда не делай X» выполняется в большинстве случаев, но под давлением, в длинной сессии, в неоднозначной ситуации или при prompt injection может быть нарушена. Prompt injection здесь значит чужую инструкцию в файле, который агент открыл по задаче.

Делим правила по цене ошибки

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

• permissions: правила allow, ask и deny определяют, что агент делает сам, о чём спрашивает и что ему запрещено;
• hooks: shell-команды, которые Claude Code запускает на событие сессии, например перед записью файла или при попытке закончить ход;
• проверка кодом перед запуском, например скрипт, который не стартует работу без файла с подтверждённым планом.

Пример из практики автора: команда браузерного инструмента тратила платные кредиты. Её закрыли правилом deny в .claude/settings.json, а не просьбой в тексте. Файл настроек стоит коммитить в git, чтобы правила получила вся команда. Важная деталь из комментария к issue #65563: защита, смотрящая только на команды Bash, вызов через MCP не увидит. В самом issue агента просили расследовать баг, а он через автоматизацию браузера нажал удаление и подтверждение на реальной записи в продакшен-базе.

С ключами похоже. Deny на чтение .env закрывает файл, хук на запись отклоняет изменение с ключом, но вывод секрета из окружения эти два правила не перекрывают. Раскрытый ключ не вернуть, поэтому одним текстом такое не защищают.

Хук Stop против недоделанной работы

Чтобы агент не заканчивал ход, пока проверка не проходит, на событие Stop вешают скрипт, который запускает проверку проекта (например, make check) и при провале выходит с кодом 2. Код 2 блокирует завершение, а stderr уходит агенту как сообщение об ошибке. Код 1 без вывода действие не блокирует, это проверили в Caprock на версиях 2.1.289 и 2.1.299. С 2.1.295 опция onFailure: block блокирует действие и при сбое хука.

Есть лимит: после восьми блокировок подряд без вызова инструментов Claude Code всё равно завершает ход. Порог поднимает переменная CLAUDE_CODE_STOP_HOOK_BLOCK_CAP, и на длинных задачах стоит проверить, не упирается ли хук в него.

Что делать

Считайте CLAUDE.md журналом сбоев, а не декларацией. Добавляйте строку после второго одинакового промаха, держите файл короче 200 строк, назначьте владельца и проверяйте правки как код. Устаревшая запись вредит сильнее, чем её отсутствие.

Ограничение подхода: примеры в статье иллюстративные, точный синтаксис нужно сверять со страницей Configure permissions в документации. А главный вопрос к своему проекту простой: какие три правила в вашем файле стоят денег или секретов? Их первыми и переносите в deny, хуки и проверки кодом.