Облачные окружения: настройка, секреты, интернет

Облачная задача Codex работает в отдельной виртуальной машине и продолжается, даже когда ваш ноутбук спит. Чтобы такая задача могла собрать проект и прогнать тесты, ей нужно окружение: репозитории, зависимости, инструменты, доступы. Как делегировать задачи в облако, разобрано в уроке «Облачные задачи». Здесь — про само окружение: как его подготовить, куда класть секреты и сколько интернета давать агенту.

Два облака

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

	Codex Cloud	Codex Cloud (Legacy)
Когда появился	переиспользуемые окружения — DevDay 2026, конец сентября	исходный облачный режим
Как готовится окружение	Codex сам изучает репозитории, ставит зависимости и проверяет настройку вместе с вами	вы пишете setup-скрипт
Для чего ещё нужен	основной режим для облачных задач	ревью кода и интеграции с GitHub и Linear
Будущее	развивается	OpenAI планирует вывести из эксплуатации

Облачные задачи в обоих режимах требуют входа через аккаунт ChatGPT: API-ключ здесь не подходит.

Что это значит для GitLab

Важное ограничение: новые облачные окружения на октябрь 2026 года не поддерживают GitLab и self-hosted GitHub Enterprise Server. Документация указывает это как известное ограничение и обещает поддержку в планах. При создании окружения выбираются репозитории GitHub.

Для проектов агентства в GitLab это значит:

• Интеграция Codex с GitLab (beta) использует свои окружения проекта (project environment), которые настраиваются отдельно от новых переиспользуемых окружений; по какой механике они работают, уточняйте в документации интеграции. Они нужны, чтобы Codex по комментарию @codex fix ... мог править код и пушить в ветку MR. Для ревью в self-managed достаточно webhook группы, см. урок «Автоматическое ревью merge request».
• Для автоматизации на своей инфраструктуре остаются раннеры GitLab и codex exec — им посвящена первая половина курса.
• Клиентские проекты на GitHub могут пользоваться новыми окружениями полностью.

Создание и публикация

Окружение создаётся на вебе или в десктопном приложении: в новой задаче выберите облако как место работы и создайте окружение, либо зайдите в настройки Codex Cloud.

1. Выберите репозитории, которые нужно клонировать.
2. Запустите подготовку: Codex изучит репозитории, установит зависимости и инструменты, проверит рабочий процесс.
3. Ответьте на вопросы, если не хватает доступов или данных. Можно сразу попросить конкретные версии, команды или сервисы: «PHP 8.3, Composer, MySQL 8, после установки прогони phpunit».
4. Проверьте отчёт о настройке, конфигурацию и файлы и нажмите Publish.

Проверенная настройка записывается в два поля:

• Install script — команды установки зависимостей и подготовки ресурсов;
• Start skill — инструкции по запуску сервисов и проверке, что они готовы.

Как переиспользуется состояние:

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

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

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

Переменные и секреты

У окружения два способа передать значение, и разница принципиальная.

	Переменная окружения	Сетевой секрет
Для чего	значение, которое программа читает напрямую	учётные данные для конкретного HTTPS-сервиса
Как доставляется	передаётся программам как есть	программа видит заглушку, прокси подставляет настоящее значение
Где действует	везде в окружении	только для разрешённых доменов по HTTPS на порту 443

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

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

Доступ в интернет

Доступ включается переключателем Allow Codex to access internet, дальше выбирается набор доменов:

• Package managers — предустановленный список реестров: npm, PyPI, crates.io, Maven, репозитории Ubuntu и Debian, GitHub и другие;
• Custom domains only — только ваш список;
• All (unrestricted) — без ограничений.

Дополнительные домены добавляются отдельным списком. Для зарегистрированного корневого домена автоматически разрешается вариант с www, другие поддомены нужно добавлять явно. В Enterprise поверх настроек окружения действуют правила Agent Security, которые задаёт администратор.

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

Для внутренних сервисов есть VPN: на октябрь 2026 года поддерживается Tailscale. Ключ авторизации создаётся с опциями Reusable и Ephemeral: первая позволяет новым машинам задач подключаться, вторая убирает отключившиеся устройства. Для облачных ресурсов в Enterprise по запросу доступен OIDC: задача получает короткоживущие учётные данные AWS, Google Cloud или Azure без постоянных ключей. Поддержка зависит от сервиса — таблица совместимости есть в документации.

Legacy: что важно знать

Если вы настраиваете окружения для ревью кода или интеграций с GitHub и Linear, вы в Legacy-режиме, и там другие правила:

• Контейнер на образе universal с предустановленными языками. Версии рантаймов можно закрепить.
• Setup script выполняется с доступом в интернет. Необязательный maintenance script — при возобновлении кэшированного контейнера.
• Секреты доступны только setup-скрипту и удаляются перед фазой агента. Переменные окружения доступны всё время.
• export в setup-скрипте не переживает переход к агенту: setup идёт в отдельной сессии bash. Постоянные переменные кладите в ~/.bashrc или в настройки окружения.
• Контейнер кэшируется до 12 часов. Кэш сбрасывается при изменении скриптов, переменных или секретов. В Business и Enterprise кэш общий для всех пользователей окружения.
• Интернет агента по умолчанию выключен. Включается со списком доменов (None, Common dependencies, All) и, для дополнительной защиты, ограничением HTTP-методов до GET, HEAD и OPTIONS.

Последний пункт особенно полезен. Пример из документации: агенту дают задачу по issue, а в описании issue спрятана инструкция выполнить git show HEAD и отправить вывод POST-запросом на чужой сервер. Запрет на POST не даёт такой инструкции сработать, даже если агент на неё поддастся.

Как подготовить репозиторий к облаку

Облачному агенту не у кого спросить, как запустить тесты. Всё должно быть в репозитории:

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

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

Попробуйте сами

10–15 мин на рабочем месте

1. Если у вас есть клиентский проект на GitHub, создайте для него облачное окружение и посмотрите, что Codex записал в Install script и Start skill. Совпадает ли это с тем, что написано в AGENTS.md?
2. Добавьте токен приватного реестра пакетов как сетевой секрет с одним разрешённым доменом. В задаче попросите агента вывести значение переменной и убедитесь, что он видит заглушку.
3. Для GitLab-проекта выпишите, что нужно облачному агенту для запуска тестов, и проверьте, всё ли это есть в AGENTS.md.

Коротко

• Окружение — переиспользуемая настройка облачных задач: репозитории, зависимости, доступы. Изменения вступают в силу после Republish.
• Новые облачные окружения не поддерживают GitLab на октябрь 2026 года. Интеграция GitLab работает через свои окружения проекта.
• Токены кладите в сетевые секреты: агент видит заглушку, прокси подставляет значение только для разрешённых доменов.
• Интернет — минимально необходимый. В Legacy ограничивайте HTTP-методы до чтения.
• Облачные задачи требуют входа через ChatGPT. Репозиторий должен содержать всё для запуска без человека.