Флаг Codex CLI —dangerously-bypass-approvals-and-sandbox (—yolo): запуск без ограничений

Флаг Codex CLI --dangerously-bypass-approvals-and-sandbox применяется для запуска Codex в режиме, где инструмент не запрашивает подтверждение перед выполнением действий и не ограничивает команды песочницей. У него есть короткий аналог — --yolo. Это удобный режим для автоматизации и быстрых экспериментов, но одновременно один из самых рискованных вариантов запуска: Codex получает возможность изменять файлы, выполнять команды и взаимодействовать с системой практически без защитных остановок.

Главная мысль: --yolo экономит время не потому, что делает Codex умнее, а потому, что отключает два важных уровня контроля — подтверждения пользователя и sandbox-ограничения.

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

Как использовать

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

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

Базовый запуск интерактивного Codex CLI выглядит так:

codex --dangerously-bypass-approvals-and-sandbox

Короткая форма выполняет ту же задачу:

codex --yolo

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

cd /tmp/demo-project
codex --yolo

Вариант	Что делает	Когда удобен	Главный риск
codex --dangerously-bypass-approvals-and-sandbox	Полностью развёрнутая форма опасного режима	Документация, скрипты запуска, явное чтение команды	Можно недооценить объём предоставленных прав
codex --yolo	Короткий эквивалент	Быстрый локальный запуск	Смысл флага менее очевиден тому, кто увидит команду позже
codex	Обычный режим с защитными механизмами	Работа с реальным проектом	Меньше автоматизации, больше запросов подтверждения

Перед использованием полезно проверить справку конкретной установленной версии:

codex --help

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

Что проверить	Команда или действие	Зачем это нужно
Наличие флага	codex --help	Убедиться, что текущая версия его понимает
Текущий каталог	pwd или просмотр пути в проводнике	Не запустить агент в домашней или рабочей папке случайно
Состав файлов	git status, список каталога	Понять, какие данные находятся в зоне работы
Состояние репозитория	git diff	Не потерять незакоммиченные изменения

Если команда не распознаётся, не стоит сразу заменять её случайными вариантами вроде --yolo-mode или --no-sandbox. Сначала откройте справку и документацию установленной версии. Неправильный параметр может либо завершить запуск с ошибкой, либо создать ложное впечатление, что защита отключена, хотя на самом деле Codex работает в обычном режиме.

Когда применять

Опасный режим оправдан не самим фактом срочности, а сочетанием низкой ценности данных и высокой предсказуемости задачи. Чем меньше последствий у потенциальной ошибки, тем разумнее экспериментировать с автоматическим запуском.

Хорошее правило: сначала изолируйте среду, затем отключайте подтверждения, а не наоборот.

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

Сценарий	Оценка применимости	Рекомендация
Временный проект в отдельной папке	Высокая	Создать каталог специально под эксперимент
Генерация моков и тестовых данных	Высокая	Использовать данные без персональной и коммерческой информации
Рефакторинг рабочего продукта	Низкая	Оставить подтверждения и sandbox
Репозиторий с ключами и токенами	Очень низкая	Не применять режим без изоляции и удаления секретов
Продакшен-сервер	Недопустимая для обычной работы	Использовать отдельный стенд и строгие права

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

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

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

Среда	Что должно быть изолировано	Минимальная мера безопасности
Временная папка	Только файлы эксперимента	Проверить путь перед запуском
Контейнер	Файловая система и сетевой доступ	Не монтировать домашний каталог без необходимости
Виртуальная машина	Операционная система и снимок состояния	Создать snapshot перед экспериментом
CI-агент	Переменные окружения и токены	Выдать временные права и ограничить секреты
Рабочий ноутбук	Соседние каталоги и личные данные	Не запускать режим из домашнего каталога

Примеры использования

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

Запуск в отдельной временной папке

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

mkdir /tmp/codex-playground
cd /tmp/codex-playground
codex --dangerously-bypass-approvals-and-sandbox

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

Быстрое создание прототипа

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

mkdir /tmp/weather-prototype
cd /tmp/weather-prototype
codex --yolo

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

Автоматическая генерация тестовых файлов

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

cd /tmp/sample-library
codex --yolo

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

Рефакторинг учебного репозитория

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

git clone https://example.org/demo-project.git /tmp/demo-project
cd /tmp/demo-project
git status
codex --dangerously-bypass-approvals-and-sandbox

Важное условие — не использовать в таком клоне реальные токены, закрытые ключи и производственные настройки.

Работа внутри контейнера

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

docker run --rm -it --network none -v /tmp/codex-project:/workspace -w /workspace codex-image
codex --yolo

Перед использованием проверьте, что образ содержит нужные инструменты, а каталог /tmp/codex-project не является ссылкой на важные данные.

Генерация документации в копии проекта

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

cp -R ./service ./service-docs-draft
cd ./service-docs-draft
codex --dangerously-bypass-approvals-and-sandbox

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

Запуск с заранее подготовленным снимком

В виртуальной машине или файловой системе со снимками можно вернуть состояние до эксперимента, если автоматические изменения окажутся неудачными.

cd /var/tmp/codex-snapshot
codex --yolo

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

Одноразовая миграция формата файлов

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

cd /tmp/fixtures
codex --dangerously-bypass-approvals-and-sandbox

Сначала сохраните исходные файлы в архив. Особенно это важно при массовом переименовании: одна ошибка в шаблоне способна затронуть сотни объектов.

