Хотите, чтобы Codex сам редактировал файлы, запускал команды и не останавливался на каждом шаге с вопросом о разрешении? Включаете «Full Access», а он всё равно спрашивает. Ниже — причина и рабочее решение для полностью автономного запуска, проверенное на Codex CLI v0.145.0.
В чём причина: у Codex нет единственного переключателя «авторежима». Здесь независимо настраиваются песочница — что агенту разрешено трогать — и политика подтверждений — когда он должен остановиться и спросить. Сеть — третий отдельный барьер. Ослабить один из них недостаточно, а после обновления Codex настройки активной сессии могут незаметно вернуться к политике по умолчанию.
Полная автономность в CLI: только --yolo снимает все ограничения сразу. Если хотите сохранить песочницу, но не тратить время на лишние запросы, задайте обе оси явно. Делайте это в начале сессии и перепроверяйте настройки после обновлений.
# Truly hands-off — no sandbox, no prompts (throwaway environment only):
codex --yolo
# Safer — edits freely inside your project, still asks to leave it:
codex --sandbox workspace-write --ask-for-approval on-requestПолная автономность в приложении: откройте меню подтверждений, выберите Full access и повторно включайте этот режим после каждого обновления: апгрейды сбрасывают настройку.
Это краткий ответ. Далее — полная схема режимов, их внутреннее соответствие и рекомендации по выбору.
Три режима Codex: что меняется на практике
Песочница определяет, к чему агент может обращаться: файлам и сети. Политика подтверждений задаёт моменты, когда он останавливается и ждёт разрешения. Авторежимы лишь объединяют эти параметры в готовые пары, причём в десктопном приложении и CLI одни и те же сочетания называются по-разному.
| Название в приложении | Что делает | Эквивалент в CLI |
|---|---|---|
| Ask for approval | Редактирует файлы в рабочей области, запускает обычные локальные команды, но спрашивает разрешение перед выходом в интернет или действиями за пределами рабочей области | sandbox_mode = "workspace-write" + approval_policy = "on-request" |
| Approve for me (текущий режим по умолчанию в приложении) | Границы те же, но подходящие запросы на подтверждение отправляются AI-ревьюеру вместо вас — это Auto-review | вышеуказанное + approvals_reviewer = "auto_review" |
| Full access | Без песочницы и запросов на подтверждение: неограниченный доступ к файлам и сети | sandbox_mode = "danger-full-access" + approval_policy = "never" |
В CLI эти параметры задаются напрямую через --sandbox и --ask-for-approval; переключать пресеты прямо в сессии можно через меню /permissions. Если вы ещё выбираете между клиентами, это отдельный вопрос: здесь мы сравнили Codex и Claude Code. В этой статье речь именно о настройках.
Почему «Full Access» всё равно запрашивает разрешение
Причин три, и они могут срабатывать одновременно.
Песочница и подтверждения — разные настройки. Связка workspace-write + on-request позволяет Codex свободно работать внутри проекта, но останавливает его на границе: при сетевом запросе, доступе к файлу вне репозитория или команде sudo. Если ослабить песочницу, но оставить подтверждения по запросу, уведомления будут появляться при каждом таком переходе.
Для сети действует отдельный барьер. Даже Full Access может отдельно контролировать доступ в интернет, независимо от файловой системы. Как отметил @mxcl (16 июля 2026 года), Codex «cannot use the Internet without full access, ending task until the user enables full access». Права на запись файлов и доступ к сети — не одно и то же.
Обновления сбрасывают режим. В конце июля 2026 года с этим столкнулись несколько пользователей: после обновления Codex активные сессии незаметно возвращались к политике по умолчанию. @s_rafcon (22 июля) написал, что треды «switch their Full access flag to the default flag and [are] stuck asking for approval on every single edit». Выбирайте режим в начале сессии и проверяйте его после каждого обновления.
CLI: --full-auto больше не работает. Чем его заменить
Раньше codex --full-auto был короткой командой для сценария «работай в моём проекте без лишних вопросов»: approval_policy = "on-request" + sandbox_mode = "workspace-write". В интерактивном режиме этот флаг больше не принимается. Проверено на v0.145.0:
$ codex --full-auto
error: unexpected argument '--full-auto' foundВместо него явно задайте оба параметра — это в точности соответствует поведению старого флага:
# The modern replacement for --full-auto
codex --sandbox workspace-write --ask-for-approval on-request
# Or, non-interactive, no prompts but keep the sandbox:
codex -a never -s workspace-write exec "your task"Для скриптов codex exec --full-auto всё ещё принимает флаг; ошибка возникает только у интерактивной команды. Согласно codex --help, для --ask-for-approval доступны значения untrusted / on-request / never, а для --sandbox — read-only / workspace-write / danger-full-access. Каждый «режим» приложения — это сочетание двух таких настроек.
--yolo: когда стоит отключить все барьеры
--yolo — короткий алиас для --dangerously-bypass-approvals-and-sandbox. Это настоящий режим «не вмешиваться»: danger-full-access вместе с never, без границ файловой системы и без запросов на подтверждение. Флаг пережил отказ от --full-auto именно потому, что его название недвусмысленно предупреждает о риске: на v0.145.0 codex --yolo выполняется нормально, тогда как codex --full-auto завершается ошибкой.
Многие опытные пользователи запускают его по умолчанию — и для подходящих задач это оправданно. Но защитой должна быть сама среда: относитесь к машине как к одноразовой.
- Запускайте в одноразовой VM или dev container, а не на основной рабочей машине.
- Сначала удалите из окружения production-учётные данные.
- Держите задачу узкой по объёму, а перед продолжением проверяйте
git diff.
Поскольку --yolo снимает все ограничения, случайные rm -rf, git push или DROP TABLE будут выполнены без вопросов — такова цена скорости. Подключение Codex к self-hosted или Anthropic-compatible endpoint через кастомного провайдера моделей ничего не меняет: песочнице не важно, какая модель стоит за API.
«Approve for me» и Auto-review: когда подтверждает другой AI
Самый новый режим и текущий вариант по умолчанию в приложении — Auto-review. Подходящие действия с повышением прав отправляются отдельному агенту-ревьюеру: небольшой версии Codex на GPT-5.4 Thinking (low), которая одобряет или отклоняет действие с пояснением. OpenAI называет это «заменой ревьюера, а не выдачей разрешений»: режим не расширяет список каталогов для записи и не открывает сеть, а лишь меняет того, кто говорит «да».
По данным собственной оценки OpenAI от 30 апреля 2026 года, Auto-review обращается к человеку примерно в 200 раз реже, чем ручное подтверждение, и одобряет около 99,1% рассмотренных эскалаций — 99,93% среди всех действий. В их иллюстративном примере из 10 000 действий 9 280 были выполнены внутри песочницы без проверки, 720 попали к ревьюеру и лишь 7 были отклонены.
Есть защита от бесконечных отказов: текущий ход прерывается после 3 последовательных отклонений либо после 10 отклонений в скользящем окне из последних 50 проверок. Если работа остановилась, выполните /approve, чтобы открыть список Auto-review Denials и разрешить одно действие для повторной попытки.
Но эти меры безопасности способны тормозить долгие запуски. Пользователи, выполнявшие многочасовые задачи /goal, сообщали в конце июля 2026 года, что периодический вопрос «продолжать ждать?» ломал процессы, которые раньше работали без присмотра днями. OpenAI также прямо предупреждает, что режим «should not be treated as a guarantee of security»: полнота обнаружения в red-team-тестах высока, но не абсолютна — 90,3% для превышения полномочий, 99,3% для prompt injection и 96,1% для misaligned-model. Это хороший режим по умолчанию, но не замена песочнице в критически важных задачах.
Чтобы включить его через конфигурацию, а не интерфейс:
approvals_reviewer = "auto_review"
[auto_review]
policy = """
Describe what the reviewer should allow or block here.
"""Какой режим выбрать
- Обычная локальная разработка:
workspace-write+on-request(«Ask for approval»). За вами остаётся последнее слово во всём, что выходит за пределы репозитория, а именно там кроются реальные риски. - Долгие запуски без постоянного контроля: «Approve for me» (Auto-review). Учтите, что на отмеченных действиях он всё равно останавливается, поэтому это не полностью бесконтактный режим.
- Разовая грубая работа в одноразовой среде:
--yolo. Самый быстрый и самый опасный вариант; он приемлем только там, где среде нельзя навредить. - Чтение или ревью кодовой базы:
read-only. Никаких записей и неожиданностей.
Честный вывод: настройки, которая одновременно давала бы полную автономность и полную безопасность, не существует. Каждый шаг к работе без контроля меняет ваше собственное суждение на решение классификатора. Для рутинных задач это оправданный обмен, а для production-инфраструктуры — плохая идея. Выбирайте режим под конкретную задачу, а не раз и навсегда.
FAQ
Есть ли у Codex авторежим?
Да, но это не один переключатель, а набор пресетов. В приложении это «Ask for approval», «Approve for me» и «Full access»; в CLI аналогичное поведение собирается из --sandbox и --ask-for-approval либо выбирается через /permissions.
Как включить автоматическое подтверждение всех команд в Codex?
Установите approval_policy = "never". В паре с workspace-write Codex перестанет спрашивать внутри песочницы; в паре с danger-full-access, то есть в режиме --yolo, он вообще не будет запрашивать подтверждений. Второй вариант убирает все защитные механизмы, поэтому используйте его только в изолированной среде.
Что такое режим Codex Auto-review?
Auto-review (approvals_reviewer = "auto_review", в интерфейсе — «Approve for me») передаёт решения о подтверждении AI-агенту-ревьюеру вместо вас. Он одобряет примерно 99% рассмотренных действий и обращается к человеку приблизительно в 200 раз реже, но не является гарантией безопасности.
Работает ли --full-auto?
Не в интерактивном CLI. На v0.145.0 команда codex --full-auto возвращает «unexpected argument». Для скриптов codex exec --full-auto всё ещё принимается как устаревший алиас. В интерактивном режиме вместо него используйте --sandbox workspace-write --ask-for-approval on-request.
Безопасен ли режим --yolo?
Нет — именно об этом говорит его название. Он одновременно отключает песочницу и все подтверждения. Использовать его разумно только в одноразовой VM или контейнере, из которого удалены production-учётные данные, а задача жёстко ограничена по объёму.