Правила разрешений Claude Code и settings.json: allow / ask / deny

Правила разрешений в Claude Code позволяют прописать записи allow / ask / deny в settings.json и точно задать, какие инструменты, команды, файлы и домены выполняются без запроса, спрашивают подтверждение каждый раз или вовсе запрещены. Их можно использовать совместно в команде: вы наверняка блокируете опасное и при этом даёте безопасной рутинной работе идти без помех.

В этом руководстве разбираем, что такое правила разрешений (и чем они отличаются от режимов разрешений), приоритет allow/ask/deny, синтаксис правил, иерархию settings.json и практические рецепты — всё на основе официальной спецификации.

1. Что такое правила разрешений (в сравнении с режимами)

Claude Code использует многоуровневую систему разрешений. Чтение (просмотр файлов, Grep и т. п.) не требует подтверждения; команды Bash и редактирование файлов — требуют, и поверх этой базовой линии правила позволяют задавать точечные исключения (источник: официальный раздел Claude Code «Configure permissions»).

Правила легко спутать с режимами разрешений. Режимы — это широкая базовая линия «как часто спрашивать» (default/acceptEdits/auto и т. д.); правила — это спецификации для конкретного инструмента и конкретной команды. Они работают вместе: режим задаёт базовую линию, а правила переопределяют её через «это всегда разрешать» или «это никогда не разрешать».

2. allow / ask / deny и приоритет

Существует три типа правил. Команда /permissions показывает и редактирует их (а также указывает, из какого settings.json каждое из них пришло).

Правила проверяются в порядке deny → ask → allow. Исход определяет первое совпадение, и специфичность правила не меняет порядок. Широкое deny Bash(aws *) перебивает более точное allow Bash(aws s3 ls). Суть в том, что deny не может нести исключения по allow-списку.

3. Синтаксис правил (Tool(specifier))

Формат — Tool (всё) или Tool(specifier) (конкретное). У каждого инструмента свой стиль спецификатора.

Wildcard-символы в Bash могут стоять где угодно. Bash(ls *) (пробел + *) совпадает с ls -la, но не с lsof (граница слова); Bash(ls*) (без пробела) совпадает с обоими. Завершающее :* эквивалентно *.

// Разрешить безопасные команды, запретить git push
{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)"
    ],
    "deny": [
      "Bash(git push *)"
    ]
  }
}

Помните о составных командах. Claude Code понимает разделители вроде && || ; |, и каждая подкоманда должна совпадать самостоятельно. Bash(safe-cmd *) не разрешает safe-cmd && rm -rf .. Учтите, что команды только для чтения (ls/cat/grep/find/pwd и т. д.) выполняются без запроса в любом режиме, а обёртки вроде timeout/nice/nohup отбрасываются перед сопоставлением.

Пути Read/Edit следуют семантике gitignore с четырьмя якорями:

※ /Users/... НЕ является абсолютным — он относителен корню проекта. Для абсолютных путей используйте //Users/... (двойной слеш). Read(.env) равно Read(**/.env) и совпадает с каждым .env ниже по дереву.

4. Иерархия и приоритет settings.json

Правила живут в settings.json. Файлов несколько, и более высокие уровни сильнее. Ключевое правило: deny на любом уровне всегда перебивает allow на любом другом уровне.

// .claude/settings.json (общие для команды)
{
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": ["Bash(npm run *)", "WebFetch(domain:docs.example.com)"],
    "deny": ["Read(.env)", "Read(**/secrets/**)", "Bash(git push *)"],
    "additionalDirectories": ["../shared-lib"]
  }
}

Здесь же задаётся режим разрешений по умолчанию — через defaultMode (подробнее о режимах). Чтобы читать/редактировать за пределами рабочего каталога, добавьте пути в additionalDirectories.

5. Практические рецепты

Распространённые комбинации. Базовый принцип: наверняка запретить опасное, разрешить безопасную рутину, чтобы автоматизировать её.

Ограничивать URL через шаблоны аргументов Bash ненадёжно (curl http://github.com/ * легко обходится через -X GET или подстановку переменных). Вместо этого запретите curl/wget и разрешите конкретные домены через WebFetch(domain:...). Для более строгого контроля проверяйте URL в хуке PreToolUse.

6. Подводные камни и частые путаницы

• Deny обеспечивает Claude Code, а не модель. Фраза «не читай это» в промпте или CLAUDE.md не остановит чтение без правила.
• Deny на Read/Edit не остановит косвенный доступ. Оно применяется к встроенным файловым инструментам и cat/head/sed, но не к скрипту на Python или Node, который сам открывает файлы. Для контроля на уровне ОС используйте ещё и песочницу (sandboxing).
• Следите за «запускателями» окружения. devbox run *, npx и docker exec выполняют свои аргументы как команду, поэтому Bash(devbox run *) заодно разрешает devbox run rm -rf .. Пишите правила, включающие внутреннюю команду.
• Хуки не переопределяют правила. Хук PreToolUse может расширить разрешения, но deny/ask проверяются независимо от того, что возвращает хук (приоритет deny-first неизменен).

※ Поведение соответствует официальной документации Claude Code (Configure permissions / Settings) по состоянию на июнь 2026. Оно может измениться — сверяйтесь с официальной документацией за актуальными данными.

Итоги

Три вывода о правилах разрешений Claude Code.

• Что это: allow/ask/deny в settings.json, чтобы разрешать/спрашивать/запрещать по инструменту, команде, файлу и домену. Режимы задают базовую линию; правила решают частности.
• Приоритет: deny → ask → allow (побеждает первое совпадение; специфичность не важна). Deny на любом уровне всегда побеждает. Уровни: управляемые > CLI > local > project > user.
• Синтаксис: Tool(specifier). Bash использует wildcard-символы (пробел + * = граница слова), Read/Edit используют пути в стиле gitignore, WebFetch использует domain:. В составных командах должна совпадать каждая подкоманда.

«Наверняка блокировать опасное, автоматизировать безопасную рутину» — суть проектирования правил. Сочетайте это с режимами разрешений, хуками и настройкой effort, чтобы запускать Claude Code безопасно и без сбоев.

FAQ