Codex под контролем: как песочница и одобрения решают, что агенту можно

Codex умеет сам редактировать файлы и запускать команды — и ровно поэтому вопрос «а что ему вообще позволено» перестаёт быть теоретическим. Большинство путается, потому что ищет «один режим». На деле у Codex два независимых регулятора: песочница решает, что агент технически может сделать, а политика одобрений — когда он обязан остановиться и спросить. Привычные названия «read-only», «auto», «full access» — это просто удобные комбинации этих двух регуляторов.

В этом разборе — как оба механизма устроены по отдельности, как складываются в пресеты, что происходит с доступом в сеть (локально и в облаке) и, главное, готовая матрица: какой режим брать на своём проекте, а какой — когда открываешь чужой незнакомый код. Данные актуальны на 17 июля 2026; имена флагов и значения политики меняются от версии к версии — где смотреть свежее, укажу в конце.

Sandbox и approval в Codex: два регулятора, а не один «режим»

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

Песочница (sandbox) — это про «что можно физически». Она ограничивает файловую систему и сеть на уровне процесса: куда агент может писать, откуда только читать, есть ли выход в интернет. Даже если модель сгенерирует опасную команду, песочница не даст ей выйти за свои границы.

SpaceX · xStockSpaceX — частная компания. Торгуй её токеном на Bybit за крипту.Торговать SpaceX →

Политика одобрений (approval policy) — это про «когда спросить». Она определяет, в какой момент Codex ставит выполнение на паузу и просит вашего подтверждения: перед выходом за пределы песочницы, перед доступом в сеть, перед командой вне доверенного набора.

Codex для не-программиста: как собрать первый рабочий продукт

Один продукт на Codex: как довести идею до живого URL, не утонув в коде

AGENTS.md: инструкция, которую агент Codex действительно читает перед работой

Codex — не чат-бот, а агент: как формулировать задачи, чтобы он делал их правильно

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

Разница принципиальная. Можно поставить «пиши в проект без вопросов» (свободные одобрения), но при этом «в интернет — нельзя» (жёсткая песочница). А можно наоборот: «читать что угодно, но любое изменение — только с моего разрешения». Именно комбинация двух настроек и даёт нужный баланс автономности и контроля, а не один волшебный переключатель.

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

Песочница Codex: три режима доступа

Песочница задаётся параметром sandbox_mode и имеет три уровня — от самого строгого «codex read-only режим», где агент только читает, до полного доступа.

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

workspace-write — рабочий режим по умолчанию для локальной разработки. Codex читает и правит файлы внутри текущей рабочей папки и запускает обычные локальные команды, но не выходит за её пределы. Важный нюанс: даже в этом режиме служебные каталоги .git, .codex и .agents остаются доступны только для чтения — агент не перепишет вашу историю коммитов и собственный конфиг. Расширить список папок для записи можно ключом writable_roots.

danger-full-access — песочница снимается полностью: пропадают и файловые, и сетевые границы. Название с «danger» не для красоты. Этот режим оправдан только там, где окружение и так изолировано (одноразовый контейнер), а не на рабочем ноутбуке с доступом к вашим ключам и репозиториям.

Bybit · Rewards Hubдо $30,100Внеси депозит, торгуй 14 дней — и забери награды в Rewards HubЗабрать бонус →

Технически песочница опирается на средства операционной системы: на macOS это встроенный механизм Seatbelt, на Linux — Landlock и seccomp (через развёртывание изолированного пространства, обычно с помощью bubblewrap), на Windows работает нативная песочница или Linux-реализация при запуске через WSL2. Знать детали не обязательно, но полезно понимать: границы держит ОС, а не «обещание» модели.

Политика одобрений: когда Codex остановится спросить

Второй регулятор — approval_policy (в англоязычной документации «codex approval mode»). Он не про границы, а про частоту вопросов внутри этих границ.

Отдельно отмечу on-failure: во многих гайдах он всё ещё числится как рабочий вариант «работай свободно, спроси при ошибке». В актуальной конфигурационной документации на дату проверки это значение помечено как устаревшее — используйте on-request или never. Это как раз тот случай, где старые статьи вводят в заблуждение.

Есть и продвинутый, «гранулярный» вид политики — объект с отдельными флагами на разные типы запросов (одобрение выхода из песочницы, правил, вызовов MCP-инструментов и так далее). MCP здесь — протокол, которым Codex подключает внешние инструменты и сервисы; его вызовы можно проводить через одобрение отдельно от остальных команд. Он нужен, когда стандартных трёх значений мало и хочется тонко развести, что спрашивать, а что нет.

Наконец, кто отвечает на запросы одобрения, тоже настраивается: ключ approvals_reviewer по умолчанию user (спрашивают вас), но может быть auto_review — тогда подходящие запросы проходят через агента-ревьюера, а не всплывают вам на экран.

