Claude Code: 8 пунктов для ограничения большого diff через хук

Как контролировать объём работы Claude Code и claude code tasks?

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

Отсюда две разные проблемы:

• контекст становится длиннее;
• область изменения становится шире.

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

После ускорения написания кода узким местом становятся проверка, review и безопасность. Claude может быстро собрать правку. У человека при этом не появляется такой же быстрый способ понять, что изменилось и зачем.

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

Если Claude внезапно трогает несколько файлов вместо одного, это повод остановиться и спросить:

1. Какие файлы относятся к задаче напрямую?
2. Почему каждый дополнительный файл понадобился?
3. Можно ли разделить работу на несколько коротких шагов?
4. Что изменится, если принять только минимальную правку?

Большой diff бывает нормальным для миграции или крупной функции. Проблема начинается, когда ты не планировал такой объём и замечаешь его только после завершения работы.

Какие ограничения можно настроить для claude code tokens?

Токен показывает единицу текста, которую модель обрабатывает в запросе и ответе. Лимит контекста отвечает за объём данных, который помещается в текущую работу. Объём токенов показывает, сколько текста модель обрабатывает. Размер diff отвечает на другой вопрос: сколько файлов и строк изменилось.

Нельзя заменить одно другим. Уменьшение контекста не поставит запрет на изменение многих файлов. Ограничение токенов не сообщит, что Claude переписал нужный экран вместе с соседними модулями.

В проверенных официальных материалах не найдена настройка вида maxDiffFiles или maxDiffLines; это не доказывает отсутствие такой функции во всех версиях Claude Code. Поэтому обещание «Claude Code сам не изменит больше N файлов» без дополнительного правила нельзя считать подтверждённым для установленной версии.

PreToolUse запускается до выполнения tool call и может заблокировать вызов по доступным данным о нём. Но текущий git diff в этот момент ещё не показывает результат будущей записи, поэтому фактический размер нужно проверять после действия. О настройке такой защиты смотри в материале про хуки Claude Code и PreToolUse. Проектное правило можно хранить в .claude/settings.json, чтобы оно жило рядом с кодом и не зависело от памяти отдельной сессии.

Claude вызывает инструмент, после чего hook получает событие. Для детерминированной блокировки в этом сценарии используй проверяемый command hook и протестируй результат на установленной версии.

1. Claude собирается вызвать инструмент.
2. PreToolUse получает событие.
3. Hook получает событие и проверяет доступные данные о предстоящем вызове, но не может по текущему diff заранее измерить результат записи.
4. Если условие превышения вычислимо до вызова, PreToolUse возвращает блокировку.
5. Claude получает короткое объяснение причины.

Порог N файлов и M строк не задан Anthropic. Это инженерное решение под конкретную задачу. Для маленькой правки порог будет ниже. При миграции он может мешать и потребует временного исключения.

Не смешивай правило с инструкцией в CLAUDE.md. Там можно написать: «не меняй больше пяти файлов без отдельного подтверждения». Но это пожелание к модели. Жёсткую границу я бы выносил в hook.

У hook есть собственные ограничения. Он должен понимать, какие инструменты проверять, откуда брать baseline и что именно считать изменением. Готового универсального счётчика общего diff в документации нет.

В каком режиме безопаснее работать?

Постоянно подтверждать каждое действие тоже не значит контролировать работу. Anthropic предупреждает, что частые подтверждения замедляют цикл и могут привести к approval fatigue. Человек привыкает нажимать approve, особенно когда подряд идут чтение файлов, команды и небольшие правки.

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

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

Я бы разделял две ситуации:

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

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

Правило должно отвечать прямо: похоже ли текущее изменение на ту задачу, которую я дал.

Как связаны claude code tools и разрешения Claude Code?

CLAUDE.md подходит для описания нормы: какие каталоги не трогать, какие файлы считать чувствительными, когда остановиться и попросить подтверждение.

Этого мало, если мне нужен именно запрет: инструкция в CLAUDE.md остаётся пожеланием к модели. Hook не убеждает модель словами. Он получает событие и либо возвращает разрешение, либо останавливает вызов, если условие можно проверить до записи.

При этом permissions тоже не дают готового контроля diff. Можно закрыть отдельное действие, но запись файла иногда проходит через другой инструмент.

Практический обход выглядит так:

• Edit заблокирован;
• Claude вызывает Bash;
• внутри запускает sed, python, echo или tee;
• файл меняется уже не через Edit.

