Настроить ограничения
В этом руководстве показано, как настроить ограничения: правила, которые решают, выполняется действие агента, сначала запрашивает одобрение или отклоняется.
Ограничения охватывают тринадцать классов эффектов, которые объявляет каждый изменяющий инструмент. Они применяются на стороне сервера в момент вызова инструмента, а не инструкцией в промпте.
Задать решение для класса действия
Заголовок раздела «Задать решение для класса действия»- Откройте Настройки → Рабочее пространство → Разрешения агента
- Выберите область сегментированным переключателем: Рабочее пространство, Агент (затем выберите агента) или Пространство (затем выберите пространство)
- В строке для класса действия выберите Разрешить, Спросить сначала или Запретить
- Чтобы удалить заданное вами правило, нажмите кнопку сброса, которая появляется в конце этой строки (Сбросить к унаследованному) — решение вернётся к более широкой области
Каждая строка показывает действующее решение в виде тега состояния и бейджа,
указывающего, откуда оно пришло: Эта область, Унаследовано или
Встроенное по умолчанию. Матрица разрешается в режиме «Агент» (chat),
поэтому Пресет режима здесь никогда не появляется — чтобы увидеть этот слой,
воспользуйтесь пробой «что если» с выбранным режимом только для чтения.
Для записи правила нужна роль admin. Для чтения матрицы — нет.
Контрольная точка: задайте для пункта Отправить в удалённый репозиторий
значение Запретить на уровне рабочего пространства, затем запустите пробу
«что если» ниже для git push origin main. Результат будет deny с источником
workspace.
Как определяется решение
Заголовок раздела «Как определяется решение»Решение определяется так: сначала специфичность, затем строгость:
- Сначала правила пространства, затем агента, затем рабочего пространства. Первая область с подходящим правилом решает, и на этом разрешение останавливается
- Если ни одно правило не подходит, применяется пресет режима — режим только для чтения (plan, review, orchestrate) отклоняет одиннадцать из тринадцати классов
- Если режиму нечего сказать, применяется встроенное по умолчанию
В пределах одной области правило для команды разрешается по самому длинному совпадающему префиксу, а конфликт с одинаковой специфичностью разрешается в пользу самого строгого — запретить важнее, чем спросить сначала, а спросить сначала важнее, чем разрешить. Действие, которое объявляет несколько классов, разрешает каждый из них независимо, а затем объединяет их по самому строгому.
Решение Спросить сначала порождает один запрос на одобрение, охватывающий
каждый класс, разрешившийся в prompt. Если одобряющий не подключён, оно
отклоняется — и для команд оболочки, и для вызовов инструментов раннера. Это
сделано намеренно: запуск без шлюза хуже, чем отклонённый.
Классы действий и встроенные значения по умолчанию
Заголовок раздела «Классы действий и встроенные значения по умолчанию»| Класс действия | Встроенное по умолчанию |
|---|---|
| Удалить файл | Спросить сначала |
| Писать вне рабочего дерева | Разрешить |
| Создать коммит | Разрешить |
| Отправить в удалённый репозиторий | Спросить сначала |
| Открыть pull request | Спросить сначала |
| Опубликовать ревью или слияние | Спросить сначала |
| Писать во внешний трекер | Спросить сначала |
| Обращаться к сети | Разрешить |
| Читать секрет | Разрешить |
| Установить пакет | Разрешить |
| Запустить процесс | Разрешить |
| Изменять структуру рабочего пространства | Разрешить |
| Управлять enclosure (rig) | Разрешить |
Таксономия закрыта. Новый инструмент, выпущенный без объявления своих классов, проваливает тест-храповик в CI, поэтому ничто не приходит с молча пустым набором эффектов.
Проверить правило с помощью пробы «что если»
Заголовок раздела «Проверить правило с помощью пробы «что если»»Прежде чем менять правило, проверьте, как текущая политика уже его разрешает.
- На той же странице прокрутите до Что если?
- Выберите Действие (один из тринадцати классов)
- При необходимости заполните Команду (например,
git push origin main), Агента, Пространство и Режим - Прочитайте результат: решение, причину и Источник:
Проба использует тот же механизм разрешения, что и путь принуждения, против ваших действующих правил, поэтому ответ точный. Если он вас удивит, измените правило в матрице выше и запустите пробу снова.
Настроить регулятор автономии пространства
Заголовок раздела «Настроить регулятор автономии пространства»Регулятор задаётся для каждого агента в каждом пространстве и сочетается с правилами, а не заменяет их.
- Откройте пространство
- Откройте Управлять участниками из заголовка пространства
- В разделе Автономия в строке агента выберите уровень:
| Уровень | Эффект |
|---|---|
| По умолчанию | Настройки пространства нет — ведёт себя как Действовать с одобрения |
| Только предлагать | Каждый инструмент под шлюзом отклоняется сразу, с сообщением, предлагающим агенту вместо этого предложить действие |
| Действовать с одобрения | Рискованные действия упираются в fail-closed-шлюз одобрения |
| Действовать свободно | Заранее одобряет всё, что не разрешилось в жёсткий запрет |
Регулятор дотягивается только до встроенного раннера. Адаптер Claude Code запускает свои инструменты в обход этого шлюза.
Знать, куда ограничения не дотягиваются
Заголовок раздела «Знать, куда ограничения не дотягиваются»Таблица Где применяются правила внизу той же страницы — это версия того же самого внутри приложения: для каждого класса эффекта она говорит, перехватывает ли его каждый исполнитель на шлюзе политики, оставляет ли его песочнице или не может перехватить вовсе.
- Адаптер Claude Code проходит через шлюз лишь для части своих вызовов
инструментов. Claude Code запускается с
--dangerously-skip-permissions, поэтому его вызовы чтения, записи и редактирования никогда не проходят через ограничения. Его команды bash доходят до них через хук, который классифицирует командную строку, а его push, как и у любого агента, проходит через шлюз push. Через шлюз также проходят поверхность инструментов MCP, в которую он вызывает обратно, и команда оболочки, которую Control Center порождает для его запуска. - Собственный выходной глагол режима (
submit_plan,propose_orchestration) закреплён и никогда не может быть запрещён — иначе режим был бы структурно неспособен выдать свой единственный результат. - Подкрепляет ли эти правила песочница, зависит от хоста. Там, где
cc_serverнаходит бэкенд, он оборачивает CLI Claude Code и инструментbashраннера, поэтому у правила, которое вы не писали, всё равно есть основа на уровне ОС. В Windows её нет, и в Linux или WSL2 безbwrapиsocatеё тоже нет — там ограничения плюс поверхность инструментов режима и есть всё принуждение, а не его вторая линия. Проверьте, какой у вас случай, с помощью страницы Настроить политики песочницы.