Настройка Codex Cloud: задачи в облаке и управление с телефона

Настройка Codex Cloud позволяет подготовить среду проекта один раз и возвращаться к ней для новых задач. Перед уходом с рабочего места поручите Codex разобраться с падающим тестом: работа продолжится даже с выключенным ноутбуком. Через веб-интерфейс или с телефона можно следить за ходом задачи, уточнять требования и проверять результат.

Что изменилось 30 сентября

После перезапуска облачную работу проще организовать как повторяемый процесс: репозиторий, зависимости, скрипты и настройки можно подготовить ещё до начала следующей задачи. Следить за ходом работы и направлять Codex можно с телефона или другого компьютера. Привычный интерфейс настольного приложения теперь доступен и в веб-версии, и на мобильных устройствах. Эти изменения описаны в анонсе OpenAI от 30 сентября 2026 года.

Представьте среду как подготовленную мастерскую. Инструменты и материалы уже на месте, а для каждой задачи выделяется отдельный верстак. Зависимость — это программный пакет, который нужен проекту; репозиторий — хранилище его кода с историей версий.

Практический смысл в том, что работа над кодом больше не требует держать собственный компьютер включённым. Codex Cloud выполняет задачи на компьютерах под управлением OpenAI. Создайте и опубликуйте среду в настольном приложении или веб-интерфейсе, затем используйте её на поддерживаемых устройствах. У каждой задачи свой набор рабочих файлов. Это разделение объясняется в справке OpenAI по Codex Cloud.

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

В каких тарифах доступен Codex Cloud?

Для доступа к облаку нужна подходящая учётная запись Plus, Pro, Business, Enterprise, Healthcare или Education. Доступность зависит от этапа развёртывания и настроек рабочего пространства. Free и Go дают доступ к Codex, но не к Codex Cloud. Пользователи с местами Guest, K-12 и Enterprise с правами только на просмотр не могут создавать облачные среды. Эти различия приведены в справке OpenAI о доступности по тарифам.

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

Как облачные задачи расходуют лимиты

На момент запуска за виртуальную машину стандартной среды отдельная плата не взимается. Виртуальная машина — это удалённый компьютер, на котором выполняется задача. При этом использование модели по-прежнему расходует обычные лимиты Codex и учитывается в применимых кредитах или оплате. В тарифах с общим пулом использование может распределяться между Codex, ChatGPT Work, ChatGPT for Excel и Workspace Agents, если они доступны. В договорах Enterprise с оплатой по токенам расчёты ведутся в USD, а не в кредитах. Этот порядок описан в правилах OpenAI по учёту использования.

Локальные сообщения и облачные чаты расходуют общий лимит тарифа; также могут действовать недельные ограничения. Облачные задачи способны расходовать больше лимита, чем локальные сообщения. Оценки количества сообщений на странице тарифов относятся к локальной работе и не гарантируют определённого числа облачных задач. Пользователи Plus и Pro, которым доступна эта возможность, могут докупить кредиты без смены тарифа. Актуальные лимиты и время их сброса проверяйте на панели использования. На странице цен и использования Codex объясняется, от чего зависит расход.

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

Более широкое сравнение подписок и API — в статье «Цены Codex в 2026 году». Для Cloud нужен вход через ChatGPT; локальная сессия CLI с ключом API оплачивается отдельно по тарифам API. Разница описана в документации по способам аутентификации.

Настройка Codex Cloud: одна среда для повторяющихся задач

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

1. Подключите репозиторий. В веб-интерфейсе или настольном приложении выберите Work in > Cloud > Select environment > Create environment. Укажите репозитории GitHub и при необходимости подключите GitHub.
2. Подготовьте проект. Выберите Get started. Дайте Codex изучить проект, установить зависимости и запустить тесты. Сообщите недостающие сведения и нужные версии.
3. Проверьте скрипт настройки. Install script фиксирует подготовку зависимостей, а Start skill — запуск сервисов и проверку их готовности. Уточняйте настройку в диалоге.
4. Задайте значения. Нажмите Manage рядом с переменными окружения или сетевыми секретами. Для сетевого секрета укажите ключ, значение и разрешённые домены.
5. Настройте доступ к интернету. При необходимости включите Allow Codex to access internet. Выберите Package managers или Custom domains only и добавьте нужные хосты. Режим All (unrestricted) разрешает более широкий доступ.
6. Опубликуйте среду и начните задачу. Проверьте файлы, конфигурацию и результаты проверок. Сохраните изменения, затем нажмите Publish. После сообщения Environment published создайте новую задачу. Для последующих изменений настройки используйте Edit и Republish.

