Claude

Разрешения в Claude Code — allow, deny и sandbox

Как настроить разрешения в Claude Code, чтобы не кликать «да» на каждый запрос, но и не дать AI доступ к секретам.

Pavel Matveev

Pavel Matveev

— 3 min read
Разрешения в Claude Code — allow, deny и sandbox
TL;DR: Claude Code спрашивает разрешение на каждое действие — запуск команд, чтение файлов, редактирование. Это можно настроить: автоматически разрешать безопасные команды (allow), блокировать опасные (deny) и изолировать bash в sandbox. Настраивается в settings.json.

Первое, что раздражает в Claude Code — бесконечные «Allow this tool?». Хочешь запустить тесты — разреши. Хочешь прочитать файл — разреши. Десятый раз за минуту. В какой-то момент ты начинаешь машинально жать «Yes» на всё, и это хуже, чем если бы разрешений не было вообще.

Хорошая новость: систему разрешений можно настроить один раз и забыть. Плохая — документация не самая интуитивная. Давай разберёмся.

Три типа правил

В settings.json (проектном или пользовательском) есть секция permissions с тремя списками:

  • allow — автоматически разрешать. Никаких вопросов, Claude просто делает.
  • deny — запретить. Claude не сможет выполнить действие, даже если очень хочет.
  • ask — спрашивать каждый раз. Это поведение по умолчанию для большинства инструментов.

Правила проверяются в порядке: сначала deny, потом ask, потом allow. Первое совпадение побеждает.

Синтаксис правил

Формат простой: Инструмент(паттерн). Вот примеры:

{
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)",
      "Bash(git diff *)",
      "Bash(git status)",
      "Read(~/.zshrc)"
    ],
    "deny": [
      "Bash(curl *)",
      "Bash(rm -rf *)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

Звёздочка * работает как wildcard. Bash(npm run test *) разрешит и npm run test, и npm run test --watch, и npm run test src/utils.

Можно указать инструмент без паттерна — тогда правило сработает для всех вызовов. WebFetch в deny заблокирует все HTTP-запросы.

Что стоит разрешить сразу

Вот мой базовый набор allow-правил, который экономит кучу кликов:

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(git log *)",
      "Bash(git branch *)"
    ]
  }
}

Логика простая: всё, что только читает данные или запускает проверки — можно разрешить. Тесты, линтер, git-команды для просмотра.

Что стоит запретить

Тут важнее: deny-правила защищают тебя от случайностей.

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)",
      "Read(./config/credentials.json)",
      "Bash(curl *)",
      "Bash(wget *)",
      "Bash(rm -rf *)"
    ]
  }
}

Файлы .env — первые кандидаты на блокировку. Claude может случайно прочитать API-ключи и включить их в ответ, а оттуда они попадут в логи Anthropic. Это заменило старый ignorePatterns — deny-правила работают надёжнее.

Sandbox — изоляция bash-команд

Sandbox — это следующий уровень безопасности. Когда он включён, bash-команды Claude выполняются в изолированной среде с ограниченным доступом к файловой системе и сети.

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": true,
    "network": {
      "allowedDomains": ["github.com", "*.npmjs.org", "registry.yarnpkg.com"],
      "allowLocalBinding": true
    },
    "excludedCommands": ["docker", "git"]
  }
}

Обрати внимание на autoAllowBashIfSandboxed: true. Когда sandbox включён, можно автоматически разрешать все bash-команды — они всё равно изолированы. Это убирает 90% «Allow?» вопросов.

excludedCommands — команды, которые запускаются вне sandbox. Docker и git обычно нужно исключать, потому что они не работают в изоляции.

Sandbox работает на macOS и Linux. На Windows — через WSL2.

Режимы разрешений

Claude Code может запускаться в разных режимах:

  • Стандартный — спрашивает разрешения по правилам
  • acceptEdits — автоматически разрешает редактирование файлов, спрашивает только про bash
  • bypassPermissions — разрешает всё (флаг --dangerously-skip-permissions, название говорит само за себя)

Режим по умолчанию можно задать в settings.json:

{
  "permissions": {
    "defaultMode": "acceptEdits"
  }
}

Я использую acceptEdits в проектах, где доверяю Claude редактировать файлы, но хочу контролировать команды. Для CI/CD пайплайнов некоторые используют bypassPermissions, но я бы рекомендовал делать это только с глубоким пониманием.

Приоритет настроек

Если одно и то же правило задано в разных местах, работает приоритет:

  1. Managed settings (от администратора) — не перебить ничем
  2. Local settings (.claude/settings.local.json) — для тебя в этом проекте
  3. Project settings (.claude/settings.json) — для всей команды
  4. User settings (~/.claude/settings.json) — для тебя везде

Пример: если в проектном settings.json стоит deny на Bash(rm *), а в пользовательском allow — deny победит, потому что project settings приоритетнее user settings.

WebFetch — контроль HTTP-запросов

Отдельный тип правил для HTTP-запросов:

{
  "permissions": {
    "allow": [
      "WebFetch(domain:github.com)",
      "WebFetch(domain:stackoverflow.com)"
    ],
    "deny": [
      "WebFetch"
    ]
  }
}

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

Часто задаваемые вопросы

Как быстро настроить разрешения без ручного редактирования JSON? Команда /allowed-tools в Claude Code открывает интерактивный менеджер разрешений. Можно добавлять правила через UI, не трогая файлы.

Deny-правила блокируют и чтение через grep/glob? Да. Если файл в deny — Claude не увидит его ни через Read, ни через Grep, ни через Glob. Файл исчезает из результатов поиска полностью.

Можно ли разрешить bash-команду только для конкретного проекта? Да. Положи правило в .claude/settings.json в проекте — оно будет работать только там и не затронет другие проекты.

Sandbox замедляет работу? Почти незаметно. Накладные расходы минимальны. Основная проблема — некоторые команды не работают в sandbox (docker, git), их нужно явно исключать.

Что ещё почитать