Claude Code permissions задают, какие инструменты агенту запрещены, какие требуют согласия и какие разрешены по правилам команды. Общую политику удобно описать в .claude/settings.json, затем проверить её на безопасных пробных файлах с учётом режима сессии и управляемых настроек. Для доступа к рабочим системам остаются отдельные серверные права: промпт лишь описывает желаемое поведение.
Порядок разрешений
Claude Code проверяет совпавшие правила в порядке deny, затем ask, затем allow. Запрет имеет приоритет даже при более узком разрешающем правиле; настройки применяет приложение Claude Code. Языковая модель получает результат проверки.
Если команда уже пользуется Claude Code, общий договор «агенту доступны только согласованные действия» полезно превратить в проверяемые правила. Официальная документация Claude Code описывает правила для инструментов и путей, а также порядок их оценки. Deny блокирует совпавший вызов. Ask показывает запрос на подтверждение. Allow снимает обычный запрос для разрешённого действия. Совпадение с deny останавливает вызов до обсуждения остальных правил. Широкий запрет сохраняет силу даже при узком allow.
| Правило | Смысл для команды | Проверка |
|---|---|---|
| deny | Действие закрыто политикой | Попытка получает отказ |
| ask | Человек решает по конкретному вызову | Хост запрашивает согласие |
| allow | Действие допускается правилом | Вызов проходит без обычного запроса |
| permission mode | Общее поведение сессии | Сравнение при тех же правилах |
В статье о Claude Code для команды описан общий порядок совместной работы. Здесь вопрос уже: какой именно вызов Read, Edit или Bash должен получить отказ, запрос либо разрешение. Это важнее абстрактной фразы «работать осторожно». Промпт и файл CLAUDE.md могут подсказывать агенту желаемый процесс, но контроль вызова находится в системе разрешений. После изменения политики проверяйте фактическую попытку инструмента. Ответ модели о намерениях служит лишь пояснением.
Политика репозитория
Общие правила проекта помещают в .claude/settings.json и обсуждают как изменение репозитория. Локальные предпочтения разработчика живут отдельно, а управляемые настройки администраторов задают верхний уровень организационной политики. Согласно документации, запрет из любого уровня побеждает разрешение другого уровня. Управляемое правило нельзя снять параметром запуска. Перед доверием к репозиторию Claude Code показывает проектные правила, которые расширяют доступ; команда должна просмотреть их так же внимательно, как код.
- В permissions.deny запишите Read(./fixtures/private/**) для синтетической закрытой папки и Edit(./fixtures/protected/**) для тестовой защищённой области.
- В permissions.ask задайте Bash(npm run build), если команда хочет отдельно подтверждать запуск сборки в учебном сценарии.
- В permissions.allow приведите узкий пример Bash(npm run lint) после ревью содержимого сценария; широкий шаблон для Bash открыл бы лишние команды.
- Рядом с правилами опишите владельца политики и причину каждого ограничения обычным текстом для ревью.
Пути в правилах Read и Edit зависят от источника настройки и текущего каталога. Для проекта проверьте разрешение относительных путей по официальному описанию, особенно если разработчики открывают разные рабочие папки. Синтетические fixtures в примере нужны только для проверки механизма; реальные файлы с секретами в тестовый набор исключите. Образец настройки нельзя копировать без сверки с фактической структурой репозитория и списком доступных инструментов.
Правила пути защищают вызовы, которые Claude Code умеет распознавать. Для произвольного скрипта, читающего файлы косвенно, документация отмечает отдельную границу такого контроля. Поэтому чувствительные каталоги защищают также средствами ОС и песочницы, а доступ к внешним сервисам ограничивают на сервере. Страница о безопасности ИИ-агентов подробнее раскрывает этот общий слой.
Пробный вызов
Будущий пилот можно построить на временном учебном репозитории без рабочих секретов и клиентских данных. Цель проверки — увидеть реальное решение Claude Code по каждой попытке. Подготовьте открытый файл для чтения, закрытый учебный путь, разрешённый файл для правки и защищённую область. Зафиксируйте текст правил и выбранный permission mode до испытания, чтобы повторный результат был сопоставимым.
- Попросите агента прочитать учебный файл из fixtures/private. Ожидаемый исход для совпавшего Read deny — отказ инструмента; сохраните сообщение без содержимого файла.
- Попросите изменить учебный файл в fixtures/protected. Ожидайте блокировку Edit и проверьте, что содержимое осталось прежним.
- Запросите запуск разрешённого действия и отдельно действия с ask. Отметьте, где вызов прошёл, а где появился диалог согласия.
- Измените узкое правило в проектной настройке и повторите те же попытки. Сравните фактические решения, затем верните учебную политику к согласованному варианту.
Если проверка дала спорный исход, сначала установите, какой инструмент реально вызван и какой путь попал в его аргументы. Затем посмотрите правила других уровней и режим сессии. Узкий тест на синтетических файлах выявляет ошибку записи шаблона без доступа к производственным данным. Для полного вывода событий используйте скрипт или парсер, ИИ поручите объяснение расхождений; инженер сверит гипотезу с исходным журналом и правилами.
Для команды полезно сохранять в ревью новый JSON и таблицу ожидаемых исходов: чтение закрытой папки, запись в защищённую область, подтверждаемый вызов и обычное разрешённое действие. Эта таблица станет критерием следующего изменения политики.
Режим сессии
Permission mode отвечает за широкое поведение сессии, тогда как deny, ask и allow относятся к совпавшим вызовам. В документации Claude Code режим default описан как запрос согласия для действий, требующих разрешения; plan предназначен для исследования без правок исходных файлов. Режим acceptEdits автоматически принимает правки файлов в рабочей области, поэтому его применение команда обсуждает отдельно. Начальный режим можно задать через defaultMode в настройках. Политика конкретных запретов сохраняет значение и при смене режима.
Испытайте одну и ту же учебную попытку с тем же набором правил в согласованных режимах. Если ожидание команды расходится с фактом, обновите формулировку политики или выберите иной стартовый режим. Управляемые настройки могут ограничивать доступные режимы; администраторский запрет сохраняет силу поверх проектной настройки. Документация также разделяет разрешения Claude Code и песочницу ОС: последняя ограничивает файловый и сетевой доступ запускаемых процессов. Это разные слои защиты с разными точками проверки.
В рабочем репозитории изменение режима должно быть видно владельцу процесса. Зафиксируйте допустимый стартовый режим, перечень действий с ask и список путей с deny. Сравнение ведите по результату реального вызова инструмента, включая отказ или диалог. Ответ агента в чате помогает объяснить результат.
Такое описание даёт команде предметный разговор: какие операции агент может выполнить сам, а где нужен человек. Для интеграций с базой задач или системой публикации отдельный сервер сверяет учётную запись, роль и подтверждение записи. Право в этой системе выдаёт её сервер по собственной политике.
Хотите проверить правила Claude Code для вашего репозитория?
Приёмка политики
Предложенный пилот завершается после проверки ожидаемых отказов, запросов и разрешений на учебных действиях. Критерием служит воспроизводимое решение при одинаковом пути, инструменте, режиме и наборе настроек. Дополнительно проверьте, что защищённая область остаётся закрытой при смене рабочего каталога или локальных предпочтений разработчика. Если правило слишком широкое, исправьте шаблон и повторите тест. Отчёт описывает поведение политики на учебных действиях. Внедрение пока остаётся планом.
- Сохраните версию .claude/settings.json и отдельную таблицу ожидаемых исходов без секретных путей.
- Проверьте deny перед ask и allow на перекрывающихся учебных правилах, чтобы увидеть приоритет.
- Сверьте управляемые ограничения с настройкой проекта и запишите владельца каждого уровня.
- Проверьте серверное подтверждение для внешнего действия на тестовом объекте без реальной отправки или публикации.
Плагины и подключённые инструменты добавляют собственные точки доступа, поэтому их проверяют отдельным перечнем после базовой политики репозитория. Эта статья ограничена разрешениями Claude Code и тестом чтения и записи. Профильный администратор утверждает управляемые ограничения, разработчик проверяет правило в своей рабочей области, владелец внешней системы отвечает за серверную авторизацию. Эти решения принимают люди и серверные средства контроля.
Стоимость настройки командной политики зависит от числа репозиториев, набора инструментов, управляемых настроек и объёма проверки. Обсудить состав аудита можно на консультации по доступу ИИ-инструментов. Для разговора подготовьте обезличенный список разрешённых действий, описание рабочих ролей и результаты тестов на синтетических файлах. Реальные секреты остаются вне оценки.