Окружение облачных задач Codex: setup-скрипт, кэш и доступ в интернет

Облачная задача Codex падает не потому, что модель плохо пишет код. Она падает потому, что в контейнере не оказалось нужной версии PHP, лок-файл потянул пакет из приватного реестра без токена, а тест полез в интернет, которого в этот момент уже нет. Модель тут ни при чём: всё перечисленное — настройки окружения, и все они в ваших руках. Разберём этот контейнер по слоям: что в нём уже стоит, что делает ваш скрипт, что переживает между задачами, а что стирается перед тем, как агент возьмётся за работу.

Всё ниже сверено по документации OpenAI и открытым обсуждениям на 11 августа 2026.

Коротко (TL;DR)

• Окружение — отдельный настраиваемый объект, привязанный к репозиторию. Живёт в настройках Codex, а не в файлах проекта, и переиспользуется всеми задачами по этому репозиторию.
• У задачи два разных бюджета доверия. Фаза установки получает интернет и секреты, но не видит модель. Фаза агента получает модель, но лишается секретов и по умолчанию остаётся без сети.
• Setup-скрипт запускается один раз, а его результат кэшируется — до 12 часов. Любая правка скрипта, переменной или секрета кэш обнуляет.
• Секреты удаляются перед фазой агента. Это не настройка, а архитектурное решение: интеграционный тест с живым ключом в облаке не пройдёт, и обходить это опасно.
• Главный источник падений — сеть и версии. Оба лечатся до постановки задачи: зависимости ставятся в скрипте, версии рантаймов пинятся, домены заносятся в аллоулист.

Окружение Codex Cloud: что это за объект и где он настраивается

Окружение (environment) — это описание контейнера, в котором будет выполняться облачная задача: базовый образ, версии рантаймов, скрипт установки, переменные, секреты и политика доступа в сеть. Задаётся оно один раз на репозиторий на странице настроек окружений в интерфейсе Codex, и все последующие задачи по этому репозиторию берут его как заготовку.

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

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

• Окружение облачной задачи — то, о чём эта статья. Живёт в веб-настройках, описывает контейнер OpenAI.
• Локальный config.toml — настройки Codex CLI на вашей машине: модель, песочница, политика одобрений. К облачному контейнеру отношения не имеет.
• AGENTS.md — инструкция проекта, которую агент читает уже внутри контейнера: какой командой гонять тесты, куда не лезть. Окружение готовит инструменты, а файл AGENTS.md объясняет, что с ними делать.

Разница между локальным и облачным запуском здесь принципиальная. Когда вы работаете в терминале, агент видит вашу машину со всем, что вы туда годами доставляли. В облаке машины нет: есть чистый контейнер, поднятый под задачу, и в нём ровно то, что вы описали. Три поверхности продукта и их отличия разобраны отдельно — в уроке про три способа запустить Codex; здесь важно одно следствие: в облаке «у меня работает» не аргумент, работать должно у контейнера.

MCP-серверы в Codex: config.toml, транспорты и отладка молчащего сервера

config.toml и профили Codex: 6 слоёв приоритета и запретные ключи проекта

Сессия Codex CLI на час работы: команды, расход контекста и откат через git

Codex CLI против Codex Cloud: десять критериев выбора под задачу

DeepSeek Harness вышел под MIT: открытый каркас ИИ-агентов, где всё плагин

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

Жизнь облачной задачи по этапам: где вы ещё можете вмешаться

Порядок этапов важнее, чем список настроек: половина проблем возникает из-за попытки настроить то, что на этом этапе уже недоступно. Маршрут задачи от постановки до готового pull request разобран в уроке про облачные задачи Codex — ниже тот же маршрут, но глазами окружения.

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

Образ universal: какие рантаймы уже стоят и как пинить версии

Контейнер поднимается не из пустоты, а из образа universal, в который OpenAI заранее положила распространённые языки, пакеты и инструменты. Публичный референс этого образа выложен как openai/codex-universal — его можно скачать и посмотреть своими глазами.

