Налаштувати обмеження

Цей посібник показує, як налаштувати обмеження: правила, що вирішують, чи дія агента виконається, чи спершу попросить затвердження, чи буде відхилена.

Обмеження охоплюють тринадцять класів ефектів, які оголошує кожен інструмент, що змінює стан. Вони застосовуються на сервері в момент виклику інструмента, а не інструкцією в промпті.

Задати рішення для класу дій

Перейдіть у Налаштування → Робочий простір → Дозволи агента
Виберіть область сегментованим перемикачем: Робочий простір, Агент (тоді виберіть агента) або Простір (тоді виберіть простір)
У рядку класу дій виберіть Дозволити, Спочатку запитати або Заборонити
Щоб прибрати задане правило, натисніть кнопку скидання, що з’являється в кінці цього рядка (Скинути до успадкованого) — рішення повернеться до ширшої області

Кожен рядок показує чинне рішення як статусну позначку та бейдж із зазначенням, звідки воно походить: Ця область, Успадковано або Вбудований стандарт. Матриця розв’язується в режимі Agent (chat), тож Пресет режиму тут ніколи не з’являється — скористайтеся зондом «що якщо» з вибраним режимом лише для читання, щоб побачити цей рівень.

Щоб записати правило, потрібна роль admin. Щоб читати матрицю — ні.

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

Зрозуміти, як розв’язується рішення

Розв’язання відбувається спершу за конкретністю, потім за суворістю:

Спершу правила простору, потім агента, потім робочого простору. Вирішує перша область із відповідним правилом, і на ній розв’язання зупиняється
Якщо жодне правило не збігається, застосовується пресет режиму — режим лише для читання (plan, review, orchestrate) відхиляє одинадцять із тринадцяти класів
Якщо режим нічого не каже, застосовується вбудований стандарт

У межах однієї області правило команди розв’язується за найдовшим відповідним префіксом, а однаково конкретний конфлікт розв’язується найсуворіше — заборона перемагає запит, а запит перемагає дозвіл. Дія, що оголошує кілька класів, розв’язує кожен із них незалежно, а тоді поєднує їх найсуворіше.

Рішення Спочатку запитати показує один запит на затвердження, що охоплює кожен клас, який розв’язався як prompt. Без під’єднаного затверджувача його відхиляють — і для shell-команд, і для викликів інструментів harness. Це навмисно: запуск без шлюзу гірший за відхилений.

Класи дій і вбудовані стандарти

Клас дій	Вбудований стандарт
Видалити файл	Спочатку запитати
Запис поза робочим деревом	Дозволити
Створити коміт	Дозволити
Надіслати на віддалений репозиторій	Спочатку запитати
Відкрити pull request	Спочатку запитати
Опублікувати рецензію або злити	Спочатку запитати
Запис у зовнішній трекер	Спочатку запитати
Доступ до мережі	Дозволити
Читати секрет	Дозволити
Установити пакет	Дозволити
Запустити процес	Дозволити
Змінити структуру робочого простору	Дозволити
Керувати ізольованим середовищем (rig)	Дозволити

Таксономія закрита. Новий інструмент, що виходить без оголошення своїх класів, не проходить тест храповика в CI, тож ніщо не приходить із тихо порожнім набором ефектів.

Перевірити правило зондом «що якщо»

Перш ніж змінювати правило, перевірте, як поточна політика вже його розв’язує.

На тій самій сторінці прокрутіть до Що якщо?
Виберіть Дію (один із тринадцяти класів)
За потреби заповніть Команду (наприклад, git push origin main), Агента, Простір і Режим
Прочитайте результат: рішення, причину та Джерело:

Зонд запускає той самий розв’язувач, який використовує шлях примусу, проти ваших поточних правил, тож відповідь точна. Якщо вона вас здивує, змініть правило в матриці вище й перевірте знову.

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

Регулятор діє для кожного агента в кожному просторі й поєднується з правилами, а не замінює їх.

Відкрийте простір
Відкрийте Керувати учасниками із заголовка простору
У розділі Автономність у рядку агента виберіть рівень:

Рівень	Ефект
Типовий	Немає налаштування простору — поводиться як Діяти з підтвердженням
Лише пропонувати	Кожен інструмент під шлюзом відхиляється напряму, з повідомленням, що каже агенту натомість запропонувати дію
Діяти з підтвердженням	Ризиковані дії потрапляють на шлюз затвердження з відмовою за замовчуванням
Діяти вільно	Заздалегідь затверджує все, що не розв’язалося як тверда заборона

Регулятор сягає лише вбудованого harness. Адаптер Claude Code виконує власні інструменти поза цим шлюзом.

Знати, куди обмеження не сягають

Таблиця Де застосовуються правила внизу тієї самої сторінки — це версія цього в застосунку: для кожного класу ефектів вона каже, чи кожен раннер ловить його на шлюзі політики, чи лишає його пісочниці, чи взагалі не може його перехопити.

Адаптер Claude Code проходить через шлюз лише для частини власних викликів інструментів. Claude Code запускається з --dangerously-skip-permissions, тож його виклики читання, запису та редагування ніколи не проходять крізь охоронець. Його команди bash доходять до нього через хук, що класифікує командний рядок, а його push, як і в будь-якого агента, проходить через шлюз push. Під шлюзом також поверхня інструментів MCP, у яку він викликає назад, і shell-команда, яку Control Center породжує для його запуску.
Власне вихідне дієслово режиму (submit_plan, propose_orchestration) закріплене й ніколи не може бути заборонене — інакше режим структурно не міг би створити свій єдиний результат.
Чи пісочниця підстраховує ці правила, залежить від хоста. Там, де cc_server знаходить бекенд, він обгортає CLI Claude Code і інструмент bash harness, тож під правилом, яке ви не писали, усе одно є базовий рівень ОС. У Windows його немає, і на Linux чи WSL2 без bwrap і socat його теж немає — там обмеження разом із поверхнею інструментів режиму становлять весь примус, а не його другу лінію. Перевірте, який у вас випадок, у Налаштувати політики пісочниці.