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

> В проверенных официальных материалах не найдена встроенная настройка maxDiffFiles или maxDiffLines. Показываю, как собрать локальное правило через hook и проверить его настоящим изменением.

Источник: https://vibeceh.ru/guides/claude-code-nastroit-ogranichenie-na-bolshoj-diff
Автор: Сергей Мазур · опубликовано 2026-08-22

Если ты вводишь запрос `claude code limit` и Claude Code однажды переписал больше, чем ты просил, тебе нужен не ещё один режим подтверждения, а проверка масштаба изменения. Ограничение количества файлов и строк помогает понять, когда точечная задача расползается. Если хочешь отработать такой подход на практике, начни с практикума по вайб-кодингу для специалистов. Ниже я показываю, как настроить локальную проверку и сверить результат через Git.

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

запросы `claude code limit`, `claude code tasks`, `claude code tools`, `claude code tokens` и `claude code commands` затрагивают разные стороны работы, но для diff нужен отдельный контроль масштаба. Claude Code может повторно использовать в следующих ходах прочитанные файлы и вывод команд, поэтому длинная сессия постепенно размывает исходную задачу. Чем шире diff, тем больше материала приходится проверять человеку. Я использую лимит как сигнал остановки: сначала смотрю на масштаб, потом принимаю результат.

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

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

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

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

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

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

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

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

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

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

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

запрос `claude code limit` смешивает три разные границы: объём контекста, расход токенов и размер изменения. В проверенных официальных материалах не найдена встроенная настройка `maxDiffFiles` или `maxDiffLines`. `PreToolUse` блокирует вызов до выполнения; проверка будущего общего diff возможна только если необходимый масштаб выводится из доступных данных. Фактический общий diff можно проверить после действия через Git, но такая проверка не отменяет уже выполненную запись и нужна для остановки дальнейшей работы, отказа от результата или отката.

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

| Граница | Что ограничивает | Чего не ограничивает | Механизм |
| --- | --- | --- | --- |
| Контекст | Объём данных в текущей работе | Число изменённых файлов и строк | Окно контекста |
| Токены | Объём обрабатываемого текста | Размер diff | Лимит или расход токенов |
| Diff | Число файлов и добавленных и удалённых строк | Объём прочитанных данных | Локальный hook и Git |

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

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

