Codex bypass: что отключает флаг и чем его заменить

Codex bypass обычно означает запуск с флагом --dangerously-bypass-approvals-and-sandbox. Он одновременно убирает песочницу и запросы подтверждения, поэтому для обычной работы лучше выбрать ограниченный режим и отдельно настроить поведение подтверждений. Ниже есть безопасная схема для интерактивной работы и автоматизации.

Что именно отключает bypass

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

Важно не смешивать отсутствие вопросов с полным доступом. Значение approval_policy = "never" запрещает Codex спрашивать подтверждение, но границы файловой системы не расширяет. Режим sandbox_mode = "workspace-write" по-прежнему ограничивает запись рабочей областью. Допустимые значения обоих параметров перечислены в справочнике конфигурации Codex.

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

Как выбрать режим под задачу

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

• Нужно прочитать проект и предложить изменения: read-only с on-request.
• Нужно менять файлы только в проекте: workspace-write с on-request.
• Нужен запуск без человека в пределах проекта: workspace-write с never.
• Нужны системные файлы и свободная сеть: сначала создайте отдельный контейнер или временную машину, затем решайте вопрос полного доступа внутри неё.

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

Безопасный запуск без постоянных подтверждений

Для повторяемой проверки кода можно оставить запись внутри проекта и убрать интерактивные вопросы. Официальная таблица режимов рекомендует для неинтерактивного запуска codex exec --sandbox workspace-write; политика never задаётся настройкой или параметром запуска. Так агент не зависнет в ожидании ответа и не получит доступ ко всей машине.

1. Сохраните незакоммиченные изменения или сделайте копию рабочих файлов, чтобы видеть только результат текущего запуска.
2. Укажите sandbox_mode = "workspace-write" и approval_policy = "never" в отдельном профиле, который используется только для автоматизации.
3. Дайте узкую задачу с перечнем разрешённых файлов, команд проверки и условия завершения.
4. После выполнения просмотрите список изменённых файлов, diff и результаты целевых проверок.
5. Удалите профиль или верните on-request, если неинтерактивный запуск больше не нужен.

# ~/.codex/automation.config.toml
approval_policy = "never"
sandbox_mode = "workspace-write"

Запускайте интерактивный сеанс командой codex --profile automation, а неинтерактивный запуск командой codex exec --profile automation; используйте профиль только для репозитория, которому доверяете. Инструкции могут находиться в AGENTS.md, навыках и других доступных файлах, поэтому перед автономным запуском полезно проверить их содержимое. Для отдельной подготовки задачи подойдёт режим Plan в Codex.

Проверочный список перед запуском

Этот список отделяет удобство от реального расширения прав. Если хотя бы один пункт нельзя подтвердить, сохраните on-request или уменьшите область задачи.

• Рабочая папка содержит только данные, которые агенту разрешено читать.
• Секреты не лежат в файлах проекта и не выводятся командами проверки.
• Запись за пределы проекта не нужна для ожидаемого результата.
• Сеть включена только при явной необходимости и ограничена внешней средой или правилами.
• Изменения можно увидеть через систему контроля версий и откатить.
• Команда проверки не публикует, не развёртывает и не удаляет данные.

Практический граничный случай: approval_policy = "never" в read-only не превращает аудит в редактирование. Агент просто не сможет запросить расширение прав. Это полезно для проверки в непрерывной интеграции, но не подходит для задания, которое должно исправить найденные ошибки.

По теме: Codex Sandbox: режимы, разрешения и безопасная проверка

Если запуск не дал результата

Если запуск завершился без результата, сначала определите, какой слой остановил действие. Не включайте bypass до этой проверки.

1. Codex сообщает о запрете записи: проверьте sandbox_mode и список доступных рабочих корней.
2. Codex не может обратиться к сайту: проверьте сетевую политику отдельно от файловых прав.
3. Codex ждёт ответа человека: проверьте approval_policy и правила, которые вызывают подтверждение.
4. Настройка не применяется: проверьте выбранный профиль, проектный config.toml и управляемые требования организации.
5. Команда работает только с полным доступом: вынесите её в отдельный подготовительный шаг или изолированную среду.

Управляемые требования организации могут запретить отдельные режимы. В таком случае локальная строка в конфигурации не должна обходить политику администратора. Разбирайте конкретное сообщение и сверяйте его с руководством по ошибкам Codex.

Когда полный bypass всё же применяют

Официальная документация допускает --sandbox danger-full-access и равнозначный опасный флаг, когда Codex должен читать, менять файлы и выполнять сетевые команды без вопросов. Документация помечает этот режим как повышенный риск и не рекомендует его для обычной работы.

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

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

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

Флаг bypass просто убирает вопросы Codex?

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

Чем отличается full auto от bypass?

Старый codex exec --full-auto сохранён как устаревший совместимый путь. Для новых сценариев официальная документация предлагает явно выбирать песочницу, например codex exec --sandbox workspace-write, и задавать политику подтверждений отдельно.

Можно ли включить bypass только для одного проекта?

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

Почему never не помогает записать файл?

Потому что never управляет вопросами, а не файловой границей. Проверьте sandbox_mode и доступные рабочие корни.