Настройка разрешений: Насколько свободно или строго, решать вам

📚 Навигация по серии: Предыдущая статья 19 Управление контекстом научила вас управлять "рабочим столом" Claude, чтобы не переполнять его память. В этой статье мы изменим перспективу — речь пойдет не о том, "сколько он помнит", а о том, "сколько ему позволено трогать": от запроса на каждую строку команды до полной свободы действий, насколько туго натянуты поводья разрешений, решать вам.

"Как ты посмел включить --dangerously-skip-permissions? Даже в названии сказано dangerous."

"Я в песочнице, чего бояться. Даже если он сделает rm -rf всему каталогу, удалится только одноразовый контейнер, можно создать новый."

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

Ранее в 7-й статье мы уже пробовали это однажды — Claude Code остановится и спросит вас, прежде чем изменять файл. Но это лишь верхушка айсберга. Сегодня мы раскроем весь айсберг целиком: какие режимы разрешений есть в Claude Code, как переключаться между ними в один клик и как использовать конфигурационные файлы для точного определения того, "что можно делать, а что абсолютно запрещено".

После прочтения этой статьи вы получите:

• Что представляет собой каждый из шести режимов разрешений и в каких сценариях их следует использовать, ясно показано в одной таблице
• Мышечная память переключения между режимами с помощью Shift+Tab, а также как напрямую указать режим при запуске
• Синтаксис написания правил allow / ask / deny в settings.json, точный контроль разрешений по инструментам и командам
• Два шаблона конфигурации: "расслабленный для проектов-игрушек, строгий для производственных проектов", готовые к копированию и использованию
• Когда на самом деле безопасно включать --dangerously-skip-permissions и где находится красная линия

---

01 Для начала разберемся: чем управляет система разрешений

Сразу к выводу: Claude Code по умолчанию — это стажер, который "сначала спрашивает, потом делает", а настройка разрешений — это "кодекс поведения", который вы устанавливаете для этого стажера.

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

Тип инструмента	Примеры	Требуется ли одобрение по умолчанию
Только чтение	Чтение файлов, поиск Grep	Нет, пропускается сразу
Команды Bash	Выполнение shell-команд	Да
Изменение файлов	Изменение файлов через Edit / Write	Да

Аналогия: спрашивает ли стажер вас перед тем, как что-то сделать. Надежный стажер, если попросить его "посмотреть этот код", просто посмотрит его (только чтение, нулевой риск); но если он хочет "изменить производственную конфигурацию" или "запустить команду удаления", он обычно сначала поднимает голову и спрашивает: "Босс, я могу это трогать?". Claude Code по умолчанию такой человек — читает что угодно, но перед тем, как действовать, отчитывается.

Здесь есть важное осознание, на котором я сам однажды споткнулся: разрешения принудительно обеспечиваются самой программой Claude Code, а не полагаются на "сознательность модели".

Тогда я специально написал в CLAUDE.md строку "не выполняй git push", думая, что это заблокирует действие, но в результате он все равно проворно сделал push, когда ему было нужно — потому что CLAUDE.md — это всего лишь "мягкая подсказка", которая "влияет на то, что он хочет сделать", а настоящие жесткие ограничения должны быть записаны в правилах разрешений. Позже я перенес это правило в deny, и только тогда он стал вести себя послушно. Официальная документация говорит очень прямо:

Правила разрешений принудительно применяются Claude Code, а не моделью. Ваши промпты или инструкции в CLAUDE.md будут влиять на то, что Claude пытается сделать, но они не изменят того, что разрешено делать Claude Code.

Запомните это правило, и тогда вы будете знать, где следует строить "линию обороны".

💡 Краткий итог: только чтение разрешено свободно, действия требуют одобрения — это правила по умолчанию; если вы действительно хотите заблокировать какую-то операцию, вам нужно написать правила разрешений, просто попросить об этом в CLAUDE.md не сработает.

---

02 Шесть режимов разрешений: от "спрашивать на каждом шагу" до "полной свободы"

Режим разрешений (permission mode) контролирует одно: "частоту", с которой Claude останавливается и спрашивает вас перед действием. От "останавливаться и ждать вашего кивка на каждом шагу" до "делать напрямую, ничего не спрашивая" — это непрерывный спектр.

Аналогия: снова этот стажер, режим — это "уровень автономии", который вы ему даете. В первый день на новой работе нужно спрашивать о каждом деле (default); после того, как освоился, можно менять код без спроса, но удалять базу данных все равно нужно звать вас (acceptEdits); вы уехали в командировку и полностью доверяете ему, позволяя действовать по своему усмотрению (bypassPermissions).

