6 апреля 2026 · Редакция

Как «запереть» Claude Code: пять паттернов разрешений для файлов, Bash, MCP и git

Агентная CLI вроде Claude Code опирается на цепочку разрешений: какие файлы читать, какие команды выполнять, какие MCP-инструменты вызывать. В статье на dev.to автор разбирает пять практических паттернов, которые помогают сузить поверхность атаки и убрать типичные «дыры», когда одобрения накапливаются автоматически. Ниже — краткий пересказ оригинала с сохранением исходных технических формулировок. Пост вышел 6 апреля 2026 года; на странице указана ориентировочная длительность чтения около 6 минут.

Зачем вообще пересобирать политику доступа у coding-агента

Автор приводит мотивирующий пример: в settings.json были запрещены чтения .env, но агент всё равно получил к содержимому. Дальше текст объясняет, что у Claude Code многоуровневая система разрешений, которую часто не доводят до конца после ответов в духе «Yes, don't ask again». В результате появляются «невидимые пробелы»: команды с автоматическим одобрением попадают в настройки проекта, а инструменты без явной политики работают с максимально широким доступом.

Итог для практики: ограничить намерения агента в интерфейсе недостаточно, если те же действия доступны через другой канал (например, Bash) или если правила не согласованы между уровнями конфигурации.

Паттерн 1: deny-first в `settings.json`

Первый паттерн — Deny-First Rules в файле настроек. Правила оцениваются в порядке: сначала все deny, затем ask, затем allow; запрет имеет приоритет над разрешением независимо от порядка записей в JSON и от того, в каком файле настроек они лежат. В статье предлагается хранить конфигурацию в .claude/settings.json в корне репозитория.

В примере стартового набора правил фигурируют запреты на чтение секретов (в том числе .env), сетевые вызовы через curl/wget, разрушительные команды вроде git push --force и rm -rf, плюс точечные разрешения на отдельные build/test-команды.

Отдельно подчёркивается нюанс: deny для встроенного инструмента Read не блокирует чтение через cat .env в Bash. Для полной защиты нужны ограничения и на Bash, и/или песочница (см. паттерн 4).

# Логика приоритета (по описанию автора):
# 1) все deny → 2) ask → 3) allow; deny побеждает allow

Паттерн 2: иерархия настроек и запрет «обойти запрет снизу»

Второй паттерн назван The 4-Layer Settings Hierarchy; в подзаголовке указано «4-layer», при этом в теле перечислены пять уровней приоритета — именно так изложено у автора:

managed settings
аргументы CLI: --allowedTools / --disallowedTools
.claude/settings.local.json (в gitignore)
.claude/settings.json (общий для проекта)
~/.claude/settings.json (пользовательский)

Утверждается: если инструмент запрещён на любом из уровней, более низкий уровень не может это разрешить.

Паттерн 3: MCP-серверы и субагенты

Третий блок — MCP Server and Subagent Controls. Для MCP в статье описан формат правил вида mcp__<имя_сервера>__<имя_инструмента>, с примерами вроде mcp__filesystem__read_file и mcp__github__merge_pull_request. Для субагентов используются правила Agent(имя) (в тексте встречаются примеры Agent(Explore) и Agent(Plan)).

По формулировке автора, без явных правил MCP-инструменты после однократного «allow» получают широкое автоодобрение, а субагенты — неограниченный доступ — то есть для агента в терминале это отдельный класс риска, который стоит закрывать явной политикой, а не надеждой на умолчания.

Паттерн 4: песочница как граница ОС

Четвёртый паттерн — Sandbox for OS-Level Enforcement. В конфиге задаётся блок sandbox с полями enabled, ограничениями filesystem и network.allowedDomains. Идея: правила разрешений ограничивают намерения модели, а операционная система — что может процесс. При включённой песочнице, по словам автора, вызов вроде cat .env может блокироваться уже на уровне ОС.

Упоминаются autoAllowBashIfSandboxed: true (поведение по умолчанию при включённой песочнице) и совместное использование с deny-правилами как defense in depth. В чеклисте в конце статьи песочница рекомендуется включать, если вы на macOS или Linux — прямая формулировка источника.

Паттерн 5: режимы разрешений под разные workflow

Пятый паттерн — Permission Modes for Different Workflows. Перечислены режимы: default, acceptEdits, plan, dontAsk, auto (в тексте указано, что auto находится в research preview), bypassPermissions. Описана настройка disableBypassPermissionsMode со значением "disable", чтобы запретить bypass-режим.

В том же материале упоминаются CI и сценарии с контейнерами и виртуальными машинами в контексте bypassPermissions — без привязки к конкретным версиям продукта в просмотренном тексте.

Что вынести в свою практику

Пять паттернов складываются в один смысл: для CLI-агента с MCP и Bash нужна согласованная политика — deny-first, иерархия файлов настроек, явные правила для MCP и субагентов, песочница там, где это поддерживается ОС, и осознанный выбор режимов, включая отключение обхода ограничений.

Полный разбор с примерами конфигурации — в оригинале на dev.to у пользователя klement_gunndu (см. список источников). Отдельного юридического дисклеймера в тексте публикации нет; корпоративные политики и условия использования инструментов стоит сверять со своими требованиями отдельно.

Источники

klement_gunndu. Lock Down Claude Code With 5 Permission Patterns — dev.to: https://dev.to/klement_gunndu/lock-down-claude-code-with-5-permission-patterns-4gcn — дата доступа (UTC): 2026-04-06T21:04:16Z.