Разрешения и sandbox: как безопасно запускать Codex

Coding agent ценен тем, что может действовать, но действие создаёт риск. В Codex этот риск ограничивают две разные настройки: sandbox задаёт техническую границу доступа, а…

Краткий ответ

Coding agent ценен тем, что может действовать, но действие создаёт риск. В Codex этот риск ограничивают две разные настройки: sandbox задаёт техническую границу доступа, а approval policy определяет, когда требуется подтверждение пользователя.

Две независимые границы

Sandbox отвечает на вопрос «что процесс вообще может прочитать, изменить или вызвать». Approval policy отвечает на вопрос «какие выходы за обычный рабочий сценарий нужно согласовать».

Типичные режимы sandbox:

read-only — чтение и анализ без записи в проект;
workspace-write — запись внутри рабочей области при сохранении ограничений;
danger-full-access — отсутствие стандартной sandbox-изоляции, поэтому риск значительно выше.

Для version-controlled проекта официальная документация рекомендует начинать с ограниченной автоматической работы внутри workspace и подтверждать выход за её пределы. Для неизвестной папки или первичного аудита разумен read-only.

Выбирайте минимально достаточный доступ

Задача «объясни архитектуру» не требует записи. Исправление компонента требует workspace-write, но обычно не требует доступа ко всей домашней директории. Установка пакета или обращение к сети может потребовать отдельного разрешения в зависимости от конфигурации.

Перед расширением доступа проверьте:

1. какое конкретное действие заблокировано; 2. почему оно необходимо для критерия готовности; 3. можно ли достичь результата внутри текущей границы; 4. какие данные станут доступны после расширения; 5. можно ли разрешить одну команду вместо постоянного изменения режима.

Запрос «дайте полный доступ, чтобы не мешало» не объясняет необходимость и маскирует архитектурную проблему рабочего процесса.

Как оценивать запрос подтверждения

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

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

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

Внешний контент как недоверенный ввод

Репозиторий, issue, веб-страница или вывод инструмента могут содержать инструкции, пытающиеся изменить поведение агента. Это prompt injection. Текст из внешнего источника следует воспринимать как данные для анализа, а не как новое разрешение.

Практические меры:

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

Безопасный сценарий для незнакомого репозитория

1. Открыть проект в read-only.
2. Проверить Git status, инструкции и команды сборки.
3. Попросить карту точек входа и внешних интеграций.
4. Не запускать найденные скрипты установки автоматически.
5. После проверки доверия разрешить запись только в workspace.
6. Подтверждать сеть или внешние действия по одному назначению.
7. Перед завершением просмотреть diff и результаты тестов.

Для критичной среды добавьте контейнер или отдельную тестовую учётную запись. Sandbox снижает риск, но не превращает недоверенный код в безопасный.

Упражнение: матрица доступа

Для четырёх задач — объяснение кода, исправление теста, обновление зависимости и production-миграция — запишите:

минимальный sandbox;
нужен ли доступ к сети;
какие действия требуют ручного подтверждения;
какие секреты вообще не должны попадать в среду;
какой откат доступен.

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

Частые вопросы

Можно ли отключить подтверждения, но оставить sandbox?

Да, approval policy и sandbox настраиваются отдельно. Режим без запросов не расширяет сам по себе файловые границы, однако заблокированное действие тогда не сможет попросить исключение и завершится ошибкой.

Делает ли workspace-write любой проект безопасным?

Нет. Код внутри workspace может быть ценным, а разрешённая команда может менять файлы, запускать процессы или использовать доступные данные. Нужны Git, проверка команд, минимальные секреты и осознанное доверие к репозиторию.

Когда допустим danger-full-access?

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

Что важно запомнить

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

https://yadro-code.ru/lessons/without-university/codex-agent-workflows/codex-agent-05