Официально предоставлено всего шесть режимов. Мы свели их в таблицу по критериям "что можно делать без спроса" и "подходящие сценарии" — это самая важная таблица для запоминания в этой статье:

Режим	Что можно делать без спроса	Будет ли он спрашивать вас сначала	Наиболее подходящий сценарий
default	Только чтение	При изменении файлов и запуске команд спрашивает всегда	Для новичков, деликатная работа
acceptEdits	Только чтение + редактирование файлов + обычные команды файловой системы (mkdir, mv, cp и т.д.)	При редактировании файлов и указанных командах не спрашивает, при других командах Bash по-прежнему спрашивает	Итерация кода, который вы проверяете
plan	Только чтение (только исследование, только планирование, не трогает ваш исходный код)	Те же правила подсказок, что и в default	Исследование и планирование перед внесением изменений
auto	Все операции, с проверкой безопасности фоновым классификатором	В основном не спрашивает, действия, выходящие за рамки, блокируются классификатором	Долгие задачи, уменьшение прерываний (preview-версия для исследований)
dontAsk	Только предварительно одобренные инструменты	Не спрашивает и не останавливается, неодобренные сразу отклоняет	Заблокированные CI, скрипты
bypassPermissions	Все операции, пропускает все проверки	Вообще не спрашивает	Только изолированные контейнеры / VM

Несколько моментов, которые новички путают чаще всего, давайте проясним их:

plan (Plan Mode, режим планирования) — это не "расслабление", а как раз самый сдержанный режим. Он позволяет Claude только читать файлы, только запускать команды только для чтения, чтобы прояснить ситуацию, а затем написать вам план "как я собираюсь это изменить", но он не тронет ни одной буквы в вашем исходном коде. Принимая любой незнакомый проект, на первом шаге рекомендуется сначала переключиться в plan и позволить ему прочитать все от начала до конца, это гораздо надежнее, чем позволять ему слепо вносить изменения с самого начала.

acceptEdits — это золотая середина для повседневной разработки. Он автоматически одобряет редактирование файлов в вашем рабочем каталоге и несколько распространенных команд файловой системы (mkdir, touch, rm, rmdir, mv, cp, sed), но останавливается и спрашивает вас перед другими командами shell и записями за пределами рабочего каталога. Это означает: "изменение кода не требует каждый раз нажатия кнопки согласия, но для опасных действий шлюз остается закрытым".

auto и bypassPermissions оба кажутся "не спрашивающими", но их безопасность различается кардинально. auto — это исследовательская предварительная версия, за которой стоит независимая модель-классификатор, проверяющая каждую операцию перед ее выполнением; действия, выходящие за рамки (например, curl | bash, пуш в main, удаление облачного хранилища), будут заблокированы; bypassPermissions — это истинный режим без защиты, он даже не защищает от внедрения промптов. В официальной документации сказано предельно ясно:

bypassPermissions не обеспечивает защиту от внедрения промптов или непреднамеренных действий. Для фоновых проверок безопасности без запросов используйте вместо этого auto mode.

Поэтому, если вы хотите "спокойствия, но с соблюдением границ", отдайте предпочтение auto, не включайте bypassPermissions сразу.

💡 Краткий итог: default спрашивает на каждом шагу, acceptEdits не спрашивает об изменении кода, plan только смотрит и не трогает, auto имеет классификатор для подстраховки, bypassPermissions полностью без защиты — просто запомните этот спектр от строгого к свободному и выбирайте подходящее место.

На этом изображении шесть режимов выстроены в спектр "от самого строгого к самому свободному": зеленая зона слева — это plan / default (только чтение, запрос на каждом шагу, самые безопасные), двигаясь вправо, мы проходим через acceptEdits (нет вопросов при изменении кода), auto (подстраховка классификатора), вплоть до красной зоны справа с bypassPermissions (полностью без защиты) — чем правее, тем краснее цвет, напоминая вам, что "чем свободнее, тем яснее вы должны понимать, где вы это используете".

---

03 Переключение режимов: циклическое переключение одной кнопкой Shift+Tab

Режимы мы знаем, как переключать? Самый используемый способ — это одно сочетание клавиш: Shift+Tab.

Простое нажатие Shift+Tab в сеансе будет циклически переключать три режима:

default → acceptEdits → plan → (нажмите снова, чтобы вернуться к default)

В каком режиме вы находитесь, можно узнать, посмотрев на строку состояния. Например, при переключении на acceptEdits в строке состояния отобразится ⏵⏵ accept edits on.