На Windows отдельно протестируй shell-команды через Bash, которые запускают PowerShell. Поэтому hook, который слушает только Edit|Write, выглядит защищённым, но не контролирует запись через Bash и его shell-команды.

В пользовательском issue Best Practice: 5-Layer QA & Safety System Built Over 68 Claude Code Failures сообщается о таком обходе: после блокировки Edit Claude может использовать Bash с sed, python -c или echo >. Поэтому hook на уровне одного инструмента не охватывает все пути записи.

Я бы собирал защиту слоями:

1. В CLAUDE.md описать границы задачи.
2. В permissions ограничить опасные действия.
3. В hook проверять Edit, Write и Bash, включая Bash-команды, запускающие PowerShell или другие оболочки.
4. Через Git сверять итоговый diff с baseline.
5. Отдельно проверить реальную попытку изменения.

Последний пункт нельзя заменять просмотром JSON. На Windows поведение блокировки особенно важно проверять на реальном изменении. Поэтому файл после теста нужно открыть и убедиться, что он не изменился.

Как настроить и проверить ограничение на большой diff?

Готового JSON, который надёжно считает общий diff, в использованных источниках нет. Поэтому я не выдаю придуманный конфиг за проверенное решение. Ниже - порядок настройки и заготовка запроса, которая помогает собрать правило под конкретную систему и затем проверить его руками.

1. Подготовь чистую точку сравнения.

   Убери из рабочего дерева посторонние изменения или явно зафиксируй исходное состояние для сравнения.

   Обычный git diff может включить изменения, сделанные тобой или другим процессом. Поэтому baseline нужен до запуска Claude Code. Иначе hook не отличит правку агента от уже существующей правки.

   Не называй baseline «изменениями Claude Code». Для запросов claude code tasks это только исходная точка, относительно которой считается новое состояние задачи.

2. Создай проектную настройку.

   Добавь hook в .claude/settings.json и выбери тип command.

   Командный hook должен запускаться до tool call, читать переданные данные, считать изменение и возвращать однозначный результат. В настройке укажи инструменты, через которые Claude может записывать файлы: прежде всего Edit, Write и Bash; отдельно протестируй внутри Bash команды с PowerShell, sed, Python, echo и tee.

   Для порога задай две отдельные величины: максимальное количество файлов и максимальное количество добавленных и удалённых строк. Например, проект может выбрать 5 файлов и 200 строк как произвольные стартовые значения; это не рекомендация Anthropic и не универсальная граница.

   Заготовка запроса для создания command hookСкопировать промпт

   Собери для проекта Claude Code локальный PreToolUse hook типа command.
   
   Требования:
   - хранить настройку в проектном .claude/settings.json;
   - проверять инструменты Edit, Write и Bash; отдельно тестировать shell-команды, которые запускают PowerShell;
   - учитывать заранее созданный baseline для последующей проверки фактического diff;
   - после записи выполнять аудит diff и не выдавать его за предотвращение уже выполненной записи;
   - считать добавленные и удалённые строки после записи;
   - блокировать tool call только там, где будущий масштаб можно надёжно оценить по входным данным;
   - использовать короткое сообщение об отказе: число файлов, добавленные строки, удалённые строки и причина;
   - не вставлять полный diff в сообщение hook;
   - подробно описать, где хранится baseline и как обновить его перед новой задачей;
   - использовать type: "command", а не agent или prompt;
   - отдельно показать команды проверки на текущей операционной системе;
   - не считать конфигурацию рабочей без тестовой попытки изменить файл.
   
   Сначала проверь актуальный формат hooks для установленной версии Claude Code. Затем создай настройку и скрипт, объясни каждый файл и покажи тест превышения порога.

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

3. Выбери проверяемые инструменты.

   Не оставляй matcher только на Edit|Write: проверь Bash, а внутри него отдельно протестируй команды с PowerShell и другими оболочками.

   Запись через shell-команду обходит запрет на отдельные инструменты редактирования. На Windows добавь PowerShell. Если в проекте есть другие способы записи, их тоже нужно учитывать отдельно. Факт, что hook сработал для Edit, ничего не говорит о поведении Bash.

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