В диалоге подготовки сообщите Codex реальные команды установки и тестирования проекта, требуемую версию среды выполнения и необходимые сервисы. Попросите указать, какие проверки прошли, а что проверить не удалось. Это рекомендации для постановки задачи, а не универсальный скрипт настройки.

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

Три задачи, с которых стоит начать

Выберите задачу с понятной отправной точкой, небольшим объёмом и результатами, которые можно проверить. Эти варианты задания можно адаптировать к своему репозиторию.

Исправить падающий тест

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

Пример задания:

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

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

Написать миграцию

При изменении схемы базы данных бэкенд-разработчик может запросить файл миграции, разбор совместимости и тесты на временных данных. Миграция — это версионируемое изменение структуры базы или хранящихся в ней данных.

Пример задания:

Подготовь миграцию для этого изменения схемы по принятым в репозитории правилам. Объясни совместимость с текущим приложением, варианты отката и риски потери данных. По возможности проверь её на одноразовых тестовых данных. Не запускай миграцию на рабочей базе и не выполняй развёртывание.

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

Проверить pull request

Если сопровождающий проекта ждёт изменений от коллеги, нужно указать ветку или коммиты PR и базовую ветку. Попросите найти проблемы и подкрепить выводы доказательствами, не меняя рабочие файлы.

Пример задания:

Изучи этот pull request относительно его базовой ветки. Проверь корректность, авторизацию, совместимость и недостающие тесты. Для каждой найденной проблемы укажи место в файле, конкретный сценарий сбоя и подтверждающие данные. Не меняй файлы и не выполняй слияние PR.

Для встроенного ревью в GitHub OpenAI описывает подключение репозитория и комментарий @codex review в PR. Этот процесс разобран в инструкции по настройке ревью в GitHub. В переходный период Code Review, Security Review и существующие интеграции с GitHub и Linear продолжают использовать Codex Cloud (Legacy). Это уточнение есть в справке по Cloud.

Запрос на проверку внутри новой облачной задачи и автоматическое ревью в GitHub — разные процессы.

Ещё три задачи, которые можно поручить агенту

После исправления падающего теста я бы выбрал следующие задачи: их сравнительно легко ограничить по объёму и проверить. Это предлагаемые сценарии работы, а не отчёт о полученных результатах.

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

Как следить за задачей и направлять её с телефона

Чтобы продолжить работу, возвращайтесь в ту же задачу. Новая задача получает отдельное рабочее пространство и не восстанавливает незакоммиченные изменения из первой. Важные изменения сохраняйте коммитами. По умолчанию окно восстановления сохранённой виртуальной машины составляет до семи дней с начала последнего хода диалога или возобновления задачи. Это срок восстановления состояния, а не правило хранения истории переписки. Что именно сохраняется, объясняется в справке OpenAI о состоянии задачи.

На мобильном устройстве откройте Codex и выберите опубликованную среду. Вернитесь в задачу, чтобы следить за ходом работы и отправлять уточнения. Работа на разных устройствах описана в обзоре Cloud.

Полезное уточнение снимает конкретный вопрос:

• «Оставь исправление в парсере; сохрани формат публичного ответа».
• «Для теста миграции используй одноразовый тестовый набор данных в базе».
• «Остановись после исправления и отчёта о тестах; развёртывание оставь до проверки».

Я бы использовал телефон для уточнения границ задачи и проверки хода работы, а существенный diff просматривал на большом экране. Удалённый доступ к задаче, выполняющейся на ноутбуке, всё равно зависит от этого компьютера. Он не даёт возможности работать с выключенным ноутбуком, которую предоставляет Cloud. Эти режимы различаются в справке OpenAI.

Что выбрать: Codex в облаке или локальный CLI?

Выбирайте облако, если задача с чёткими границами должна продолжаться независимо от вас. Локальный CLI подходит, когда работа зависит от файлов и инструментов разработчика, уже установленных на вашем компьютере.

CLI умеет изучать локальный репозиторий, менять файлы и запускать установленные инструменты. Откройте каталог проекта, выполните codex и войдите через ChatGPT. CLI также может делегировать задачи через codex cloud, поэтому исходный интерфейс не определяет, где будет выполняться работа. Оба варианта описаны в руководстве по CLI.

В таблице ниже — мои рекомендации.

Текущие среды Cloud не поддерживают управление компьютером или браузером, GitLab и самостоятельно размещённый GitHub Enterprise Server. Личные навыки из локальной среды не синхронизируются. Текущие ограничения важнее общей симпатии к облачной работе.

