Песочница и одобрения: что агенту можно без спроса

Агент запускает команды на вашем компьютере. Это и делает его полезным, и требует границ. В Codex границы задают две независимые настройки: песочница и политика одобрений. Разберёмся, что каждая означает, какой режим выбирать и как читать запросы на одобрение, чтобы не нажимать «да» не глядя.

Две оси

Песочница (sandbox) определяет, что агенту технически доступно: какие файлы он может читать и менять, есть ли у него сеть. Ограничения действуют на уровне операционной системы и распространяются на все процессы, которые запускает агент: git, composer, npm, тесты.

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

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

Режимы песочницы

Рабочий каталог (workspace) — это папка, в которой вы запустили Codex, плюс временные каталоги вроде /tmp. Посмотреть точный список доступных для записи каталогов можно командой /status.

У политики одобрений два основных значения: on-request — агент работает внутри песочницы и спрашивает, когда нужно выйти за неё; never — агент не останавливается для одобрений. Есть ещё тонкая настройка granular по типам запросов — она понадобится позже, в курсе по настройке.

Готовые сочетания

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

При запуске Codex сам смотрит, под git ли папка: для репозиториев он рекомендует Auto, для папок без контроля версий — только чтение.

В десктопном приложении и IDE те же режимы называются иначе: Ask for approval, Approve for me, Full access. В CLI режим меняется посреди сессии командой /permissions.

Что ограничено даже в Auto

Сеть. По умолчанию у агента нет доступа в сеть. composer install, npm install, запрос к внешнему API — всё это потребует одобрения. Это неудобно в первый день, но защищает от целого класса проблем: утечки данных, скачивания чего попало, обращения к боевым сервисам.

Защищённые каталоги. Внутри рабочего каталога .git, .codex, .agents и .aws остаются только для чтения. Поэтому агент не может молча переписать историю репозитория или собственные настройки, а git commit от его имени потребует одобрения.

Каталоги вне проекта. Если агенту нужно писать ещё куда-то — например, в соседний репозиторий с общей библиотекой, — дайте доступ точечно:

codex --add-dir ../shared-lib

Документация прямо рекомендует --add-dir вместо переключения в полный доступ.

Как читать запрос на одобрение

Когда агент останавливается и спрашивает, перед вами команда и причина. Прежде чем ответить, проверьте три вещи:

1. Что это за команда. composer require нового пакета, когда вы просили поправить валидацию, — повод спросить зачем.
2. Где она выполнится. Запись вне проекта, в домашний каталог, в системные папки — внимательнее.
3. Куда уходит сеть. Установка зависимости из публичного реестра — одно, curl на неизвестный адрес или запрос к боевому API — совсем другое.

Если сомневаетесь — откажите и спросите агента, зачем ему это. Отказ не ломает сессию: агент поищет другой путь или объяснит.

Отдельная осторожность — с командами, которые меняют внешний мир: git push, миграции на общей базе, деплой, отправка писем. Их стоит одобрять только когда вы точно понимаете последствия. Позже, в курсе по настройке, вы научитесь задавать для таких команд постоянные правила — урок «Rules».

Approve for me

В режиме Approve for me запросы на выход за границы рассматривает не человек, а отдельный агент-ревьюер. Он оценивает эскалации, сетевые запросы, правки вне рабочих каталогов и вызовы инструментов с побочными эффектами. Важно: этот режим не расширяет песочницу, он лишь меняет, кто принимает решение по запросу.

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

Полный доступ

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

Как это устроено на разных ОС

На macOS песочница работает на встроенном механизме Seatbelt. На Linux и в WSL2 — на bubblewrap, поэтому его нужно поставить заранее (урок «Установка и вход»). На Windows у Codex своя нативная песочница. Проверить, как конкретная команда поведёт себя в песочнице, можно командой codex sandbox — подробности в документации.

Если вы читали старые инструкции

• Флаг --full-auto больше не поддерживается. Вместо него — режим по умолчанию (--sandbox workspace-write) или --approve-for-me.
• Политика одобрений untrusted удалена, on-failure устарела. Остались on-request, never и granular. Строгое поведение старого untrusted теперь задаётся пометкой проекта как недоверенного (trust_level = "untrusted").
• Команда /approvals в CLI заменена на /permissions.