Автоматическая проверка

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

Как работает автоматическая проверка

В общих чертах процесс выглядит так:

1. Основной агент работает внутри read-only или workspace-write.
2. Когда ему требуется выйти за границы песочницы, он запрашивает одобрение.
3. Если approvals_reviewer = "auto_review", Codex направляет этот запрос на одобрение отдельному агенту-рецензенту, а не останавливается в ожидании решения человека.
4. Рецензент решает, следует ли выполнять действие, и возвращает обоснование.
5. Если действие одобрено, выполнение продолжается. Если оно отклонено, основной агент получает указание найти существенно более безопасный путь или остановиться и обратиться к пользователю.

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

Когда она запускается

Автоматическая проверка рассматривает запросы на одобрение, которые иначе потребовали бы вмешательства человека. К ним относятся:

• Вызовы оболочки или инструмента exec, запрашивающие расширенные разрешения песочницы.
• Сетевые запросы, заблокированные текущей песочницей или политикой.
• Изменения файлов за пределами разрешённых для записи корневых каталогов.
• Вызовы инструментов MCP или приложений, требующие одобрения согласно их аннотациям или настроенному режиму одобрения.
• Доступ Computer Use к новому сайту или домену.

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

Computer Use представляет собой отдельный случай. Запросы на одобрение приложений для Computer Use по-прежнему показываются непосредственно пользователю, поэтому автоматическая проверка не заменяет такие запросы на уровне приложений.

Что блокирует автоматическая проверка

В общих чертах автоматическая проверка предназначена для блокирования таких действий, как:

• отправка конфиденциальных данных, секретов или учётных данных ненадёжным получателям
• поиск учётных данных, токенов, файлов cookie или материалов сеанса
• масштабное или постоянное ослабление защиты
• разрушительные действия со значительным риском необратимого ущерба

Точная политика находится в репозитории Codex с открытым исходным кодом: policy_template.md и policy.md. Эту политику можно настроить для каждой организации с помощью guardian_policy_config или для каждого пользователя с помощью локального файла [auto_review].policy.

Что видит рецензент

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

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

Скрытые рассуждения ассистента не включаются. Автоматическая проверка видит сохранённые элементы чата и свидетельства от инструментов, но не скрытую цепочку рассуждений.

Отклонения и поведение при сбоях

Явное отклонение не обрабатывается как обычная ошибка песочницы. Codex возвращает основному агенту обоснование рецензента и добавляет более строгое указание:

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

Codex также применяет предохранитель отклонений для каждого хода. В текущей реализации с открытым исходным кодом автоматическая проверка прерывает ход после 3 последовательных отклонений или 10 отклонений в скользящем окне из последних 50 проверок в рамках одного хода.

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

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

Также предусмотрен явный способ переопределить решение для отклонённых действий. В текущем TUI с открытым исходным кодом выполните /approve, чтобы открыть окно выбора Отклонения автоматической проверки, затем выберите одно из недавно отклонённых действий, чтобы одобрить одну повторную попытку. Codex сохраняет до 10 недавних отклонений для каждой задачи. Такое одобрение имеет узкую область действия: оно применяется к конкретному отклонённому действию, а не к похожим будущим действиям; оно регистрируется для одной повторной попытки в том же контексте; и повторная попытка всё равно проходит автоматическую проверку. Внутренне Codex добавляет маркер одобрения с областью действия разработчика для этого конкретного действия. Рецензент видит это явное переопределение пользователя в контексте, но по-прежнему следует политике и может снова отклонить действие, если политика не позволяет пользователю переопределять такой класс отклонений.

Настройка

Подробности настройки приведены в разделе Управляемая конфигурация.

Политика рецензента по умолчанию находится в репозитории Codex с открытым исходным кодом: core/src/guardian/policy.md. Организации могут заменить её раздел, относящийся к конкретному арендатору, с помощью guardian_policy_config в управляемых требованиях. Отдельные пользователи также могут задать локальный [auto_review].policy в своём config.toml, но управляемые требования имеют приоритет:

[auto_review]
policy = """
YOUR POLICY GOES HERE
"""

Чтобы настроить политику, сначала скопируйте полный текст политики по умолчанию, а затем последовательно изменяйте его с учётом индивидуального профиля рисков.

Сокращение количества проверок без ослабления безопасности

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

На практике наиболее эффективны следующие изменения:

• Добавьте узкие writable_roots для временных каталогов или соседних репозиториев, которые вы намеренно используете.
• Добавьте узко заданные правила префиксов. Отдавайте предпочтение точным префиксам команд, таким как ["cargo", "test"] или ["pnpm", "run", "lint"], а не широким шаблонам, таким как ["python"] или ["curl"]. Широкие правила часто стирают именно ту границу, которую призвана охранять автоматическая проверка.

Стенограммы сеансов автоматической проверки по умолчанию сохраняются в ~/.codex/sessions, поэтому перед изменением политики или разрешений вы можете попросить Codex проанализировать предыдущие запросы в этом каталоге.

Ограничения

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

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

Обоснование подхода и опубликованные результаты оценки приведены в публикации Alignment Research об автоматической проверке.