Ограничьте доступ и проверьте diff

Выясните, куда среда может обращаться. Разрешённые домены определяют сетевые адреса, доступные виртуальной машине, но не выдают права в самих сервисах. Сетевые секреты, принадлежащие среде, также разрешают доступ к своим доменам. Требования Enterprise Agent Security действуют вместе с настройками среды. Эти механизмы описаны в документации по сетевой конфигурации и Agent Security.

Выберите подходящий способ передачи учётных данных. Значения обычных переменных окружения доступны программам. Сетевые секреты используют подстановочные значения через прокси для разрешённых HTTPS-адресов на порту 443 при настройке и выполнении задач. Так исходные учётные данные не попадают в локальные процессы и файлы. Механизм объясняется в документации по работе с секретами.

Для первой задачи я бы не давал доступ к учётным данным рабочей системы и ограничился узкими правами в среде разработки. Перед слиянием прочитайте diff, проверьте вывод тестов и изменения зависимостей, убедитесь, что исправление отвечает заданию. Прошедшие тесты — это данные для оценки, а не повод пропустить ревью.

Доступность Cloud для учётных записей Healthcare не означает, что на Cloud распространяется BAA OpenAI — соглашение об обработке медицинских данных, подпадающих под его условия. OpenAI указывает, что в Codex Cloud нельзя обрабатывать защищённую медицинскую информацию. Эта граница описана в правилах Cloud по работе с данными.

Настройки для команды разобраны в статье «Как настроить безопасность Codex после DevDay».

Какие продукты можно построить вокруг этого процесса

Самая перспективная идея — набор для исправления сбоев, блокирующих релиз, под один программный стек. Командам, которые теряют время на падающих тестах, можно продавать повторяемый процесс и проверку результатов. По оценке DataForSEO, полученной 7 октября, запрос «automated software testing tools» набирает 1,600 поисков в Google в США за месяц. Это показатель интереса к самой задаче, а не спроса именно на Codex Cloud.

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

Набор для проверки миграций может пригодиться командам, работающим с одним фреймворком и одной базой данных. DataForSEO оценивает частотность запроса «database migration tools» в 1,300 поисков в США за месяц. MVP может содержать шаблоны миграций, одноразовые тестовые данные, проверки совместимости и запросы для ревью, которые разработчик запускает в подготовленной среде. Ограничение связано с поведением рабочей системы: универсальный набор не может обещать, что внедрение изменений в реальную базу будет безопасным или быстрым.

Набор для обоснованного ревью PR может помочь сопровождающим проектов унифицировать запросы на проверку и оценку найденных проблем. По оценке DataForSEO, запрос «ai code review» набирает 1,300 поисков в США за месяц, а среди вопросов в поиске встречается «Can ChatGPT do a code review?» — «Может ли ChatGPT проводить ревью кода?». Начните с рекомендаций для репозитория, заданий на ревью и формата, в котором выводы подкрепляются доказательствами. Сложность в том, что встроенное ревью уже существует: набор должен добавлять понимание конкретной предметной области и полезные проверки.

Все три идеи — предлагаемые продукты на основе документированного делегирования задач. Числа поисковых запросов показывают оценочный интерес к таким задачам, а не количество клиентов или прогноз выручки. Начните с набора для исправления тестов: его критерий приёмки проще измерить, чем качество ревью в целом.

Может ли ChatGPT проводить ревью кода?

Да. Для Codex описан процесс ревью PR в GitHub; также можно поручить отдельную задачу на проверку. Укажите базовую ветку и риски, которые нужно проверить. Решение о слиянии оставьте человеку.

Безопасен ли код, написанный ИИ?

Оценивайте конкретное изменение. Проверьте, как изменилось поведение, что происходит с авторизацией и зависимостями, какие есть тесты и непроверенные допущения. Ни убедительное объяснение, ни зелёные тесты не доказывают, что учтён каждый важный случай.

Стоит ли тратить время на ревью кода?

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

С чего начать в понедельник

Выберите один репозиторий с надёжной командой запуска тестов. Подготовьте и опубликуйте его среду, поручите исправить небольшую воспроизводимую ошибку, а после ухода с рабочего места проверьте задачу с телефона. Изучите исправление перед слиянием. Запишите, сколько усилий ушло на настройку и ревью, а также какой объём лимита тарифа был израсходован. Используйте среду повторно, если эксперимент улучшил ваш рабочий процесс.

Если хотите встроить такой процесс в работу команды по выпуску изменений, создайте систему с ИИ для продакшена.