Перейти к содержимому

Настроить ограничения

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

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

  1. Откройте Настройки → Рабочее пространство → Разрешения агента
  2. Выберите область сегментированным переключателем: Рабочее пространство, Агент (затем выберите агента) или Пространство (затем выберите пространство)
  3. В строке для класса действия выберите Разрешить, Спросить сначала или Запретить
  4. Чтобы удалить заданное вами правило, нажмите кнопку сброса, которая появляется в конце этой строки (Сбросить к унаследованному) — решение вернётся к более широкой области

Каждая строка показывает действующее решение в виде тега состояния и бейджа, указывающего, откуда оно пришло: Эта область, Унаследовано или Встроенное по умолчанию. Матрица разрешается в режиме «Агент» (chat), поэтому Пресет режима здесь никогда не появляется — чтобы увидеть этот слой, воспользуйтесь пробой «что если» с выбранным режимом только для чтения.

Для записи правила нужна роль admin. Для чтения матрицы — нет.

Контрольная точка: задайте для пункта Отправить в удалённый репозиторий значение Запретить на уровне рабочего пространства, затем запустите пробу «что если» ниже для git push origin main. Результат будет deny с источником workspace.

Решение определяется так: сначала специфичность, затем строгость:

  1. Сначала правила пространства, затем агента, затем рабочего пространства. Первая область с подходящим правилом решает, и на этом разрешение останавливается
  2. Если ни одно правило не подходит, применяется пресет режима — режим только для чтения (plan, review, orchestrate) отклоняет одиннадцать из тринадцати классов
  3. Если режиму нечего сказать, применяется встроенное по умолчанию

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

Решение Спросить сначала порождает один запрос на одобрение, охватывающий каждый класс, разрешившийся в prompt. Если одобряющий не подключён, оно отклоняется — и для команд оболочки, и для вызовов инструментов раннера. Это сделано намеренно: запуск без шлюза хуже, чем отклонённый.

Классы действий и встроенные значения по умолчанию

Заголовок раздела «Классы действий и встроенные значения по умолчанию»
Класс действия Встроенное по умолчанию
Удалить файл Спросить сначала
Писать вне рабочего дерева Разрешить
Создать коммит Разрешить
Отправить в удалённый репозиторий Спросить сначала
Открыть pull request Спросить сначала
Опубликовать ревью или слияние Спросить сначала
Писать во внешний трекер Спросить сначала
Обращаться к сети Разрешить
Читать секрет Разрешить
Установить пакет Разрешить
Запустить процесс Разрешить
Изменять структуру рабочего пространства Разрешить
Управлять enclosure (rig) Разрешить

Таксономия закрыта. Новый инструмент, выпущенный без объявления своих классов, проваливает тест-храповик в CI, поэтому ничто не приходит с молча пустым набором эффектов.

Проверить правило с помощью пробы «что если»

Заголовок раздела «Проверить правило с помощью пробы «что если»»

Прежде чем менять правило, проверьте, как текущая политика уже его разрешает.

  1. На той же странице прокрутите до Что если?
  2. Выберите Действие (один из тринадцати классов)
  3. При необходимости заполните Команду (например, git push origin main), Агента, Пространство и Режим
  4. Прочитайте результат: решение, причину и Источник:

Проба использует тот же механизм разрешения, что и путь принуждения, против ваших действующих правил, поэтому ответ точный. Если он вас удивит, измените правило в матрице выше и запустите пробу снова.

Настроить регулятор автономии пространства

Заголовок раздела «Настроить регулятор автономии пространства»

Регулятор задаётся для каждого агента в каждом пространстве и сочетается с правилами, а не заменяет их.

  1. Откройте пространство
  2. Откройте Управлять участниками из заголовка пространства
  3. В разделе Автономия в строке агента выберите уровень:
Уровень Эффект
По умолчанию Настройки пространства нет — ведёт себя как Действовать с одобрения
Только предлагать Каждый инструмент под шлюзом отклоняется сразу, с сообщением, предлагающим агенту вместо этого предложить действие
Действовать с одобрения Рискованные действия упираются в 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 её тоже нет — там ограничения плюс поверхность инструментов режима и есть всё принуждение, а не его вторая линия. Проверьте, какой у вас случай, с помощью страницы Настроить политики песочницы.