Обратите внимание на одну официальную деталь, чтобы не искать долго определенный режим: по умолчанию в цикле есть только эти три: default / acceptEdits / plan. Способы входа в остальные три отличаются: auto автоматически появится в цикле, когда аккаунт будет соответствовать условиям; bypassPermissions требует запуска с флагом типа --permission-mode bypassPermissions, чтобы войти в цикл; dontAsk никогда не появляется в цикле, его можно установить только через параметр запуска --permission-mode dontAsk (подробнее ниже).

Аналогия: трехпозиционное переключение "звонок / вибрация / без звука" на телефоне. Вы нажимаете на переключатель рядом с кнопками громкости, и он переключается между этими тремя режимами. Shift+Tab — это тот самый переключатель для Claude Code, один цикл — это "спрашивать каждый шаг / менять код без спроса / только смотреть, не трогать".

Если вы не хотите переключаться вручную при каждом входе, есть два способа "зафиксировать" режим:

Способ 1: Указать через параметр при запуске (действует только для текущего сеанса):

claude --permission-mode plan

Вы можете заменить plan на acceptEdits, dontAsk или любое другое название режима. bypassPermissions особенный — варианты --permission-mode bypassPermissions и --dangerously-skip-permissions эквивалентны, но в повседневной практике используется второй вариант, "название с предупреждением", о котором мы подробно поговорим в разделе 05.

Способ 2: Записать в settings.json как значение по умолчанию (действует при каждом запуске). В файле .claude/settings.json вашего проекта:

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

⚠️ Важное официальное ограничение: когда defaultMode установлено на "auto", настройки проекта и локальные настройки будут игнорироваться (чтобы предотвратить скрытое включение автоматического режима репозиторием), если вы хотите использовать auto по умолчанию, это нужно прописать в ~/.claude/settings.json на уровне пользователя.

Рекомендуемая привычка: не фиксировать режим в проекте жестко, полагаться на ручное переключение через Shift+Tab. Потому что в одном и том же проекте иногда вы хотите дать ему свободу действий (переключиться на acceptEdits), а иногда хотите, чтобы он только предложил план (переключиться на plan), жесткое кодирование только мешает. defaultMode обычно устанавливается на default для подстраховки, только когда "этот проект должен быть строго под контролем".

💡 Краткий итог: Shift+Tab в сеансе циклически переключает "спрашивать каждый шаг / менять код без спроса / только смотреть, не трогать", текущий режим виден в строке состояния; если хотите зафиксировать, используйте параметр запуска --permission-mode или defaultMode в settings.json.

---

04 Точный контроль разрешений: три правила allow / ask / deny

Режимы — это "грубая настройка", задающая основной тон. Настоящая "тонкая настройка", вплоть до точности "эту команду можно запускать, а эту абсолютно нельзя", опирается на три правила в settings.json.

Каждое правило в конечном итоге сводится к одному из трех действий:

Действие	Эффект	Типичное использование
allow	Не требует одобрения, пропускает автоматически	Высокочастотные операции с низким уровнем риска, такие как git status, npm run build
ask	Показывает подсказку, решение за вами	Есть некоторый риск, хочется оставить подтверждение, например git push
deny	Блокирует напрямую, не выполняет и не спрашивает	Явно запрещенные опасные операции, такие как rm -rf, чтение .env

Приоритет — это железное правило: deny → ask → allow, побеждает первое совпавшее правило. Поэтому deny всегда подавляет остальные два — если вы написали и allow, и deny, слово за deny. Такой дизайн очень разумен: "запрет" должен иметь больший вес, чем "разрешение".

Синтаксис правил — это ИмяИнструмента или ИмяИнструмента(спецификатор). Посмотрите на несколько примеров, и вы все поймете:

Правило	Что сопоставляется
Bash	Все команды Bash
Bash(npm run build)	Сопоставляется только с этой точной командой npm run build
Bash(npm run *)	Сопоставляется с командами, начинающимися с npm run (build, test…)
Read(./.env)	Чтение файла .env в текущем каталоге
WebFetch(domain:github.com)	Сетевые запросы к github.com

У подстановочного знака * есть ловушка с пробелами, в которую обязательно попадают новички, официально это специально подчеркнуто:

Bash(ls *) сопоставляется с ls -la, но не сопоставляется с lsof, в то время как Bash(ls*) сопоставляется с обоими.

Разница в один пробел меняет смысл. ls * (с пробелом) требует, чтобы после ls обязательно был пробел, поэтому lsof проскальзывает через сеть; ls* (без пробела) сопоставляется и с lsof. Хотите быть точными — используйте пробел.