Версии рантаймов не собираются заново на каждую задачу: образ подставляет нужную по переменной CODEX_ENV_*, что заметно быстрее установки с нуля. Допустимые значения на 11 августа 2026:

Поверх рантаймов в образе уже лежит обвязка, которую иначе пришлось бы ставить руками: для Python — pyenv, poetry, uv, ruff, black, mypy, pyright, isort; для Node — corepack, npm, yarn, pnpm; отдельно bun, bazelisk, Erlang и Elixir.

BYBIT EARNЗаставь крипту работатьПроценты на USDT и BTC без блокировки — деньги остаются под рукой.Разместить

Проверьте свой стек по этому списку до того, как писать скрипт. Если проект на Python или Node, скрипт может вообще не понадобиться: для npm, yarn, pnpm, pip, pipenv и poetry Codex умеет ставить зависимости сам, опираясь на лок-файл. А вот PHP в образе нет — в практическом разборе настройки под Symfony автор ставит php8.4 с расширениями через apt и подкладывает Composer с проверкой контрольной суммы установщика. То же касается баз данных: PostgreSQL поднимается и инициализируется тем же скриптом.

Setup-скрипт: когда он запускается и что успевает сделать

Setup-скрипт — обычный bash, который выполняется после выкладки кода и до того, как агент получит управление. Три его свойства определяют почти всё остальное.

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

Скрипт идёт в отдельной bash-сессии. Документация предупреждает: команды вроде export до фазы агента не доживают. Переменную, которая нужна агенту, дописывают в ~/.bashrc или задают в настройках окружения — тогда она будет и в установке, и в работе.

Время не бесконечно. Предел измеряется минутами. В июне 2025 участники сообщества OpenAI ловили обрыв на пятой минуте при объявленных десяти; сотрудник OpenAI подтвердил, что это ошибка, и починил её в тот же день. Тогда же прозвучала жалоба, что и десяти минут не хватает: установка тяжёлых библиотек падала на 600 секундах «совсем близко к концу». Практический вывод не зависит от текущего значения лимита — тяжёлую сборку из установочного скрипта надо выносить, а не надеяться дотянуть.

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

#!/usr/bin/env bash
set -euo pipefail

# 1. Системные пакеты: самое медленное и самое редко меняющееся
apt-get update -qq
apt-get install -y -qq libpq-dev

# 2. Зависимости проекта строго по лок-файлу.
#    --frozen-lockfile не даст скрипту молча обновить дерево,
#    --ignore-scripts спасает, когда postinstall лезет в сеть.
pnpm install --frozen-lockfile --ignore-scripts

# 3. Переменная, которая нужна агенту: export её не переживёт
echo 'export APP_ENV=test' >> ~/.bashrc

# 4. Самопроверка: пусть скрипт падает здесь, а не в руках агента
node --version
pnpm --version
pnpm exec tsc --version

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

Кэш контейнера и maintenance-скрипт: тёплый старт против холодного

Гонять полную установку на каждую задачу было бы расточительно, поэтому Codex кэширует состояние контейнера — до 12 часов. Первая задача в репозитории идёт холодным стартом и платит за установку; следующие берут тёплый контейнер и стартуют заметно быстрее.

Кэш обнуляется автоматически, если вы поменяли setup-скрипт, maintenance-скрипт, переменные окружения или секреты. Сбросить его руками можно кнопкой Reset cache на странице окружения — это нужно, когда репозиторий изменился так, что старое состояние стало несовместимым, например после мажорного обновления зависимостей. В планах Business и Enterprise кэш общий для всех, у кого есть доступ к окружению, поэтому сброс задевает всю команду.

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

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

Есть важная оговорка. Двенадцать часов — это потолок, а не обещание. С 29 мая 2026 висит открытая заявка #25086, где автор с логированием в обоих скриптах показывает: полная установка выполняется на каждой новой сессии, файлы из /tmp в следующую задачу не переходят, и повторный запуск «заметно внутри 12 часов» всё равно идёт как холодный. На 11 августа 2026 ответа мейнтейнеров в заявке нет.

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