Как режимы складываются в пресеты Read Only / Auto / Full Access

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

• Read Only — --sandbox read-only --ask-for-approval on-request. Codex читает файлы и отвечает на вопросы; на любое изменение, запуск команды или доступ к сети просит разрешение.
• Auto (по умолчанию) — --sandbox workspace-write --ask-for-approval on-request. Агент сам читает, редактирует и запускает команды в рабочей папке, но спрашивает, чтобы выйти за её пределы или получить сетевой доступ. Это режим, который закрывает большую часть повседневной работы без риска, что агент уйдёт за границы проекта.
• Full Access — флаг --dangerously-bypass-approvals-and-sandbox (короткий алиас --yolo). Снимает и песочницу, и вопросы. Максимум автономности — и максимум ответственности на вас.

Флаги можно комбинировать и вручную: --sandbox задаёт песочницу, --ask-for-approval — политику. Флаг --full-auto устарел (при запуске Codex выводит предупреждение) — раньше он включал пару workspace-write без лишних вопросов. Современная замена — явный флаг --sandbox workspace-write.

Здесь же понятно, чем «codex full access» отличается от «auto»: в auto сеть и выход из папки под запросом, а в full access — нет ни песочницы, ни запросов вообще.

Сетевой доступ: локально и в облаке — это разные истории

Сеть — самое частое место, где что-то «не работает», и одновременно самая чувствительная настройка с точки зрения безопасности.

Локально (Codex CLI). В режиме workspace-write сеть по умолчанию выключена. Это осознанное решение разработчиков: агент, у которого есть выход в интернет и который читает недоверенный контент, — потенциальная мишень для промпт-инъекции. Включается сеть отдельно, в таблице [sandbox_workspace_write] ключом network_access = true. На практике это выглядит так: команда, которой нужна сеть (например, npm install или curl), падает внутри песочницы, и при политике on-request Codex спрашивает, выполнить ли её вне песочницы. Если агенту действительно нужен поиск в интернете, разумнее не открывать сеть нараспашку, а разобраться, какой web search API подключить агенту под конкретную задачу.

В облаке (Codex Cloud). Здесь модель доступа устроена аккуратнее и заслуживает отдельного внимания, потому что конкуренты её почти не разбирают. У облачной задачи две фазы. Фаза setup-скрипта запускается с доступом в интернет — чтобы поставить зависимости. А вот фаза агента по умолчанию идёт без интернета. Агентский доступ настраивается на уровне окружения и имеет два состояния:

• Off (по умолчанию) — интернет для агента полностью закрыт.
• On — доступ есть, и его можно сузить: ограничить разрешённым списком доменов (allowlist) и списком допустимых HTTP-методов. То есть «ограниченный доступ» — это не отдельный третий тумблер, а тот же On с надетыми ограничениями.

Для сужения доменов предлагают преднастроенные списки: None (пустой, домены добавляете сами), Common dependencies (популярные репозитории — npm, PyPI, Docker, GitHub и подобные) и All (без ограничений). Методы можно урезать — например, оставить только GET, HEAD и OPTIONS, заблокировав POST, PUT, DELETE и прочие изменяющие запросы. Весь исходящий трафик при этом идёт через HTTP/HTTPS-прокси, а состояние контейнера кэшируется до 12 часов.

Похожая логика «разрешить публичный интернет отдельной настройкой» есть и у смежного агента OpenAI — ChatGPT Work: доступ к сети там тоже включается сознательно, а не по умолчанию.

Матрица «песочница × одобрения»: когда что брать

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

Разложу три частых config.toml. Файл лежит в $CODEX_HOME/config.toml (по умолчанию ~/.codex/config.toml).

Свой проект, низкое трение:

approval_policy = "on-request"
sandbox_mode = "workspace-write"

Чужой или недоверенный код на рабочей машине (разумные значения по умолчанию — сеть выключена):

approval_policy = "untrusted"
sandbox_mode = "workspace-write"

[sandbox_workspace_write]
network_access = false

Неинтерактивный CI-прогон, где окружение само ограничивает ущерб:

approval_policy = "never"
sandbox_mode = "read-only"

Смысл матрицы: не искать «правильный режим вообще», а под каждую задачу подбирать пару «границы + частота вопросов».

config.toml и профили доступа: точная настройка

Когда трёх пресетов мало, в дело идут именованные профили. Codex различает доверенные и недоверенные проекты: конфигурация из папки проекта (слой .codex/) подхватывается только для доверенного проекта; недоверенный откатывается к пользовательским, системным и встроенным значениям. Это защищает от того, чтобы чужой репозиторий втихую навязал вам свои настройки доступа.

