Claude Code и Cursor умеют не только писать код, но и удалять файлы, выполнять bash-команды и коммитить в git без остановки. Claude code permissions и cursor permissions решают ровно одну задачу: агент делает то, что вы разрешили, и не трогает то, что вы запретили. Ниже, пошагово: как настроить allow и deny list, зачем нужны pre-tool-use хуки и почему CLAUDE.md сам по себе ничего не гарантирует.
Разберем allow/deny list в settings.json, pre-tool-use хуки на exit code 2 и разницу между Claude Code и Cursor в контроле опасных команд. В конце: готовая карта выбора и таблица команд для deny list.
Зачем вообще ограничивать AI-агента в кодинге?
Агент видит только файлы и команды, до которых ему хватает прав. Без ограничений один неверно понятый промпт может стереть рабочую директорию целиком.
Claude Code и Cursor работают по циклу think, act, observe: агент рассуждает, выполняет действие через инструмент, потом смотрит на результат. Проблема в фазе act: там агент может редактировать файлы, удалять их и запускать bash-команды. По разбору из обучающего видео про режимы безопасности Claude Code, именно на этом этапе разработчик теряет контроль, если заранее не выставил границы.
Ключевой факт из практики: 93% permission-запросов в Claude Code разработчики подтверждают не глядя. Это превращает систему подтверждений в фоновый шум, а не в защиту. Отсюда и вывод: полагаться на то, что вы прочитаете каждый запрос, не стоит. Механизм должен работать сам, без вас в моменте.
Ниже разберем два уровня защиты: permissions в settings.json (что агенту вообще можно) и хуки (что физически блокируется, даже если агент очень хочет).
Как работают claude code permissions в settings.json?
Claude Code проверяет каждое действие по трем спискам: allow, ask и deny. При конфликте всегда побеждает deny, даже если команда есть в allow.
Правило простое и его стоит запомнить дословно: если команда одновременно попадает и в allow, и в deny, деню отдается приоритет. Порядок оценки: deny → ask → allow → режим по умолчанию, если правило вообще не найдено.
Файл лежит в трех местах. ~/.claude/settings.json — общий для всех ваших проектов. .claude/settings.json — настройки проекта, их стоит коммитить в репозиторий, чтобы вся команда работала по одним правилам. .claude/settings.local.json— личные исключения, добавляете в .gitignore.
Базовый безопасный конфиг выглядит так:
{
"permissions": {
"allow": ["Bash(git status)", "Bash(git diff:*)", "Bash(npm run test:*)"],
"ask": ["Edit", "Write", "Bash(git commit:*)", "Bash(git push:*)"],
"deny": ["Bash(rm -rf:*)", "Bash(curl:*)", "Read(./.env*)"]
}
}Читать и проверять код разрешаем без вопросов, изменения кода и коммиты подтверждаем вручную, а необратимые команды блокируем полностью на уровне deny.
Какие режимы permissions есть у Claude Code кроме allow/deny?
Помимо списков, у Claude Code есть режимы работы всей сессии. Их четыре штуки, и разница между ними прямо влияет на риск.
| Режим | Что делает | Когда использовать |
|---|---|---|
| Default | Спрашивает разрешение на каждое действие | Первая неделя работы с новым проектом |
| Accept edits | Автоматически принимает правки файлов, команды все еще подтверждаются | Когда доверяете агенту, но держите git под рукой |
| Plan | Агент только планирует, ничего не меняет | Проектирование новой фичи с нуля |
| Bypass | Отключает вообще все подтверждения | Только изолированный sandbox, никогда не в реальном проекте |
Bypass физически не нужен ни на одном рабочем репозитории. Это тот самый режим, который дает агенту ключи от всего сразу, и разработчики в комментариях к обучающим видео прямо называют его вариантом, который стоит избегать.
Как настроить allow и deny list шаг за шагом?
Настройка занимает пять минут: команда /permissions показывает текущие правила, а settings.json редактируется как обычный JSON-файл.
Cоздайте .claude в корне проекта, если его еще нет, и добавьте туда settings.json с пустыми массивами permissions. Дальше заполняете по шагам.
Шаг 1. Разрешите безопасные команды. Чтение файлов, git status, git diff, запуск тестов и линтера — это обратимые операции, их можно смело класть в allow.
Шаг 2. Переведите операции с последствиями в ask. Edit, Write, git commit, git push, npm install — сюда же деплой. Агент попросит подтверждение, но хотя бы не сделает это молча.
Шаг 3. Заблокируйте необратимое через deny. rm -rf, чтение .env, прямой curl без разбора и любые команды, которые трогают продакшн-базу.
Шаг 4. Проверьте через /permissions внутри сессии. Команда покажет, какое правило откуда взялось: из проектного файла, пользовательского или локального.
Проверять стоит именно так, потому что правила из разных файлов не заменяют друг друга, а объединяются. Более строгое правило из проектного settings.json нельзя случайно ослабить локальным файлом.
Что такое pre-tool-use хуки и зачем они нужны?
PreToolUse хук запускается до выполнения инструмента и может физически остановить его через exit code 2. В отличие от промпта, хук сработает всегда, а не когда агент "вспомнит".
Разница между запретом в промпте и хуком принципиальная. Промпт вида "никогда не удаляй файлы" агент может проигнорировать, если контекст переполнен или формулировка задачи звучит убедительнее запрета. Хук такого шанса не оставляет: он детерминированный скрипт, который проверяет команду перед запуском.
Логика на exit code простая. Код 0 значит: продолжай, все хорошо. Код 2 блокирует конкретно PreToolUse и передает агенту текст ошибки из stderr, чтобы тот мог скорректироваться. Любой другой код — просто некритичная ошибка самого хука, выполнение продолжается.
Пример хука, который блокирует rm -rf в bash-командах:
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": "if echo \"$CLAUDE_TOOL_INPUT\" | grep -q 'rm -rf'; then echo 'Blocked: rm -rf запрещен' >&2; exit 2; fi"
}
]
}
]
}
}Похожим образом блокируют запись в .env: хук на Write/Edit проверяет путь файла через tool_input.file_path и выходит с кодом 2, если в пути встречается .env. Такой конфиг стоит держать в репозитории вместе с проектом, а пути к скриптам указывать через переменную $CLAUDE_PROJECT_DIR, чтобы они работали независимо от того, откуда запущена сессия.
Почему CLAUDE.md не защищает от опасных команд?
CLAUDE.md — это файл с контекстом и инструкциями для агента, а не система защиты. Claude читает его как часть промпта, и в этом главная проблема: правило из CLAUDE.md может быть проигнорировано или размыто, если модель посчитает задачу более приоритетной.
Максим: «Портал VibeCoderz мы с командой собрали за неделю, тремя скриптами, голосом, прямо в Claude Code. Там уже 6 200 материалов. Одна забытая команда rm -rf в такой момент и переделывать пришлось бы весь каталог заново.»
Правильное разделение обязанностей такое: в CLAUDE.md пишете контекст и стиль работы над проектом (какие файлы важны, какая архитектура, как называть переменные). В settings.json и хуках прописываете жесткие границы: что разрешено без вопросов, что требует подтверждения, что заблокировано физически. Дублировать запрет в CLAUDE.md можно, но полагаться только на него нельзя.
Cursor или Claude Code: чей denylist надежнее?
У Cursor denylist в auto-run режиме исторически обходился через обфускацию команд и переменные окружения. Claude Code с deny-first порядком правил и sandbox для bash-процессов держит границу строже, но тоже не абсолютную.
У Cursor есть похожий механизм: в режиме Auto Run командам разрешено выполняться без подтверждения, а denylist должен останавливать опасные. Разработчики из Backslash Security показали, что до исправления в релизе 1.3 обфусцированные команды проходили denylist незамеченными. Похожая история описана в CVE-2026-22708: агент Cursor в режиме Allowlist пропускал часть shell-встроенных команд, если атакующий через prompt injection менял переменные окружения.
В марте 2026 Cursor обновил модель до трехступенчатого Cursor Auto-review: allowlist пропускает доверенные вызовы мгновенно, sandbox изолирует что может, а классификатор-субагент решает по всем остальным. Настраивается через .cursor/permissions.json с полями allow_instructions и block_instructions. Сам разработчик прямо называет это best-effort механизмом, а не жесткой границей безопасности.
| Параметр | Claude Code | Cursor |
|---|---|---|
| Приоритет правил | deny всегда выше allow | allowlist + sandbox + классификатор |
| Файл конфигурации | .claude/settings.json | .cursor/permissions.json |
| Детерминированная блокировка | PreToolUse хуки, exit code 2 | Только sandbox-изоляция |
| Известные обходы | Не выявлено массовых обходов sandbox | Обфускация команд, переменные окружения (CVE-2026-22708) |
Для задач, где важна гарантия, а не удобство, связка settings.json плюс хуки в Claude Code выглядит надежнее. Cursor удобнее для скорости работы, но denylist там стоит держать вместе с allowlist, а не полагаться на него в одиночку.
Какие команды точно нужно заносить в deny list?
Список ниже стоит взять за основу и адаптировать под свой проект. Это не полный перечень, а минимальный набор, с которого стоит начинать в любом репозитории.
| Команда или паттерн | Почему опасна |
|---|---|
| rm -rf * | Необратимое удаление файлов и директорий |
| curl | bash | Выполнение произвольного кода из сети без проверки |
| git push --force | Перезаписывает историю, ломает работу команды |
| Чтение и запись .env* | Утечка или подмена секретов и токенов |
| DROP TABLE, DELETE FROM без WHERE | Потеря данных в продакшн-базе |
| chmod 777 | Открывает файлы на запись всем пользователям системы |
Гайд из аудита разрешений Claude Code рекомендует держать в deny именно необратимые операции, а обратимые вроде git commit переводить в ask. Логика простая: то, что можно откатить через git или checkpoint, спокойно уходит в подтверждение. То, что откатить нельзя, блокируется физически.
Какие ошибки чаще всего допускают при настройке permissions?
Три частые ошибки: включают bypass "на минутку", надеются на промпт вместо хука и не проверяют правила через /permissions после каждого изменения проекта.
Первая ошибка: bypass-режим ради скорости на "простой задаче". Простых задач для агента с полным доступом к shell не бывает: одна неверно понятая формулировка команды и откатывать нечего, если git не закоммичен.
Вторая: надежда на негативные формулировки в промпте вроде "не удаляй базу", "не делай ошибок". По разбору гайдлайнов для продакшн-агентов такие промпты работают нестабильно, особенно если задача звучит убедительно противоречиво. Ограничение прав доступа надежнее любой словесной просьбы.
Третья: настроили permissions один раз и забыли. Проект растет, появляются новые скрипты и новые пути к секретам, а deny list остается прежним. Проверять /permissions стоит после каждого крупного изменения структуры проекта, не только на старте.
Итог: какая связка нужна для безопасной работы с AI-агентом
Для большинства проектов на 2026 год оптимальна связка: allow на чтение и тесты, ask на изменения кода и git, deny на необратимые операции плюс PreToolUse хук как физический барьер поверх всего этого.
| Ваш сценарий | Что настроить |
|---|---|
| Соло-проект, много ручной работы | Default-режим + базовый deny list на rm -rf и .env |
| Команда, общий репозиторий | settings.json в git + hooks на форматирование и блокировку |
| CI/CD, автономные прогоны | Accept edits + строгий allow list + хуки с логированием |
| Экспериментальный sandbox | Bypass допустим только здесь, и нигде больше |
Если работаете с Claude Code или Cursor на постоянной основе, разбор permissions и хуков стоит внести в чеклист запуска нового проекта, а не оставлять на потом. Полный каталог IDE и агентов для вайбкодинга собран в каталоге AI-инструментов.
FAQ
Что произойдет, если команда есть и в allow, и в deny одновременно? Сработает deny. Правило приоритета в Claude Code строгое: запрет всегда перекрывает разрешение, независимо от того, в каком файле оно объявлено.
Можно ли просто написать в CLAUDE.md "никогда не удаляй файлы"? Можно, но это не гарантия. CLAUDE.md читается как часть промпта, а не как enforced-правило. Для гарантии нужен deny в settings.json или PreToolUse хук с exit code 2.
Чем отличается Accept edits от Bypass в Claude Code? Accept edits принимает правки файлов автоматически, но команды в bash все еще требуют подтверждения. Bypass отключает все проверки полностью, включая деструктивные команды.
Работает ли denylist в Cursor так же надежно, как deny в Claude Code? Не совсем. У Cursor были зафиксированы обходы denylist через обфускацию команд и через манипуляции переменными окружения (CVE-2026-22708). Рекомендуется комбинировать allowlist с sandbox-режимом, а не полагаться на denylist в одиночку.
Нужно ли настраивать permissions, если я работаю один и без продакшн-базы? Да. Даже локальный проект может содержать .env с ключами от API или платежных систем. Один неверно понятый промпт способен удалить недели работы, если нет git-коммитов и deny list.
Как проверить, какие правила сейчас активны в Claude Code? Команда /permissions внутри сессии показывает весь список: что разрешено, что запрещено, в каком режиме сейчас работает агент и из какого файла взялось каждое правило.
Хуки замедляют работу агента? Минимально. PreToolUse хук — это короткий скрипт, который выполняется за миллисекунды перед действием. Задержка ощутима только если хук делает что-то тяжелое, вроде сетевого запроса без таймаута.
Если настраиваете permissions под конкретный проект и не уверены, какую связку выбрать, можно обсудить это на консультации с Максимом.
Обновлено: октябрь 2026