Переменные окружения и секреты: кто доживает до фазы агента

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

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

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

Обход существует — положить ключ в переменные окружения вместо секретов. Но тогда он перестаёт быть секретом в прямом смысле: попадает в контекст модели и в команды, которые она запускает. Возражение из той же ветки сформулировано жёстко: автор не готов отдавать модели секреты, которые окажутся у неё в контексте, потому что это даёт ей полную свободу действий с ними. Рабочая развязка обычно такая: в облаке — сборка, линт и юнит-тесты; интеграционные прогоны — локально после появления pull request. Если ключ всё же нужен, разумно завести отдельный, с минимальными правами и коротким сроком, а не подкладывать рабочий.

Отдельная ловушка — путаница со списками переменных. Официальный реестр переменных Codex (CODEX_HOME, CODEX_API_KEY, CODEX_ACCESS_TOKEN, RUST_LOG и прочие) описывает CLI и app-server, то есть локальный инструмент. К облачной задаче он не относится: переменные окружения задаются в настройках окружения и в документации по именам не перечислены. «Я задал переменную, а её нет» чаще всего означает, что настройка сделана не в том слое.

Приватные реестры пакетов: как поставить закрытые зависимости

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

#!/usr/bin/env bash
set -euo pipefail

# npm: токен приходит из СЕКРЕТА окружения, в репозитории его нет
npm config set "//registry.npmjs.org/:_authToken=${NPM_TOKEN}"
npm ci

# Composer: приватные пакеты авторизуются секретом COMPOSER_AUTH в формате JSON
composer install --no-interaction --prefer-dist

# git и gh: переменную с именем GITHUB_TOKEN нужно СНЯТЬ перед логином,
# иначе установка падает — Codex проверяет это сам
token="${GITHUB_TOKEN}"
unset GITHUB_TOKEN
echo "$token" | gh auth login --with-token
gh auth setup-git

Про unset стоит сказать отдельно, потому что ошибка выглядит необъяснимо. В рецепте из сообщества это подано прямым текстом: Codex Cloud сам требует, чтобы переменная была снята, иначе установка упадёт на этапе setup. Скрипт при этом сначала копирует значение в локальную переменную и только потом снимает исходную — иначе снимать будет нечего.

Второй момент: gh в образе может не оказаться, и его ставят тем же apt в начале скрипта. А в maintenance-скрипт из всего этого блока попадает только переустановка адреса удалённого репозитория — повторно логиниться при тёплом старте не нужно.

Прокси и аллоулист: сеть включена, а нужный хост недоступен

Сами режимы доступа, готовые пресеты списка доменов и урезание HTTP-методов подробно разобраны в уроке про режимы одобрения и песочницу Codex — пересказывать их здесь незачем. Вопрос этого раздела другой: как настроить сеть окружения так, чтобы задача не спотыкалась о то, чего в списке настроек не видно.

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

Отсюда порядок, который экономит и время, и риск:

1. Сначала попробуйте обойтись без сети вообще. Если всё поставлено в скрипте, а тесты не ходят во внешние API, доступ агенту не нужен. Это самая безопасная и самая быстрая конфигурация — и она же самая частая рабочая.
2. Понадобилась сеть — открывайте её по факту, а не про запас. Домен добавляется под конкретное падение в логе. Каждый лишний хост в списке — это и лишний риск, и лишний источник загадочных отказов, которые потом придётся исключать.
3. Проверяйте не только свой список. Отказ приходит не только от политики окружения — и вот это съедает больше всего времени, потому что лечить пытаются не там. Разбираем ниже.

И главная неочевидная деталь: весь исходящий трафик задачи идёт через HTTP/HTTPS-прокси окружения. Из этого следуют два практических вывода.

