Песочница

Песочница — это граница, которая позволяет агенту действовать автономно, не предоставляя ему неограниченный доступ к вашему компьютеру. Когда локальный чат выполняет команды в настольном приложении ChatGPT, Codex CLI или расширении IDE, эти команды по умолчанию выполняются в ограниченной среде, а не с полным доступом.

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

Что делает песочница

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

Codex использует встроенные механизмы защиты каждой ОС. Реализация различается в macOS, Linux, WSL2 и нативной Windows, но принцип одинаков во всех интерфейсах: предоставить агенту ограниченное рабочее пространство, чтобы стандартные задачи могли выполняться автономно в чётко заданных пределах.

Почему это важно

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

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

Начало работы

В режиме разрешений по умолчанию песочница применяется автоматически.

Предварительные требования

В macOS песочница работает без дополнительной настройки благодаря встроенному фреймворку Seatbelt.

В Windows Codex использует нативную песочницу Windows при работе в PowerShell и реализацию песочницы Linux при работе в WSL2.

В Linux и WSL2 сначала установите bubblewrap с помощью менеджера пакетов:

Ubuntu/Debian

sudo apt install bubblewrap

Fedora

sudo dnf install bubblewrap

Codex использует первый исполняемый файл bwrap, найденный в PATH. Если исполняемый файл bwrap недоступен, Codex использует встроенный вспомогательный инструмент, но для его работы необходима поддержка создания непривилегированных пользовательских пространств имён. Установка пакета дистрибутива, содержащего bwrap, обеспечивает надёжность этой конфигурации.

Codex показывает предупреждение при запуске, если bwrap отсутствует или вспомогательный инструмент не может создать необходимое пользовательское пространство имён. В дистрибутивах, ограничивающих этот параметр AppArmor, рекомендуется загрузить профиль AppArmor bwrap, чтобы bwrap мог продолжать работу без глобального отключения ограничения.

Как работают разрешения

Используйте элемент управления разрешениями в соответствующем интерфейсе, чтобы изменить обработку локальных aдействий в Codex.

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

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

Настройка значений по умолчанию

Чтобы при каждом запуске использовать одинаковое поведение, задайте значения по умолчанию в config.toml. В разделе Основы конфигурации объясняется принцип работы, а Справочник по конфигурации описывает точные ключи для sandbox_mode, approval_policy, approvals_reviewer и sandbox_workspace_write.writable_roots. Используйте эти параметры, чтобы определить степень автономности агента по умолчанию, каталоги, в которые он может записывать данные, моменты, когда он должен приостанавливаться для подтверждения, и того, кто рассматривает подходящие запросы на подтверждение.

На высоком уровне распространены следующие режимы песочницы:

• read-only: агент может просматривать файлы, но не может изменять их или выполнять команды без подтверждения.
• workspace-write: агент может читать файлы, изменять их в рабочем пространстве и выполнять стандартные локальные команды в его пределах. Это режим по умолчанию с минимальным количеством препятствий для локальной работы.
• danger-full-access: агент работает без ограничений песочницы. Этот режим снимает ограничения файловой системы и сети; его следует использовать, только если вы хотите, чтобы агент действовал с полным доступом.

Распространённые политики подтверждений:

• untrusted: агент запрашивает подтверждение перед выполнением команд, не входящих в его доверенный набор.
• on-request: по умолчанию агент работает в песочнице и запрашивает подтверждение, когда ему требуется выйти за её пределы.
• never: агент не останавливается для запросов подтверждения.

При интерактивных подтверждениях можно также выбрать, кто будет их рассматривать, с помощью approvals_reviewer:

• user: запросы подтверждения показываются пользователю. Это значение по умолчанию.
• auto_review: подходящие запросы подтверждения направляются агенту-рецензенту (см. автоматическую проверку).

Полный доступ означает совместное использование sandbox_mode = "danger-full-access" и approval_policy = "never". В отличие от него, предустановка локальной автоматизации с более низким риском использует sandbox_mode = "workspace-write" вместе с approval_policy = "on-request" или соответствующие флаги CLI --sandbox workspace-write --ask-for-approval on-request. Затем можно оставить approvals_reviewer = "user" для ручных подтверждений или задать approvals_reviewer = "auto_review" для автоматической проверки подтверждений.

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

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

Автоматическая проверка, если она доступна, не изменяет границы песочницы. Это один из возможных вариантов approvals_reviewer для запросов подтверждения на этой границе, например при расширении прав песочницы, заблокированном доступе к сети или вызовах инструментов с побочными эффектами, которые всё ещё требуют подтверждения. Действия, уже разрешённые в песочнице, выполняются без дополнительной проверки. Сведения о жизненном цикле рецензента, типах триггеров, семантике отклонения и настройке см. в разделе Автоматическая проверка.

Подробности о платформах приведены в документации для каждой платформы. Сведения о настройке нативной Windows, её поведении и устранении неполадок см. в разделе Windows. Требования к администраторам и ограничения на уровне организации для песочницы и подтверждений см. в разделе Подтверждения действий агента и безопасность.