Профили доступа (permission profiles) — это именованные комбинации песочницы и политики под разные контексты. Встроенные профили: :read-only, :workspace и :danger-full-access. Свой профиль описывается секцией [permissions.<имя>], а какой из них считать профилем по умолчанию — задаёт ключ default_permissions (можно указать имя своего профиля или один из встроенных).

Полезные ключи таблицы [sandbox_workspace_write] для тонкой настройки записи:

• network_access — выход в сеть внутри песочницы (по умолчанию false);
• writable_roots — дополнительные каталоги, куда разрешена запись;
• exclude_tmpdir_env_var и exclude_slash_tmp — исключить $TMPDIR и /tmp из записываемых путей.

Отдельная хорошая привычка — не пускать в шелл агента лишние секреты: политикой окружения (shell_environment_policy) можно исключить чувствительные переменные вроде ключей доступа к облаку, чтобы они не утекли в команды.

Риски и типичные ошибки

Вот где это ломается на практике — потому что «включил full access, и всё летает» заканчивается предсказуемо.

• danger-full-access / --yolo на рабочей машине. Снятая песочница на ноутбуке, где есть доступ к репозиториям, облачным ключам и почте, — это готовый канал эксфильтрации, если модель выполнит неудачную команду. Держите полный доступ только в одноразовом изолированном контейнере.
• network_access = true без нужды. Как только у агента появляется сеть и он читает недоверенный веб-контент, открывается вектор промпт-инъекции: инструкция, спрятанная на странице или в зависимости, может увести агента с задачи. Включённый интернет — это ещё и риск утечки кода и секретов и загрузки уязвимых зависимостей. Относитесь к каждому true как к отдельному осознанному решению.
• Слепая вера в read-only. Режим задуман как «только чтение», но у Codex открытыми числились баги, когда через MCP-инструменты или отдельные пути запись всё же проходила (issues #4152 и #12896 в репозитории на 17 июля 2026). Вывод не «режим бесполезен», а «критичное всё равно запускайте в изолированном окружении, а не только полагаясь на флаг».
• never без жёсткой песочницы. Отключить вопросы и оставить широкую песочницу — значит получить агента без тормозов. never оправдан только когда границы держит что-то ещё (read-only или контейнер).
• Ретрай без песочницы «на автомате». Когда команда падает из-за отсутствия сети, легко машинально одобрить её выполнение вне песочницы. Прежде чем нажать «да», убедитесь, что это действительно npm install, а не что-то, чему выход наружу не нужен.

Баланс при этом простой: правильно выбранный узкий профиль не тормозит работу, а страхует. Auto закрывает большую часть повседневных задач без единого лишнего риска — а расширенный доступ вы включаете точечно и осознанно.

Что в песочнице Codex устареет первым: имена флагов и пресеты

Имена флагов, набор значений политики одобрений и состав пресетов Codex меняет часто (свежий пример — устаревший on-failure). Прежде чем закладывать режим в свой config.toml или CI, сверяйтесь с актуальной конфигурационной документацией Codex и справкой codex --help. Данные в этом разборе проверены на 17 июля 2026.

FAQ

Чем песочница отличается от политики одобрений? Песочница определяет, что агент технически может сделать (куда писать, есть ли сеть). Политика одобрений — когда он останавливается и спрашивает разрешение. Это два независимых регулятора: пресеты Read Only, Auto и Full Access — просто их удобные комбинации.

Какой режим Codex стоит по умолчанию? Auto: песочница workspace-write плюс политика on-request. Агент сам работает внутри рабочей папки, но спрашивает, чтобы выйти за её пределы или получить доступ в сеть.

Есть ли у Codex интернет по умолчанию? Нет. Локально в workspace-write сеть выключена и включается ключом network_access = true. В Codex Cloud интернет агенту тоже закрыт по умолчанию (Off), хотя фаза установки зависимостей выполняется с доступом в сеть.

Как безопасно запустить Codex на чужом незнакомом коде? Начните с пресета Read Only (read-only + on-request): агент прочитает и объяснит проект, но ничего не изменит без вашего разрешения. Сеть не открывайте. Так вы оценили код, ничем не рискнув.

Что делает --yolo и когда он допустим? --yolo (он же --dangerously-bypass-approvals-and-sandbox) снимает и песочницу, и запросы одобрения — полная автономность. Допустим только в одноразовом изолированном контейнере, никогда — на рабочей машине с доступом к вашим ключам и репозиториям.

Куда писать настройки режимов? В config.toml в каталоге $CODEX_HOME (по умолчанию ~/.codex/config.toml) ключами sandbox_mode, approval_policy и таблицей [sandbox_workspace_write]. Для разных контекстов удобны именованные профили [permissions.<имя>] и ключ default_permissions.