Первый: «интернет включён» не равно «нужный хост доступен». В большой ветке Elixir-сообщества, идущей с октября 2025, участники получали от реестра пакетов 403 Forbidden и ошибку установки TLS-туннеля именно в фазе установки, где сеть формально есть; при этом установка того же инструмента напрямую из GitHub проходила. Финального решения в ветке нет, а рабочая гипотеза участников — блокировка на стороне самого реестра. Если у вас похожая картина, проверяйте не только свой аллоулист, но и то, не отказывает ли вам сам хост.

Второй: инструменты со своим хранилищем корневых сертификатов прокси не доверяют и падают на проверке. Внутри контейнера для этого есть переменная CODEX_PROXY_CERT с сертификатом прокси — в документации она не описана, её нашли на практике. Лечение — одна строка в setup-скрипте, которая указывает инструменту на этот сертификат:

export SSL_CERT_FILE="$CODEX_PROXY_CERT"
export REQUESTS_CA_BUNDLE="$CODEX_PROXY_CERT"

Имена переменных зависят от инструмента: у Hex это HEX_CACERTS_PATH, у Python-библиотек — REQUESTS_CA_BUNDLE, у многих утилит хватает SSL_CERT_FILE. Поскольку переменная официально не документирована, полагаться на неё как на стабильный контракт не стоит: проверьте, что она есть, и держите в скрипте ветку на случай её отсутствия.

Типовые падения облачной задачи и слой, на котором они лечатся

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

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

Локальная отладка в codex-universal: собрать то же окружение у себя

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

docker pull ghcr.io/openai/codex-universal:latest

docker run --rm -it \
  -e CODEX_ENV_PYTHON_VERSION=3.12 \
  -e CODEX_ENV_NODE_VERSION=20 \
  -v "$(pwd)":/workspace/"$(basename "$(pwd)")" \
  -w /workspace/"$(basename "$(pwd)")" \
  ghcr.io/openai/codex-universal:latest

Дальше внутри контейнера прогоняете свой setup-скрипт как есть и смотрите, где он спотыкается. Обратите внимание на путь монтирования: репозиторий кладётся в /workspace/<имя-репозитория> — так же, как это делает облако, и скрипты, завязанные на абсолютные пути, ведут себя одинаково.

У метода есть честные границы, и они названы в самом репозитории образа: это референсная реализация, а не идентичное окружение. На amd64 недоступна одна из сборок OpenJDK, в arm64-варианте пропущен Swift. Плюс локально у вас нет прокси окружения и нет удаления секретов перед фазой агента — то есть сетевые и секретные сценарии образ не воспроизводит. Он отвечает на вопрос «есть ли в контейнере нужные инструменты и проходит ли мой скрипт», и на этот вопрос отвечает достоверно.