Полная конфигурация выглядит так — разрешить npm и git commit, но заблокировать git push:

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)"
    ],
    "deny": [
      "Bash(git push *)"
    ]
  }
}

Последний пункт безопасности нужно обязательно выделить: правила deny для Read / Edit не могут заблокировать "обходное чтение/запись" в дочерних процессах Bash.

Что это значит? Вы написали deny: Read(./.env), чтобы заблокировать прямой доступ Claude к .env, но если он запустит Python-скрипт open('.env').read(), этот deny не сможет его проконтролировать — потому что это дочерний процесс читает файл, в обход встроенного инструмента Claude для работы с файлами. Официальное предупреждение:

Они не применяются к произвольным дочерним процессам, косвенно читающим или записывающим файлы, таким как скрипты Python или Node, открывающие файлы самостоятельно. Чтобы получить принудительное ограничение на уровне ОС, блокирующее доступ всех процессов к путям, включите песочницу.

Это легко может стать сюрпризом — вы можете подумать, что deny .env на 100% надежен. Поэтому, если вы действительно хотите надежно заблокировать конфиденциальные файлы, правила разрешений + песочница вместе — вот что называется глубокой защитой (песочница — это изоляция на уровне ОС, в следующей статье "Безопасность" это будет рассмотрено подробнее).

💡 Краткий итог: сопоставление идет в порядке deny → ask → allow, deny всегда главный; наличие или отсутствие пробела в правиле меняет смысл; но deny не блокирует обходное чтение/запись скриптами, для конфиденциальных файлов нужна песочница.

---

05 Расслабление для игрушек, строгость для производства: два шаблона + красная линия "опасного режима"

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

Здесь приведены два набора стандартных конфигураций, выбирайте в зависимости от характера проекта.

Шаблон 1: Игрушки / Небольшие личные проекты (расслабление для скорости). Если что-то пойдет не так, можно просто пересоздать, нет необходимости останавливаться на каждом шагу. Установите acceptEdits, чтобы он не спрашивал о каждом изменении кода, перехватывая только несколько действительно опасных вещей:

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push *)"
    ]
  }
}

Шаблон 2: Производство / Проекты компании (строгий контроль). По умолчанию спрашивать на каждом шагу, разрешить операции чтения для удобства проверки кода, изменение файлов и опасные команды должны проходить через вас, конфиденциальные файлы блокируются напрямую:

{
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Bash(git status *)",
      "Bash(git diff *)",
      "Bash(npm run *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push *)",
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ]
  }
}

Когда вы пишете эти два правила deny, помните: как мы говорили в предыдущем разделе, deny, блокирующий .env, не защищает от обходных путей через скрипты; если вы хотите настоящей стабильности в производственной среде, поверх этого уровня нужно добавить песочницу. Не принимайте одноуровневый deny за железную стену.

Наконец, та самая красная линия, которая была главным героем диалога в начале — --dangerously-skip-permissions (эквивалентно режиму bypassPermissions).

Эта штука пропускает все проверки разрешений и проверки безопасности, вызовы инструментов выполняются немедленно. Слово dangerously (опасно) в названии — это не запугивание. Официальная документация очерчивает границы его использования:

Используйте этот режим только в изолированных средах (таких как контейнеры, VM или dev containers без доступа к интернету), где Claude Code не может нанести вред вашей хост-системе.

Следующее железное правило можно перенять напрямую:

Сценарий	Можно ли включить --dangerously-skip-permissions
Изолированный контейнер / VM / dev container	✅ Да, даже если удалится, это одноразовая среда
Запуск одноразовых задач в CI	✅ Да, но добавьте deny для подстраховки
Локальная машина для повседневной разработки	❌ Не включать, лучше медленнее, но оставить шлюз закрытым
Машина с производственным кодом компании	❌ Абсолютно не включать, это бомба

Две официально разработанные "страховки" позволяют вам немного успокоиться: во-первых, даже в этом режиме операции вроде rm -rf / и rm -rf ~, удаляющие корневой/домашний каталог, все равно вызовут запрос, работая как автоматический выключатель от случайных ошибок; во-вторых, в Linux / macOS запуск этого режима с правами root или через sudo напрямую блокируется. Но не полагайтесь на страховки — суть в том, чтобы "включать только в изолированных средах, которые не жалко удалить".

💡 Краткий итог: используйте acceptEdits для ускорения в проектах-игрушках, default для контроля в производственных проектах, оба шаблона готовы к копированию; --dangerously-skip-permissions включать только в изолированных контейнерах, на локальных и производственных машинах это исключено.

