Налаштувати політики пісочниці

Чи буде запуск агента в пісочниці, вирішує сервер під час завантаження (--sandbox). Перемикач Увімкнути пісочницю й вибір Бекенд у розділі Налаштування → Сервер → Діагностика та приватність — це вподобання, збережені на вашому пристрої. Виявлення хоста в картці Пісочниця повідомляє, що хост сервера може загорнути.

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

Що обмежує запуск агента

Агента стримують шість речей. Перша — пісочниця ОС, і саме вона умовна; решта п’ять діють на кожному хості.

Межа	Що вона робить
Пісочниця ОС	Seatbelt на macOS, bubblewrap на Linux і WSL2. Загортає CLI Claude Code, адаптери ACP та інструмент `bash` вбудованого harness. Відсутня на Windows і на Linux без `bwrap` і `socat`
Власний worktree	Кожна розмова отримує робочу копію з copy-on-write. Оригінальна робоча копія додається до запуску як шлях із забороною запису, і саме пісочниця це забезпечує
Облікові дані від брокера	Брокер облікових даних створює середовище для кожного запуску й відкликає його під час згортання. Токен GitHub у ньому може читати, але не робити push: push проходить через Control Center, який спершу запитує правило push
Обмеження дій	Кожен інструмент, що змінює стан, оголошує свої класи ефектів, і рушій обмежень розв’язує їх до виконання виклику. `prompt` без під’єднаного затверджувача відхиляють
Очищення середовища	ACP та інструмент `bash` вбудованого harness отримують фільтроване середовище. Claude Code через `NoSandboxAdapter` успадковує середовище хоста
Поверхня інструментів режиму	Режим лише читання повністю вилучає інструменти, що змінюють worktree, і фіксує власне дієслово виводу режиму, щоб він усе одно міг видавати результат

Три речі залишаються слабшими, ніж здаються:

Лише вбудований harness забезпечує шлюз інструментів, контракти завершення та структурні правила режимів. Адаптер Claude Code — ні. Зокрема, Claude Code запускається з --dangerously-skip-permissions, бо неінтерактивний claude -p інакше блокувався б назавжди на власному запиті на схвалення — тож Control Center не бачить і не обмежує власні виклики читання, запису та редагування Claude, а його шелові команди перевіряє лише хук, що читає командний рядок. Там, де пісочниця увімкнена, вона є межею навколо них.
Файлові інструменти harness у процесі (read, write, edit, apply patch, search, find, search_files) виконуються всередині процесу сервера, тож жоден профіль пісочниці їх не обмежує. Через загорнутий виконавець команд проходить лише інструмент bash. Ці інструменти обмежені власною ізоляцією шляхів плюс обмеженнями дій.
На хості без бекенда перший рядок не застосовується взагалі. ACP та інструмент bash вбудованого harness повертаються до очищення середовища плюс політики команд; Claude Code через NoSandboxAdapter успадковує середовище хоста. Сервер повідомляє про це у своєму журналі запуску. Перевірте свій нижче.

Вирішіть, що агент може надіслати

Перемикача для окремого агента для git push, GitHub, тікетингу чи мережі немає. Кожне з них — це правило дії:

Правило	Вбудований стандарт	Що охоплює
Надіслати на віддалений репозиторій	Спочатку запитати	Кожен `git push` у GitHub, незалежно від адаптера
Відкрити pull request	Спочатку запитати	`gh pr create` та інструменти для pull request
Опублікувати рецензію або злити	Спочатку запитати	`gh pr merge`, `gh pr review`, `gh pr comment`, `gh pr close`
Запис у зовнішній трекер	Спочатку запитати	Запис тікетів через інструменти Control Center і `gh issue`
Доступ до мережі	Дозволити	Чи має пісочниця мережу взагалі, і вебінструменти harness

Перейдіть у Налаштування → Робочий простір → Дозволи агента
Виберіть область — Робочий простір, Агент або Простір — і в рядку правила виберіть Дозволити, Спочатку запитати або Заборонити

Правила push, обмежені гілками, наприклад таке, що забороняє push у main, теж діють: див. Обмеження.

Контрольна точка: попросіть агента надіслати гілку. За Спочатку запитати ви отримаєте запит на схвалення з репозиторієм і ref; за Заборонити git виведе ! [remote rejected] <ref> (Control Center policy: …).

Як кожне правило доходить до запуску:

Push забезпечується тим, що має запуск. Його токен GitHub — це токен установлення GitHub App лише для читання, який може читати вміст і працювати з pull request. Його конфігурація git надсилає кожен push у GitHub на loopback-шлюз у cc_server, який запитує правило й лише тоді передає push із токеном запису, якого агент ніколи не бачить. Шлюз передає лише у власний репозиторій worktree або в репозиторій GitHub, пов’язаний із робочим простором. Це діє для кожного адаптера.
Pull request та issues з оболонки розпізнаються за командним рядком — в інструменті bash harness і, через хук, в інструменті Bash Claude Code. Агент, який приховує команду (скрипт, eval, прямий виклик API), проходить цю перевірку, але не шлюз push.
Ключі тікетингу ніколи не потрапляють у пісочницю. Агенти пишуть тікети через MCP-інструменти Control Center, які запитують правило.
Мережа визначається один раз, коли запуск стартує. Заборонити вимикає мережу пісочниці; Дозволити та Спочатку запитати залишають її ввімкненою, а за Спочатку запитати інструменти harness web_fetch і web_search і далі запитують під час кожного виклику. Поки мережа ввімкнена, GitHub завжди є в списку дозволеного вихідного трафіку.

Без налаштованого GitHub App запуск отримує запасний персональний токен доступу, який не можна обмежити лише читанням. git push і далі проходить через шлюз і правило, але код, що напряму використовує токен, може зробити push в обхід нього. Налаштуйте GitHub App, щоб правило стало обов’язковим.