`PreToolUse` запускается до выполнения tool call и может заблокировать вызов по доступным данным о нём. Но текущий `git diff` в этот момент ещё не показывает результат будущей записи, поэтому фактический размер нужно проверять после действия. О настройке такой защиты смотри в материале [про хуки Claude Code и PreToolUse](/guides/huki-claude-code-ostanovit-opasnoe-izmenenie-fajla). Проектное правило можно хранить в `.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 в документации нет.

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

Запрос `claude code modes` не сводится к выбору режима с автоматическим или ручным подтверждением. Автоматическое одобрение ускоряет работу, но не заменяет защитное правило. Большой diff допустим для крупной задачи, если границы заранее ясны и результат проходит более глубокую проверку.

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

Перевод цитаты: «Постоянное нажатие “approve” замедляет циклы разработки и может привести к “усталости от подтверждений”».

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

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

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

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

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

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

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

Запросы `claude code tools` и `claude code permissions` описывают разрешённые действия Claude Code. Общий размер diff он не учитывает. Запрет `Edit` или `Write` не перекрывает запись через `Bash` и запущенные им команды вроде `sed`, `python`, `echo` или `tee`; отдельно проверь shell-команды, которые запускают PowerShell. В этой схеме permissions ограничивают отдельные операции, а Git-аудит или собственный hook могут проверять масштаб diff. Внешние pre-commit и CI-правила тоже могут выполнять такой аудит.

![Мужчина закрывает лицо ладонью рядом со схемой обхода запрета Edit через Bash.](https://s3.regru.cloud/crossmark/statejnik/images/guides/claude-code-nastroit-ogranichenie-na-bolshoj-diff/kadr-1.webp)

`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](https://github.com/anthropics/claude-code/issues/29795) сообщается о таком обходе: после блокировки `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?

настрой локальный `command` hook в `.claude/settings.json`, проверь его через `/hooks`, а затем сделай тестовую правку. Заранее создай baseline и отдельно проверь блокировку до записи и аудит фактического diff после записи. Post-проверка не отменяет уже выполненное действие, поэтому превышение требует остановки, отклонения результата или отката.

![Кот с поднятой лапой показывает три шага проверки command hook в настройках проекта.](https://s3.regru.cloud/crossmark/statejnik/images/guides/claude-code-nastroit-ogranichenie-na-bolshoj-diff/kadr-2.webp)

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

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

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

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

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

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

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

   

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

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

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

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

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

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

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

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

Этот шаг подтверждает только загрузку настройки. Он не доказывает блокировку. В [документации по hooks](/guides/huki-claude-code-ostanovit-opasnoe-izmenenie-fajla) описан цикл из трёх частей: добавить hook, проверить его через `/hooks`, затем спровоцировать событие и посмотреть результат.

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

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

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

На Windows это обязательный шаг: в пользовательском issue [Windows: PreToolUse hook exit 2 doesn't block the tool call](https://github.com/anthropics/claude-code/issues/80039) описан случай, когда `exit 2` не остановил изменение. Настройка могла выглядеть корректной, а файл всё равно изменился.

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

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

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

Отдельно проверь `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?

если post-проверка нашла превышение, останови дальнейшие вызовы, сравни рабочее дерево с baseline и откати только изменения текущей задачи. Сначала отдели их от посторонних правок пользователя.

![Озадаченная собака смотрит на команды Git для проверки и отката лишних изменений.](https://s3.regru.cloud/crossmark/statejnik/images/guides/claude-code-nastroit-ogranichenie-na-bolshoj-diff/kadr-3.webp)

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

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

Коротко: создай baseline, затем используй `git diff --stat` для сводки и `git diff --numstat` для добавленных и удалённых строк. Так проще отделить масштаб текущей задачи от посторонних изменений. Перед практической проверкой можно открыть [разбор diff до правки в Claude Code](/guides/claude-code-prosit-agenta-pokazat-diff-do-pravki).

`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](https://github.com/anthropics/claude-code/issues/9550) описана проблема: без отдельного baseline трудно определить, какие именно файлы Claude изменил во время сессии.

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

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

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

Сначала посмотри `git diff --stat`, затем `git diff --numstat`, а после этого открой сам diff. Сравнивай рабочее дерево с baseline, созданным до запуска Claude Code: обычный `git diff` может включать изменения, сделанные пользователем или другим процессом.

Проектный hook можно хранить в `.claude/settings.json`. В проверенной официальной документации настройки `maxDiffFiles` или `maxDiffLines` не найдены; в статье размер diff предлагается задавать собственным hook или отдельным Git/CI-правилом.

В `CLAUDE.md` можно описать пожелание: например, попросить не менять больше определённого числа файлов без остановки. Для жёсткого запрета этого недостаточно. Нужен `PreToolUse` hook или permissions, потому что текстовая инструкция не даёт механической блокировки и не защищает от обхода через другой инструмент записи.

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

Минимально проверь `Edit`, `Write` и `Bash`; добавь другие инструменты и shell-пути, которые используются в проекте, включая PowerShell внутри Bash. Запрет только `Edit` и `Write` обходится через shell-команды вроде `sed`, `python`, `echo` или `tee`. Поэтому hook на одном инструменте не гарантирует контроль всех способов записи.

Прямой связи нет. Прочитанные файлы и вывод команд повторно участвуют в следующих ходах и расширяют контекст, но размер контекста сам по себе не задаёт максимальное число изменённых файлов или строк. Для механической блокировки в Claude Code можно добавить отдельный hook; Git, pre-commit и CI остаются альтернативными слоями аудита.

Можно, если защита проверена настоящим действием и охватывает все используемые способы записи. Автоматическое подтверждение не заменяет hook: постоянные ручные подтверждения могут привести к approval fatigue. После включения режима всё равно сверяй файл и Git с baseline.

Задай границы в запросе и `CLAUDE.md`, а механический порог вынеси в `PreToolUse` hook. Проверяй количество файлов и добавленных и удалённых строк относительно baseline. Большую задачу лучше разделять, если текущий diff уже трудно проверить.

Нет подтверждённой прямой связи. Лимит токенов и размер контекста описывают объём обрабатываемых данных, а не число записанных файлов. Количество изменённых файлов и строк нужно считать отдельным правилом через hook или Git и сравнивать с baseline.

Сам по себе режим не создаёт лимит diff. Ручное подтверждение помогает увидеть действия, но не заменяет механическую проверку. Автоматический режим допустим только рядом с проверенным `command` hook и ясной границей задачи.

Посмотри статистику через `git diff --stat` и `git diff --numstat`. Дополнительно проверь список файлов и сам diff. Контекст сессии не является надёжным счётчиком изменений, потому что в него попадают чтение файлов и вывод команд.

Начни с `git diff --stat`, чтобы увидеть краткий масштаб. Затем запусти `git diff --numstat` и проверь отдельные файлы. Если baseline не создан заранее, сначала отдели изменения текущей сессии от изменений пользователя или другого процесса.

- [Maximizing the value of your Claude Code sessions](https://claude.com/blog/maximizing-the-value-of-your-claude-code-sessions)
- [Steering Claude Code: when to use CLAUDE.md, skills, hooks, and subagents](https://claude.com/blog/steering-claude-code-skills-hooks-rules-subagents-and-more)
- [Automate workflows with hooks](https://code.claude.com/docs/en/hooks-guide)
- [Hooks reference](https://code.claude.com/docs/en/hooks)
- [Beyond permission prompts: making Claude Code more secure and autonomous](https://www.anthropic.com/engineering/claude-code-sandboxing)
- [Code Review for Claude Code](https://claude.com/blog/code-review)
- [Include Modified Files in Hook Input](https://github.com/anthropics/claude-code/issues/9550)
- [Best Practice: 5-Layer QA & Safety System Built Over 68 Claude Code Failures](https://github.com/anthropics/claude-code/issues/29795)
- [Windows: PreToolUse hook exit 2 doesn't block the tool call](https://github.com/anthropics/claude-code/issues/80039)
- [Agent/Prompt hooks do not block PreToolUse or deliver feedback to Claude](https://github.com/anthropics/claude-code/issues/33125)