---

06 Практика: настройте свой первый набор правил разрешений за 5 минут

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

Шаг 1: Создайте проект-игрушку и конфигурационный файл (Mac / Linux)

mkdir perm-demo
cd perm-demo
mkdir .claude

Ожидаемый результат: В папке perm-demo есть пустой каталог .claude. Набрав ls -a, вы увидите, что .claude присутствует.

Шаг 2: Напишите файл settings.json

Используя свой любимый редактор, вставьте следующее в perm-demo/.claude/settings.json:

{
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Bash(git status *)"
    ],
    "deny": [
      "Bash(git push *)"
    ]
  }
}

Смысл этих правил: по умолчанию спрашивать на каждом шагу, но git status пропускать без вопросов, а git push блокировать напрямую.

Шаг 3: Запустите Claude и проверьте правила

claude

Зайдя внутрь, введите:

/permissions

Ожидаемый результат: Появится интерфейс управления разрешениями, где вы сможете увидеть только что написанные правила — git status * в списке Allow, git push * в списке Deny, и будет отмечено, из какого файла settings.json они взяты. Увидеть эти две записи = конфигурация загружена правильно.

Шаг 4: Убедитесь, что deny действительно блокирует

Попросите его сделать запрещенную вещь в поле ввода:

Помоги мне выполнить git push origin main

Ожидаемый результат: Claude не выполнит это и не покажет подсказку "нужно ли одобрить" — он прямо скажет вам, что эта операция была отклонена правилами разрешений. В этом и заключается сила deny: не выполняет, не спрашивает, блокирует полностью.

Шаг 5: Сравните с гладкостью работы allow

Теперь попросите его сделать разрешенную вещь:

Помоги мне посмотреть git status

Ожидаемый результат: Поскольку это подпадает под allow: Bash(git status *), он не покажет запрос на одобрение, а выполнит напрямую (в этом каталоге еще не было git init, поэтому сама команда выдаст "not a git repository", но это дело git — главное, что он не остановился, чтобы спросить вас, что означает, что allow сработало).

Пройдя эти пять шагов, вы собственноручно проверили всю цепочку "написание правил → загрузка → полная блокировка через deny → пропуск через allow". В будущем любые настройки разрешений по сути будут добавлением правил поверх этого механизма.

💡 Краткий итог: создайте .claude/settings.json, напишите правила, посмотрите через /permissions, загружены ли они, затем попросите Claude выполнить одну запрещенную и одну разрешенную команду — сделать это самому полезнее, чем запомнить десять правил синтаксиса.

---

07 Резюме

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

Давайте вспомним ключевые моменты:

Что вам нужно сделать	Что использовать	Ключевой момент
Настроить "частоту запросов к вам"	Шесть режимов разрешений	Спектр от default (спрашивать каждый шаг) до bypassPermissions (без защиты)
Быстро переключать режимы в сеансе	Shift+Tab	Циклическое переключение между default / acceptEdits / plan
Зафиксировать режим по умолчанию	defaultMode	Записать в settings.json; auto нужно ставить на уровне пользователя
Точный контроль отдельных операций	allow / ask / deny	Приоритет deny → ask → allow, deny — главный
Блокировка конфиденциальных файлов	deny + песочница	Один deny не защитит от обхода через скрипты

Теперь вы должны уметь: Понимать, в каких сценариях используются каждый из шести режимов разрешений, свободно переключаться с помощью Shift+Tab, писать правила allow / deny для инструментов и команд в settings.json, настраивать соответствующие разрешения для проектов-игрушек и производственных проектов, и четко осознавать, что красную линию --dangerously-skip-permissions можно трогать только в изолированных средах. Эта способность "свободно контролировать разрешения" даст вам уверенность в том, что вы можете позволить Claude работать, не опасаясь катастрофы.

---

Следующая статья 21 "Безопасность и границы рисков" — эта статья научила вас "как настраивать разрешения", но конфигурация — это всего лишь инструмент, проблема более высокого уровня: действительно ли стоит доверять ИИ трогать ваш код и систему? Какие сценарии являются действительно зонами высокого риска? Как выглядят ловушки с внедрением промптов и утечкой конфиденциальных данных? Поводья у вас в руках, в следующей статье мы поговорим о том, как оценивать, "когда их следует натянуть, а когда отпустить".

---

Рекомендуемое чтение

• Руководство по использованию CLAUDE.md: Запишите правила проекта в его память
• Устранение распространенных проблем (FAQ / Troubleshooting)
• Agent Skills: Экипируйте Claude специальными навыками по вызову