Облікові дані GitHub для запуску завжди належать брокеру — це токен установлення GitHub App з областю репозиторію або запасний PAT — і ніколи не власний збережений токен члена, який надіслав запит. Серверний PAT не видається запуску, який діє від імені члена, що не є власником і не підключив GitHub.

Перевірте, чи ваші запуски агентів у пісочниці

Це вирішують дві речі, обидві на сервері: чи пропонує хост бекенд і чи увімкнено --sandbox. Перевіряйте їх у такому порядку.

Перейдіть у Налаштування → Сервер → Діагностика та приватність
Прочитайте картку Пісочниця. Факт Хост — це машина, на якій працює cc_server, а не машина, на яку ви дивитеся. Поле Бекенд перелічує Нативна пісочниця (Seatbelt на macOS, bubblewrap на Linux і WSL2) або Без ізоляції. Факт Чинне — це вподобання цього пристрою, а не обгортка, яку сервер справді використовує.
Прочитайте журнал запуску сервера. Він друкує рівно один із трьох рядків:
- agent sandbox ON плюс примітка про бекенд — запуски загорнуто
- no OS-native agent sandbox on this host плюс підказка щодо встановлення, де вона є — запуски не загорнуто
- agent sandbox DISABLED by --sandbox off — навмисна відмова

GET /healthz не повідомляє стан пісочниці, тож журнал запуску і є перевіркою.

Щоб вимкнути пісочницю навмисно — хост, де профіль поводиться неправильно, і є причиною, чому така можливість існує — запустіть сервер із --sandbox off або задайте CC_SERVER_SANDBOX=off. Типове значення — on, і on означає «використати бекенд, якщо він на хості є», а не «вимагати його».

Дві ситуації ніколи не отримують нативної обгортки пісочниці. На Windows нативна перевірка завжди повідомляє про недоступність, і встановлювати нічого — диспетчеризація агентів використовує none. Бекенд microvm окремий (інтерактивні термінали та rigs) і має власну перевірку доступності залежно від свого середовища виконання. На Linux і WSL2 і bwrap, і socat мають бути в PATH; без них перевірка повідомляє про недоступність і називає відсутні пакети.

На Linux/WSL2 із встановленим bubblewrap глоб-шаблони секретних файлів стандартної політики неможливо застосувати до файлів, які агент створить пізніше. Такий нативний запуск тепер завершується невдачею, а не тихо ігнорує правила. Тож успішна перевірка під час завантаження не гарантує, що диспетчеризація на Linux зможе стартувати. --sandbox off — це навмисна відмова від обмежень, а не замінник межі безпеки.

Знайте, що режим уже забороняє

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

Режим	Worktree	Що відхиляє пресет
Агент (`chat`)	Для запису	Нічого — діють вбудовані стандарти
План	Лише читання	Видалити файл, записати поза worktree, створити коміт, надіслати (push), відкрити PR, опублікувати або злити, записати до зовнішнього трекера, встановити пакет, запустити процес, змінити структуру робочого простору, завантажити ізольоване середовище (rig) або керувати ним
Огляд	Лише читання	Ті самі одинадцять. Не вибирається користувачем — композер пропонує лише Агент, План та Оркестрація
Оркестрація	Лише читання	Ті самі одинадцять

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

Вимагати схвалення перед виконанням дії

Схвалення — це рішення обмежень, а не налаштування пісочниці.

Перейдіть у Налаштування → Робочий простір → Дозволи агента
Задайте класу дій значення Спочатку запитати в області робочого простору, агента або простору

Рішення Спочатку запитати перериває запуск і питає вас. Без під’єднаного затверджувача воно закривається відмовою, і дію відхиляють. Повний порядок розв’язання дивіться в розділі Налаштувати обмеження.

Усунення несправностей

Агент не може надіслати зміни, і я цього не забороняв

Подивіться, що вивів git. Control Center policy: … означає, що правило відхилило push або що Спочатку запитати лишилося без відповіді. … is not linked to this workspace означає, що push спрямовано в репозиторій, який не є репозиторієм worktree і не пов’язаний із робочим простором. Control Center has no GitHub credential that can push … означає, що GitHub App не встановлено в цьому репозиторії й жодні запасні облікові дані не змогли зробити push: установіть застосунок у репозиторій або підключіть GitHub.

Картка «Пісочниця» повідомляє, що нативної пісочниці немає

Тоді запуски агентів на цьому хості не загорнуті Seatbelt чи bubblewrap, і ви маєте лише решту меж. На Linux і WSL2 встановіть обидва відсутні інструменти — sudo apt-get install bubblewrap socat — і перезапустіть сервер; після цього журнал запуску має сказати, що пісочницю увімкнено. На Windows нативного бекенда для встановлення немає, тож натомість посильте обмеження: дивіться Налаштувати обмеження.

Агент дістався файлу поза своїм worktree

Від того, який інструмент до нього дістався, залежить, чи це очікувано.

Файлові інструменти harness у процесі (read, write, edit, apply patch, search, find, search_files) виконуються в процесі сервера, тож жоден профіль пісочниці до них не застосовується — їхньою межею є власна ізоляція шляхів плюс обмеження. Команда bash або CLI Claude Code загорнуті там, де бекенд існує, і ваші зареєстровані робочі копії мають заборону запису всередині цієї обгортки в кожному режимі, включно з їхнім розв’язаним через символьні посилання написанням (на macOS шлях, досягнутий через /tmp або /var/folders, розв’язується під /private, і тепер заборонено обидва написання). На хості без бекенда нічого з цього не застосовується. У будь-якому разі обмеження можуть відхилити Запис поза робочим деревом одразу.