Инструменты разработчика 11.08.2026 чтения обновлено 11.08.2026

YOLO-режим в Codex: как отключить подтверждения и не потерять при этом проект

YOLO-режим в Codex CLI: что это такое, как включить флагом --yolo или через /permissions, чем он опасен и какие аналоги есть в Claude Code, Gemini CLI, Qwen Code и Aider.

Андрей Сарапулов редактор

YOLO-режим в Codex: как отключить подтверждения и не потерять при этом проект

Коротко

YOLO-режим в Codex – работа без подтверждений и без песочницы: агент сам меняет любые файлы, запускает команды и ходит в сеть. Включается флагом --dangerously-bypass-approvals-and-sandbox (алиас --yolo) или пунктом Full Access в меню /permissions. Безопасно только в контейнере или на одноразовой машине; для повседневной работы разумнее связка --sandbox workspace-write --ask-for-approval never. Аналоги: --dangerously-skip-permissions в Claude Code, --approval-mode=yolo в Gemini CLI, режим YOLO в Qwen Code, --yes-always в Aider.

Что такое YOLO-режим

YOLO (от «you only live once») – неофициальное, но прижившееся название режима, в котором ИИ-агент выполняет любые действия без подтверждения. В Codex это сочетание двух вещей: отключённых запросов на одобрение и отключённой песочницы. Сам Codex в шапке сессии так это и подписывает – permissions: YOLO mode.

Подтверждения и песочница в Codex настраиваются отдельно друг от друга.

Песочница отвечает за то, что агент физически может сделать. На Linux она построена на bubblewrap, на macOS – на Seatbelt. Есть три уровня: read-only (только чтение), workspace-write (чтение плюс запись в рабочую папку) и danger-full-access (без ограничений). Сеть в песочнице по умолчанию закрыта даже в режиме записи.

Политика одобрений отвечает за то, когда Codex останавливается и спрашивает. Значения: untrusted (сам выполняет только заведомо безопасные команды вроде ls и cat), on-request (модель решает сама, когда спросить – это поведение по умолчанию) и never (не спрашивает никогда).

YOLO – это когда обе ручки выкручены: sandbox danger-full-access плюс approval never. Codex получает права вашего пользователя: читать и менять любые файлы, к которым у вас есть доступ, запускать что угодно, ходить в сеть.

Как включить

Самый простой способ – прямо в интерфейсе. Наберите в сессии /permissions и выберите третий пункт.

Меню /permissions в Codex CLI: три уровня доступа

Три пункта тут соответствуют трём сценариям: спрашивать как обычно, спрашивать только про потенциально опасное и не спрашивать вообще.

Второй способ – флаг при запуске:

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

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

codex --yolo "перепиши тесты под новый API"

Ещё одна деталь: --full-auto, который советуют в старых статьях, из свежих версий Codex уже выпилен – на него вы получите error: unexpected argument '--full-auto' found. Его роль теперь играет комбинация флагов.

Флаги Codex CLI: --sandbox, --ask-for-approval и байпас

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

codex --sandbox workspace-write --ask-for-approval never

Так агент перестанет дёргать вас вопросами, но останется заперт в рабочей папке и без интернета. Для большинства «дай уже поработать спокойно» сценариев этого хватает, а риск получить rm -rf по всему домашнему каталогу исчезает.

Если режим нужен постоянно, пропишите его в ~/.codex/config.toml:

approval_policy = "never"
sandbox_mode = "workspace-write"

[sandbox_workspace_write]
network_access = true

Конфиг можно положить и в проект – .codex/config.toml в корне репозитория перебьёт пользовательские настройки. Удобно, когда один проект живёт в контейнере и ему можно больше, а остальные держатся на коротком поводке.

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

Codex в YOLO-режиме выполняет команды без подтверждения

Чем это опасно

Флаг снимает все защиты разом, и ошибки после этого необратимы.

Первое – деструктивные команды. Агент, который неверно понял задачу, спокойно выполнит rm -rf, git reset --hard, git push --force или DROP TABLE. Отката не будет: подтверждение как раз и было точкой, где вы могли сказать «стой».

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

Третье, и самое недооценённое, – инъекции промпта. Агент читает файлы, вывод команд, страницы из интернета, содержимое issue и README. Любой из этих источников может содержать инструкции, адресованные не вам, а модели. В обычном режиме такая попытка упрётся в запрос на подтверждение, в YOLO – выполнится молча.

Поэтому официальная формулировка в самом Codex звучит однозначно: режим предназначен только для сред, изолированных снаружи.

Как пользоваться, не наступая на грабли

Изоляция снаружи, а не внутри. Docker-контейнер, виртуалка, отдельный пользователь в системе, dev-container в редакторе – годится любой вариант, где у процесса нет доступа к вашим ключам и остальным проектам. Проверить, как ведёт себя команда под песочницей Codex, можно и точечно: codex sandbox <команда>.

Отдельная ветка и чистое дерево. Перед запуском стоит закоммитить всё, что дорого. Git тут работает как страховка: git diff покажет, что натворил агент, а git checkout вернёт назад.

Никаких боевых доступов в окружении. Продакшен-креды, ключи от облака, токены с правами на удаление – всё это в сессии с полным доступом лежать не должно.

Промежуточный режим вместо крайности. В Codex есть флаг --approve-for-me: запросы на одобрение уходят на автоматическую проверку, а работа идёт в песочнице workspace-write. В интерфейсе это пункт «Approve for me» – спросят только про то, что выглядит подозрительно. Для повседневной работы это разумнее полного отключения тормозов.

Аналоги в других агентах

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

Claude Code. Ключ --dangerously-skip-permissions, он же --permission-mode bypassPermissions. Anthropic сделала и промежуточный вариант – auto mode, где одобрение выдаёт классификатор вместо человека: входящий контент проверяется на инъекции промпта, а к оценке действий попадает только то, что выходит за пределы проекта – команды в оболочке и обращения к внешним сервисам.

Gemini CLI. Флаг --yolo (короткий -y), в новой форме – --approval-mode=yolo. Прямо в сессии режим переключается по Ctrl+Y. Всего режимов четыре: default, auto_edit, yolo и plan.

Qwen Code. Пять уровней: Plan, Ask Permissions, Auto-Edit, Auto и YOLO, переключаются по Shift+Tab или командой /approval-mode. Режим Auto интересен тем же, чем auto mode у Claude Code: каждую команду оценивает LLM-классификатор, безопасные пропускает, рискованные блокирует.

Aider. Здесь всё аскетично: --yes-always отвечает «да» на любое подтверждение.

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

Кому это нужно

YOLO-режим оправдан, когда среда одноразовая: контейнер под конкретную задачу, CI-раннер, изолированная виртуалка для экспериментов, кластер, где системная песочница конфликтует с собственной песочницей Codex. Там терять нечего, а выигрыш во времени заметный.

На рабочем ноутбуке с боевыми ключами и десятком проектов рядом это плохая идея. Компромисс, который закрывает большинство сценариев, выглядит так: --sandbox workspace-write --ask-for-approval never – агент не отвлекает вопросами, но заперт в рабочей папке. А если хочется совсем спокойно – «Approve for me» и автоматическая проверка подозрительных действий.