Настроить политики песочницы

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

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

Что ограничивает запуск агента

Агента держат шесть вещей. Первая — песочница ОС, и только она условна: остальные пять действуют на любом хосте.

Граница	Что она делает
Песочница ОС	Seatbelt в macOS, bubblewrap в Linux и WSL2. Оборачивает CLI Claude Code, адаптеры ACP и инструмент `bash` харнесса. Отсутствует в Windows и в Linux без `bwrap` и `socat`
Собственный worktree	Каждый разговор получает копию с копированием при записи. Исходная рабочая копия добавляется в запуск как путь с запретом записи, и обеспечивает это именно песочница
Учётные данные от брокера	Брокер учётных данных создаёт окружение для каждого запуска и отзывает его при сворачивании. Токен GitHub в нём может читать, но не делать push: push проходит через Control Center, который сначала спрашивает правило push
Ограничения действий	Каждый изменяющий инструмент объявляет свои классы эффектов, и защита разрешает их до выполнения вызова. `prompt` без подключённого одобряющего отклоняется
Очистка окружения	ACP и инструмент `bash` харнесса получают отфильтрованное окружение. Claude Code через `NoSandboxAdapter` наследует окружение хоста
Поверхность инструментов режима	Режим только для чтения убирает изменяющие worktree инструменты полностью и закрепляет собственный выходной глагол режима, чтобы он всё равно мог выдать результат

Три вещи слабее, чем кажутся:

Только встроенный харнесс обеспечивает шлюз инструментов, контракты завершения и структурные правила режима. Адаптер Claude Code — нет. В частности, Claude Code запускается с --dangerously-skip-permissions, потому что неинтерактивный claude -p иначе навсегда завис бы на собственном запросе, — поэтому его собственные вызовы чтения, записи и редактирования Control Center не видит и не пропускает через шлюз, а команды bash проверяет только хук, читающий командную строку. Там, где песочница включена, границей вокруг них служит она.
Внутрипроцессные файловые инструменты харнесса (read, write, edit, apply patch, search, find, search_files) выполняются внутри процесса сервера, поэтому никакой профиль песочницы их не ограничивает. Через обёрнутый исполнитель команд проходит только инструмент bash. Эти инструменты ограничены собственной привязкой к путям плюс ограничения действий.
На хосте без бэкенда первая строка не применяется вовсе. ACP и инструмент bash харнесса откатываются к очистке окружения плюс политика команд; 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`
Обращаться к сети	Разрешить	Есть ли у песочницы сеть вообще, и веб-инструменты харнесса

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

Правила 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 харнесса и, через хук, в инструменте Bash Claude Code. Агент, который прячет команду (скрипт, eval, прямой вызов API), проходит эту проверку, но не проходит шлюз push.
Ключи тикетов никогда не попадают в песочницу. Агенты пишут тикеты через MCP-инструменты Control Center, которые спрашивают правило.
Сеть определяется один раз, при старте запуска. Запретить выключает сеть песочницы; Разрешить и Спросить сначала оставляют её включённой, а при Спросить сначала инструменты харнесса 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 glob-шаблоны секретных файлов из стандартной политики нельзя обеспечить для файлов, которые агент создаст позже. Такой нативный запуск теперь завершается ошибкой вместо того, чтобы молча игнорировать правила. Поэтому успешная проверка при запуске не гарантирует, что диспетчеризация в Linux сможет стартовать. --sandbox off — намеренный отказ от изоляции, а не замена границы безопасности.

Знать, что режим уже запрещает

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

Режим	Worktree	Что запрещает пресет
Агент (`chat`)	Доступно для записи	Ничего — применяются встроенные значения по умолчанию
План	Только для чтения	Удалить файл, писать вне рабочего дерева, создать коммит, отправить в удалённый репозиторий, открыть pull request, опубликовать ревью или слияние, писать во внешний трекер, установить пакет, запустить процесс, изменять структуру рабочего пространства, управлять enclosure (rig)
Ревью	Только для чтения	Те же одиннадцать. Недоступен для выбора пользователем — композер предлагает только Агент, План и Оркестрация
Оркестрация	Только для чтения	Те же одиннадцать

Доступ к сети и доступ к секретам намеренно не запрещаются режимом только для чтения: исследование — и есть его назначение.

Требовать одобрение до выполнения действия

Одобрение — это решение ограничений, а не настройка песочницы.

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

Решение Спросить сначала прерывает запуск и спрашивает вас. Если одобряющий не подключён, оно срабатывает в режиме fail-closed, и действие отклоняется. Полный порядок разрешения описан в разделе Настроить ограничения.

Устранение неполадок

Агент не может отправить, хотя я этого не запрещал

Посмотрите, что вывел 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

Ожидаемо ли это, решает то, какой инструмент до него добрался.

Внутрипроцессные файловые инструменты харнесса (read, write, edit, apply patch, search, find, search_files) выполняются в процессе сервера, поэтому никакой профиль песочницы к ним не применяется — их граница — это собственная привязка к путям плюс ограничения. Команда bash или CLI Claude Code, наоборот, обёрнуты там, где бэкенд есть, а ваши зарегистрированные рабочие копии внутри этой обёртки находятся под запретом записи в любом режиме, включая их написания после разрешения символических ссылок (в macOS путь, до которого добрались через /tmp или /var/folders, разрешается внутри /private, и теперь запрещены оба написания). На хосте без бэкенда ничего из этого не применяется. В любом случае ограничения могут просто отказать в действии Писать вне рабочего дерева.