Автоматизированный локальный эксперимент

Для воспроизводимого эксперимента удобно запускать Codex из заранее подготовленного рабочего каталога с небольшим набором входных данных.

mkdir -p /tmp/codex-run/input /tmp/codex-run/output
cd /tmp/codex-run
codex --yolo

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

Проверка поведения нового инструмента

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

cd /tmp/tool-evaluation
codex --dangerously-bypass-approvals-and-sandbox

После теста удалите временные ключи, кэш и созданные зависимости, если они больше не нужны.

Перед запуском	Во время работы	После завершения
Проверить каталог и секреты	Следить за необычными действиями	Изучить git diff и новые файлы
Сделать копию или snapshot	Не добавлять реальные токены в запрос	Проверить процессы и сетевые эффекты
Определить допустимый результат	Не расширять задачу без повторной оценки	Удалить временные данные

Чем отличается от…

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

От обычного запуска codex

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

Свойство	codex	codex --yolo
Подтверждения	Могут запрашиваться	Обходятся
Sandbox	Используется согласно настройкам	Обходится
Контроль пользователя	Выше	Минимальный
Подходящая среда	Рабочий проект	Изолированный эксперимент

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

От режима, который обходит только подтверждения

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

Изменение	Подтверждения	Sandbox	Общий риск
Обычный режим	Сохраняются	Сохраняется	Ниже
Обход подтверждений	Отключены или сокращены	Может сохраняться	Средний
--dangerously-bypass-approvals-and-sandbox	Отключены	Отключается	Очень высокий

Нельзя считать два режима одинаковыми только потому, что в обоих случаях Codex реже обращается к пользователю. Граница доступа к системе может отличаться принципиально.

От режима, который отключает только sandbox

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

У полного опасного флага убираются сразу оба барьера. Поэтому риск складывается не просто из двух независимых настроек: свободный доступ плюс отсутствие пауз дают агенту гораздо больше самостоятельности.

От --yolo

--yolo — короткая форма опасного режима, а не отдельный «облегчённый» вариант. Если конкретная версия Codex CLI документирует их как эквивалентные, смысл и последствия нужно считать одинаковыми.

Команда	Читаемость	Предполагаемый смысл	Рекомендация
codex --yolo	Короткая	Опасный автоматический режим	Уместна для личного быстрого запуска
codex --dangerously-bypass-approvals-and-sandbox	Максимально явная	Отключение подтверждений и sandbox	Лучше для документации и командных сценариев

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

Типичные ошибки

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

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

Запуск из домашнего каталога

Команда, выполненная после перехода в ~, может открыть агенту доступ к документам, настройкам, SSH-конфигурации и множеству несвязанных проектов. Это одна из самых распространённых и самых легко предотвращаемых ошибок.

cd ~
codex --yolo

Безопаснее создать отдельную папку и явно перейти в неё:

mkdir /tmp/codex-safe
cd /tmp/codex-safe
codex --yolo

Слепое доверие к короткому псевдониму

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

codex --yolo

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

Запуск рядом с секретами

Файл с секретами может лежать в каталоге, даже если он не нужен текущей задаче. Наличие записи в .gitignore не означает, что файл невидим для локального процесса: игнорирование влияет на Git, а не на доступ программы к диску.

cd ./production-config
codex --dangerously-bypass-approvals-and-sandbox

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

Отсутствие проверки результата

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

cd ./demo-project
codex --yolo
git status
git diff

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

Ошибка	Почему опасна	Как предотвратить
Запуск из домашнего каталога	В зоне доступа оказываются личные и служебные файлы	Использовать отдельную рабочую папку
Секреты в окружении	Команды могут получить доступ к токенам	Использовать временные и минимальные права
Нет резервной копии	Ошибки трудно отменить	Сделать commit, архив или snapshot
Нет проверки diff	Незаметные изменения остаются без контроля	Проверить новые и изменённые файлы
Запуск на сервере	Последствия затрагивают реальные сервисы	Использовать стенд или контейнер без production-доступа

Краткая памятка

Если нужно запомнить только главное, воспринимайте --dangerously-bypass-approvals-and-sandbox и --yolo как одну и ту же возможность: Codex получает максимум свободы, а пользователь — минимум автоматических остановок.

Вопрос	Правильная проверка
Где я запускаю Codex?	Путь указывает на изолированную временную папку или копию проекта?
Есть ли секреты?	Удалены ли ключи, токены, персональные и коммерческие данные?
Можно ли отменить изменения?	Есть ли commit, архив, копия или snapshot?
Нужен ли именно полный обход защиты?	Не достаточно ли обычного режима с подтверждениями?
Поддерживает ли версия флаг?	Проверен ли вывод codex --help?

1. Сначала изолируйте рабочий каталог.
2. Затем уберите реальные секреты и ограничьте права процесса.
3. Сохраните исходное состояние проекта.
4. Проверьте доступность флага в установленной версии.
5. Запускайте codex --dangerously-bypass-approvals-and-sandbox или его эквивалент codex --yolo только при понятном уровне риска.
6. После завершения изучите изменения, новые файлы, зависимости и побочные эффекты.

Для рабочего репозитория по умолчанию разумнее начинать с обычного codex. Опасный режим оставляйте для среды, которую можно безболезненно пересоздать. Тогда он будет инструментом ускорения, а не кнопкой «пусть компьютер сам решает, что делать с моей системой».