Ещё одно наблюдение, полезное для планирования: конфигурация окружения пока не скриптуется — она живёт только в веб-настройках, а заявка на управление окружениями из кода (issue #24777 в репозитории Codex) на 11 августа 2026 остаётся открытой. Практический ответ на это — держать воспроизводимость в самом репозитории: пусть в веб-поле стоит одна строка вызова файла scripts/codex-setup.sh, а вся логика лежит в этом файле под контролем версий. Тогда история изменений окружения читается в git, а не восстанавливается по памяти.

Риски настроенного окружения: секреты, сеть и общий кэш

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

• Секрет, переложенный в переменные ради фазы агента, перестаёт быть секретом. Он оказывается в контексте модели и в командах, которые она выполняет. Если без ключа не обойтись — отдельный ключ с минимальными правами и коротким сроком, а не рабочий.
• Включённая сеть в фазе агента — это вектор атаки, а не удобство. Инструкция, спрятанная в тексте страницы или тикета, может стать командой; уходящий наружу запрос может унести код. Именно поэтому OpenAI держит сеть выключенной по умолчанию, а не потому, что так проще.
• Сброс кэша в Business и Enterprise задевает всех, у кого есть доступ к окружению. Серия мелких правок переменных перед рабочим днём команды — это серия холодных стартов у коллег.
• Предел времени установки не резиновый. Скрипт, который сегодня укладывается в лимит с запасом в двадцать секунд, завтра не уложится: реестр ответит медленнее, зависимость подрастёт.
• Формально включённый интернет не гарантирует доступности хоста — отказ может прийти со стороны самого реестра, и в вашем аллоулисте лечить будет нечего.
• И противовес, чтобы картина была полной: дефолты здесь выбраны в пользу безопасности, а не удобства, и это правильный компромисс. Отключённая сеть и стирание секретов делают утечку дорогой по умолчанию, а не после того, как вы про неё вспомните.

Что в настройках окружения Codex устареет первым

Продукт меняется быстро, поэтому полезно понимать, какие части этого материала стареют раньше остальных. Быстрее всего поедут версии рантаймов в образе: их список у OpenAI обновляется вместе с релизами языков, и сверять его нужно по репозиторию образа, а не по статьям. За ними — состав пресета Common dependencies и названия элементов интерфейса: кнопки и пункты настроек переименовывают без объявлений. Третьим — предел времени setup-скрипта: он уже менялся и, судя по обсуждениям, будет меняться дальше.

Устойчивая часть, на которую можно опираться, — сама модель: две фазы с разными правами, кэш с инвалидацией по изменению конфигурации, секреты только для установки, сеть агенту по умолчанию закрыта. За свежими значениями идите в документацию окружений и в репозиторий образа; за реальным поведением, которое в документацию ещё не попало, — в открытые заявки репозитория Codex.

FAQ

Почему задача Codex падает на установке зависимостей, если локально всё ставится?

Почти всегда потому, что установка попала в фазу агента, где интернета по умолчанию нет: менеджер пакетов не может открыть соединение с реестром. Лечится переносом установки в setup-скрипт, где сеть доступна. Второй по частоте случай — инструмента просто нет в базовом образе, и его нужно поставить тем же скриптом.

Можно ли дать агенту Codex ключ к внешнему API в облачной задаче?

Технически да — если положить его в переменные окружения, а не в секреты: они действуют всю задачу, включая работу агента. Но тогда ключ попадает в контекст модели, и это уже не секрет. Разумнее оставить в облаке сборку и юнит-тесты, а интеграционные прогоны делать локально после появления pull request.

Что делать, если setup-скрипт не успевает установить тяжёлые зависимости?

Убирать из установки то, что можно не собирать: ставить готовые сборки вместо компиляции, ограничивать зависимости нужной группой, кэшировать артефакты в образе проекта. Волатильные шаги стоит перенести в maintenance-скрипт, который выполняется на тёплом старте. Надеяться дотянуть до предела времени не стоит — он уже менялся и не рассчитан на длинные сборки.

Как заставить Codex переустановить окружение с нуля?

Нажать Reset cache на странице окружения — это сбрасывает кэшированное состояние контейнера, и следующая задача пойдёт холодным стартом. Тот же эффект даёт любая правка setup-скрипта, maintenance-скрипта, переменных или секретов: кэш инвалидируется автоматически. В планах Business и Enterprise сброс касается всех, у кого есть доступ к окружению.

Нужно ли включать интернет в фазе агента, если зависимости уже стоят?

Как правило нет, и это лучший вариант по умолчанию. Сеть агенту нужна в двух случаях: тесты обращаются к внешнему сервису либо агент должен что-то докачать по ходу работы. Если включаете, оставьте узкий список доменов и по возможности урежьте методы до чтения — так вектор утечки остаётся минимальным.

Можно ли держать конфигурацию окружения Codex Cloud в репозитории?

Целиком пока нет: окружения настраиваются в веб-интерфейсе, а заявка на управление ими из кода на 11 августа 2026 открыта. Рабочий обходной путь — оставить в веб-поле только вызов файла вида bash scripts/codex-setup.sh, а всю логику установки держать в репозитории. Тогда изменения окружения проходят ревью и видны в истории git.