4. Задай пороги как рабочую границу.

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

   Официальной рекомендации по значениям нет. Для точечной задачи логично начать с небольшой границы. При крупной миграции порог придётся поднять или временно изменить. Порог выбирает владелец проекта; Claude Code не задаёт его встроенным свойством.

   Считай отдельно количество файлов и количество строк. Один файл может содержать огромную правку. Несколько маленьких файлов могут быть нормальной частью одной задачи. Две метрики ловят разные виды расползания.

5. Открой список hooks.

   Запусти /hooks внутри Claude Code и проверь, что правило зарегистрировано.

   Этот шаг подтверждает только загрузку настройки. Он не доказывает блокировку. В документации по hooks описан цикл из трёх частей: добавить hook, проверить его через /hooks, затем спровоцировать событие и посмотреть результат.

   Если правило не отображается, сначала исправь путь, JSON и matcher. Не переходи к проверке diff, пока Claude Code не видит сам hook.

6. Сделай тестовое изменение.

   Спровоцируй правку, которая точно превышает выбранную границу, и заранее определи, проверяешь ли ты блокировку PreToolUse или аудит уже выполненного diff.

   Создай отдельный тестовый файл или измени несколько безопасных строк в файле, который можно вернуть к исходному состоянию. Запусти действие через Claude Code. Проверь не только сообщение в терминале, но и содержимое файла.

   На Windows это обязательный шаг: в пользовательском issue Windows: PreToolUse hook exit 2 doesn't block the tool call описан случай, когда exit 2 не остановил изменение. Настройка могла выглядеть корректной, а файл всё равно изменился.

7. Проверь результат блокировки или аудита.

   Для PreToolUse убедись, что tool call остановлен и файл не изменился. Для post-проверки зафиксируй, что действие уже произошло, затем отклони результат или откати его.

   В сообщении достаточно числа файлов, количества добавленных и удалённых строк и пути к полному отчёту. Не вставляй полный diff в сообщение hook: длинный ответ может добавлять лишний контекст, поэтому проверь это отдельно на своей версии.

   Я не считаю правило рабочим, пока не прогоню именно тот путь записи, которым пользуется проект. Если превышение обнаружилось, но запись прошла, проверь тип hook, операционную систему, matcher и конкретный инструмент.

8. Повтори тест обходом.

   Отдельно проверь Edit, Write и Bash, включая команды с PowerShell, sed, Python, echo и tee.

   Запрет Edit не доказывает защиту от sed, python, echo, tee или PowerShell. Для каждого способа записи нужен отдельный тест. Так ты проверяешь реальную границу, а конфигурация на бумаге остаётся лишь предположением.

   После тестов верни рабочее дерево к baseline. Иначе следующая проверка будет считать тестовые файлы частью новой задачи.

Для этого сценария предпочтителен проверяемый command hook; agent и prompt нельзя считать надёжной блокировкой без теста на установленной версии. В описанном практическом случае они запускались, но не блокировали tool call, а type: "command" с однозначным кодом завершения сработал.

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

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

Как откатить превышенный diff?

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

Этот порядок относится к запросам claude code commands, claude code tools, claude code tasks и claude code tokens.

Коротко: создай baseline, затем используй git diff --stat для сводки и git diff --numstat для добавленных и удалённых строк. Так проще отделить масштаб текущей задачи от посторонних изменений. Перед практической проверкой можно открыть разбор diff до правки в Claude Code.

git diff --stat показывает сводку по файлам и строкам. Это быстрый способ увидеть, что правка стала шире ожидаемого.

git diff --numstat даёт числа добавленных и удалённых строк по каждому файлу. Такой вывод удобнее для механической проверки и для hook, который должен сравнить результат с порогом.

Проверяй в таком порядке:

1. Краткую статистику посмотри через git diff --stat.
2. Построчные числа затем проверь через git diff --numstat.
3. После этого открой сам diff только по тем файлам, которые попали в сводку.
4. Сравни результат с baseline, созданным до запуска Claude Code.

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

В issue Include Modified Files in Hook Input описана проблема: без отдельного baseline трудно определить, какие именно файлы Claude изменил во время сессии.

Для сообщения hook лучше использовать короткую сводку. Полный diff остаётся для ручного просмотра или отдельного файла. Длинное сообщение hook попадает в транскрипт и повторяется в следующих ходах, раздувая Контекст.

Если Git показывает больше изменений, чем ожидалось, не принимай результат целиком. Сначала выясни, что пришло из baseline, что сделал Claude Code, а что изменилось параллельно.

Вопросы и ответы