Параллельные облачные задачи Codex: сколько запускать и чем за это платишь

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

• Параллельные облачные задачи Codex — это несколько независимых контейнеров, каждый со своей копией репозитория. Одна задача — один контейнер, один чекаут, один дифф на выходе. Формулировка OpenAI прямая: облако существует, чтобы «запускать задачи кодинга в параллельных облачных окружениях».
• Жёсткого документированного потолка на число одновременных задач нет. На 13 августа 2026 такого числа нет ни на странице облака, ни в прайсинге, ни в справочнике опций из 372 ключей, ни в справке CLI. Ограничивает вас бюджет плана, а он считается по объёму вычислений, а не по числу задач.
• Цифры «6 потоков» и «3–5 агентов», которыми забита выдача, к облаку отношения не имеют. Это про локальные субагенты, и даже там шестёрка — не документированный дефолт, а значение из примера конфига.
• Изоляция есть, координации нет. Контейнеры не мешают друг другу на диске, но пять задач от одной ветки сойдутся в конфликте на мерже. Разрезать работу по зонам записи придётся вам.
• --attempts — это не параллель задач, а параллель попыток одной задачи. Диапазон 1–4, по умолчанию 1 (проверено на codex-cli 0.147.0).
• Главная цена параллели — не деньги, а ревью. Шесть готовых диффов одновременно — это шесть разборов, и именно здесь очередь встаёт.

Дальше — как это устроено по шагам, как резать задачу на параллельные куски, где всё ломается и сколько это стоит. Все команды и значения сверены с документацией OpenAI и с самим CLI версии 0.147.0 на 13 августа 2026.

Три механизма параллельного Codex: облако, субагенты и worktree

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

По документации OpenAI на 13 августа 2026, при старте чата выбирается одна из трёх сред: Local, Worktree и Cloud. Первые две исполняются на вашем компьютере, третья — в облачном окружении. Worktree здесь — штатная возможность Git: вторая рабочая копия репозитория в отдельном каталоге, у которой свои файлы, но общая с основной копией история коммитов (сам приём тул-агностичен, и подробно он разобран на примере нескольких агентов в git worktree). Плюс к этому существует четвёртый, ортогональный механизм: субагенты — вспомогательные агенты, которых основная сессия порождает внутри себя и результаты которых собирает в один ответ.

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

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

Если будете искать подробности в англоязычных источниках, учитывайте, что запросы там разведены по механикам, и это экономит время: codex parallel tasks и codex multiple agents выводят на облако и десктоп-приложение, codex cli parallel tasks и codex parallel sessions — на терминал и несколько сессий, а codex parallel attempts — на тот самый флаг --attempts, которому ниже отведён отдельный раздел.

Codex exec в CI: машиночитаемый вывод, коды возврата и цена прогона

Песочница Codex не закрывает чтение: модель угроз и чек-лист

Codex Code Review на GitHub: только P0 и P1, правила в AGENTS.md и борьба с шумом

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

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

Дальше в статье речь про облако. Про то, как устроена одна такая задача от постановки до готового pull request, у нас есть отдельный разбор — облачные задачи Codex; здесь мы не пересказываем его, а берём то, что появляется именно от множественности.

Как живёт одна облачная задача Codex: от контейнера до диффа

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

1. Контейнер и чекаут. Codex создаёт контейнер и выкачивает репозиторий на выбранной ветке или на конкретном коммите.
2. Setup-скрипт. Ставятся зависимости; при возобновлении закэшированного контейнера может отработать ещё и maintenance-скрипт.
3. Настройки сети. Применяется политика интернета окружения. У setup-фазы доступ в сеть есть, у агент-фазы по умолчанию нет.
4. Цикл агента. Агент выполняет команды терминала, правит код, гоняет проверки. Если в репозитории лежит AGENTS.md, команды линта и тестов он берёт оттуда.
5. Ответ и дифф. Агент показывает резюме и дифф изменённых файлов. Дальше человек либо просит доработку, либо открывает pull request.

Из этого списка вытекают три вещи, важные для параллели. Первое: умножается шаг 1 — контейнеров становится столько, сколько задач, и они друг о друге не знают. Второе: не умножается шаг 3 — политика сети и секреты настраиваются на окружение, а не на задачу, то есть одна настройка действует сразу на весь запущенный поток. Третье: шаг 5 не автоматический — pull request открывает человек, и это ваш предохранитель: даже неудачно запущенная пачка из шести задач не портит основную ветку сама по себе.

Отдельно стоит запомнить: setup-скрипт выполняется в отдельной сессии Bash от агент-фазы. Поэтому export до агента не доживает — переменные надо прописывать в ~/.bashrc или задавать в настройках окружения. При параллельном запуске эта деталь бьёт по всем задачам сразу, а выглядит как «у агента почему-то нет переменной».

Сколько облачных задач Codex можно запустить одновременно

Это главный вопрос, ради которого статью и открывают, поэтому ответ сразу: жёсткого задокументированного лимита на число одновременных облачных задач у Codex на 13 августа 2026 нет.

Проверено по четырём местам, где такое число обязано было бы стоять: страница Codex Cloud, страница прайсинга, справочник опций конфигурации (372 уникальных ключа) и справка самого CLI. Ни в одном из них потолка одновременных задач нет. По выдаче при этом ходят конкретные числа вида «на Pro можно 3 задачи, на Plus одну» — при проверке первоисточника они не подтвердились: страница, на которую ссылается поисковая сводка с этими цифрами, содержит таблицу пятичасовых окон расхода, а не ограничение конкурентности.

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

Что ограничивает вас на самом деле — три вещи, и ни одна из них не считается в задачах:

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

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

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

agents.max_threads = 6: почему рантайм Codex даёт четыре слота

Самое тиражируемое утверждение в этой теме звучит так: «у Codex по умолчанию шесть параллельных потоков, ключ agents.max_threads». Оно встречается и в англоязычных гайдах, и в русских разборах. С ним три проблемы, и разбираться в них стоит, потому что именно на эту цифру люди опираются, планируя параллель.

Проблема первая: это не про облако. agents.max_threads управляет субагентами — потоками внутри одной локальной сессии. К числу облачных задач ключ отношения не имеет вовсе.

Проблема вторая: дефолт не документирован. Официальный справочник опций описывает ключ agents.max_concurrent_threads_per_session (а agents.max_threads — его устаревший синоним) и говорит дословно: когда значение не задано, Codex выбирает умолчание сам. Конкретного числа ни на этой странице, ни на странице субагентов нет. Откуда тогда шестёрка? Судя по всему, из примеров конфигурации на странице субагентов: там в одном примере стоит max_concurrent_threads_per_session = 8, в другом = 6. Иллюстрацию прочитали как норму.

Проблема третья: ключ может вообще не работать. В багтрекере openai/codex лежат два отчёта, которые объясняют, почему у людей «шесть в конфиге, а по факту четыре». В issue #33039 (открыт 14 июля 2026) пользователь ставит max_threads = 6 и получает от рантайма четыре слота. В issue #33447 (открыт 15 июля 2026) картина раскрывается: у нового мульти-агентного рантайма свой ключ, features.multi_agent_v2.max_concurrent_threads_per_session, а лимит по умолчанию — четыре потока включая корневой, то есть три подчинённых. Автор отчёта поднимал max_threads до 10 и до 111 — задача продолжала сообщать: «There are 4 available concurrency slots… including you».

Коротко, что откуда взялось:

Проверить существование этой поверхности можно самому. На codex-cli 0.147.0 команда codex features list печатает среди прочего:

multi_agent                          stable             true
multi_agent_v2                       stable             false

То есть флаг реален и имеет статус stable, хотя на 13 августа 2026 выключен, а ключей multi_agent_v2 в официальном справочнике опций нет ни одного. Практический вывод: если вам нужно управлять числом локальных субагентов, не верьте цифре из статьи — проверьте, что говорит сама задача. Спросите у Codex, сколько у него слотов конкурентности, и вы увидите фактическое значение, а не желаемое.

Декомпозиция фичи: что резать на параллельные задачи, а что нет

Все руководства по параллельному Codex начинаются со слов «возьмите независимые задачи». Метода, как сделать их независимыми, не даёт никто — а это и есть основная работа.

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

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

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

1. Зона записи названа заранее. Вы можете перечислить каталоги и файлы, которые задача имеет право изменить.
2. Зона не пересекается с соседями по пачке. Проверяется списком, а не ощущением.
3. Задача проверяема в одиночку. У неё есть свой тест или свой способ убедиться, что она сделана, — без результатов соседних задач.
4. Задача не меняет общий контракт. Схема БД, публичный интерфейс, формат конфигурации, зависимости — всё, на что опираются остальные, должно быть уже зафиксировано.

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

• Такт 1, последовательно: одна задача фиксирует контракт — формат строки, имена колонок, сигнатуру эндпоинта. Это меняет общий контракт, значит параллелить нельзя.
• Такт 2, параллельно: три задачи на зафиксированном контракте — генератор CSV в своём модуле, кнопка и запрос на фронте, набор тестов в своём каталоге. Зоны записи не пересекаются, каждая проверяема.

Чтобы правило было под рукой, вот типовые разрезы одной фичи и их судьба в параллели:

Формулировать каждую задачу всё равно приходится полноценно: параллель не отменяет качества постановки, а умножает цену плохой. Как писать саму формулировку, разобрано отдельно — как ставить задачу Codex. К этому добавляется одно требование, которого у одиночной задачи нет: в тексте задачи стоит прямо назвать её зону записи («меняй только файлы в app/export/, остальное не трогай»). Это дешёвая страховка от того, что агент по дороге решит поправить соседний модуль.

Конфликты веток и pull request: где параллель сходится обратно

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

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

Формально это и есть граница между изоляцией и координацией. В заявке на доработку в багтрекере openai/codex (issue #37226, открыт 6 августа 2026) проблема сформулирована дословно: «chat isolation is not filesystem isolation» — изоляция чатов не равна изоляции файловой системы. Там же перечислено то, что сегодня ложится на пользователя: решать, кто работает где, назначать владельцев файлов, согласовывать порядок передачи и слияния. То есть параллель у Codex сегодня — это изоляция исполнения без координации результата.

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

fatal: 'feature/a' is already used by worktree at '<WORKTREE_PATH>'

Причина не в Codex: ветка — это единственная изменяемая ссылка, и Git сериализует операции над ней, чтобы коммиты не терялись. Именно поэтому локальные worktree Codex работают в состоянии detached HEAD — так их можно создавать пачками, не занимая ветки. Для облачной параллели вывод практический: одна задача — одна ветка, общая ветка на пачку задач не работает по устройству Git.

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

best-of-N через —attempts: одна задача, до четырёх попыток

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

Синтаксис постановки задачи из терминала (команда codex cloud на 13 августа 2026 помечена как экспериментальная):

codex cloud exec --env <ENV_ID> --attempts 3 \
  "Перепиши экспорт CSV на потоковую запись. Меняй только app/export/, тесты не трогай."

Границы флага стоит знать точно, потому что справка их не печатает — в --help указан только [default: 1]. Реальный диапазон выдаёт валидатор продукта. На codex-cli 0.147.0 попытка выйти за границы отвечает так:

error: invalid value '0' for '--attempts <ATTEMPTS>': attempts must be between 1 and 4

То же самое на 5 и на 99, а значения от 1 до 4 проходят проверку. Итого: диапазон 1–4, по умолчанию 1. Сколько попыток реально было у задачи, видно в поле attempt_total в выводе codex cloud list --json.

Когда что выбирать:

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

Изоляция окружения: интернет, секреты и общий кэш на все задачи

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

Пара деталей, на которых спотыкаются чаще всего.

Пресет «общие зависимости» — это ровно 71 домен (посчитано по официальному списку на 13 августа 2026): от alpinelinux.org до yarnpkg.com, весь типовой набор реестров пакетов и репозиториев. Сторонние пересказы обычно пишут «более семидесяти» — точное число полезно, когда вы решаете, хватит ли пресета или придётся дописывать домены руками. Весь исходящий трафик окружения в любом случае идёт через HTTP/HTTPS-прокси.

Секреты ведут себя обратно ожиданию. Они доступны setup-скриптам и удаляются до старта агент-фазы. Это регулярно читают как поломку: в issue #34460 (открыт 21 июля 2026) секрет настроен в окружении, но задача сообщает, что переменной нет. Поведение задумано именно так — то, что нужно агенту в рантайме, передаётся переменными окружения, а не секретами.

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

Цена параллели: как несколько задач съедают лимит плана

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

Отсюда простая арифметика планирования. Если ваша типовая задача стоит условную единицу расхода, то пачка стоит:

Расход пачки ≈ (число задач) × (число попыток) × (стоимость типовой задачи)

Четыре задачи с --attempts 3 — это порядка двенадцати типовых задач, а не четыре. Именно здесь недельные бюджеты и заканчиваются в среду.

Что это даёт на практике — на составе планов от 13 августа 2026 (Free, Go за 8 долларов, Plus за 20, Pro от 100 с тирами 5x и 20x к лимитам Plus, плюс Business и Enterprise):

Что бывает, когда параллель уходит вразнос, задокументировано. В issue #30246 (открыт 26 июня 2026, метки bug и rate-limits) пользователь плана за 100 долларов описывает, как недельный бюджет закончился примерно за двое суток на простых задачах ревью: по логам 4101 и 4139 вызовов API 19 и 20 июня против обычных 81–198 в день, до 632 записей параллельных сессий в одну секунду и 248 сессий за два дня; пополнение сгорело сразу после начисления. Это отчёт пользователя, а не измерение вендора — но точнее данных по цене неконтролируемой параллели в открытых источниках нет, и порядок величин он показывает убедительно.

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

Мониторинг пачки задач: codex cloud list, status, diff и apply

Когда задач больше двух, вкладка браузера перестаёт быть удобным пультом. Из терминала пачка видна одной командой. Полный набор подкоманд на codex-cli 0.147.0:

codex cloud            # интерактивный список задач (помечено [EXPERIMENTAL])
codex cloud exec       # поставить задачу без запуска интерфейса
codex cloud status     # состояние конкретной задачи
codex cloud list       # список задач
codex cloud diff       # показать дифф задачи
codex cloud apply      # применить дифф локально

Рабочий приём: codex cloud list --json плюс любой парсер JSON даёт таблицу «что готово, что ещё идёт» за секунду и хорошо ложится в маленький скрипт-пульт. Поле attempt_total при этом сразу показывает, у каких задач было несколько попыток и где, соответственно, есть из чего выбирать. Как устроен сам терминальный цикл работы с Codex, разобрано в статье про рабочий цикл Codex CLI.

Приёмка нескольких готовых диффов: в каком порядке разбирать

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

1. Сначала отсортируйте по зоне записи, а не по времени готовности. Первым разбирается то, что меняет общее — миграции, конфиги, контракты. Пока это не смержено, остальные диффы могут оказаться построенными на устаревшей базе.
2. По каждой задаче сверьте зону записи с обещанной. Дифф, залезший за пределы объявленных файлов, — повод не принимать сразу, даже если код выглядит хорошо: именно так параллельные задачи и сталкиваются.
3. Проверьте, что задача проверяема. Есть ли тест, прошёл ли он в логе задачи. Резюме агента — это его слова о своей работе, а не результат проверки.
4. Там, где было несколько попыток, сравнивайте по подходу. У attempt_total больше единицы смотрите не «какой дифф короче», а какой подход вы готовы поддерживать через полгода.
5. Мержите по одному и обновляйте базу. После каждого слияния соседние задачи стоит перепроверить на актуальность, а спорные — перезапустить от обновлённой базы.
6. Отклоняйте пачку целиком, если разошлись все. Когда три задачи из четырёх сделали не то, проблема почти всегда в постановке, а не в модели: дешевле переформулировать и запустить заново, чем чинить четыре результата руками.

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

Риски параллельного Codex: отказы, задокументированные в багтрекере

Честная картина по состоянию на 13 августа 2026: продукт активно развивается, репозиторий openai/codex держит около 105,7 тысячи звёзд и порядка 12,3 тысячи открытых issue (без учёта пул-реквестов), и параллельные сценарии — заметная их часть. Ниже отказы, задокументированные в багтрекере. Это отчёты пользователей, а не подтверждённые вендором дефекты, но знать их полезно: они описывают ровно те грабли, на которые наступают при параллели.

Отдельно стоит сказать, чего в этом списке нет. Нет ни одного отказа, при котором параллельные задачи сами по себе портят основную ветку: результат приезжает диффом на ревью, а pull request открывает человек. Цена ошибки при неудачной параллели — потраченный бюджет и потраченное время на разбор, но не сломанный репозиторий.

Что устареет первым. Быстрее всего меняются: статус экспериментальной команды codex cloud и состав её подкоманд, диапазон --attempts, состав и цены планов, ключи мульти-агентной конкуренции (multi_agent_v2 на 13 августа 2026 существует, но выключен и в справочнике опций отсутствует) и список доменов в пресете. Проверить у себя это дёшево: codex cloud exec --help покажет актуальные флаги, codex features list — состояние экспериментальных поверхностей, а страница Codex Cloud — текущий жизненный цикл задачи.

FAQ

Есть ли у Codex лимит на число одновременных облачных задач?

Документированного потолка нет: на 13 августа 2026 такого числа нет ни на странице Codex Cloud, ни в прайсинге, ни в справочнике опций, ни в справке CLI. Ограничивает бюджет плана, который считается по объёму вычислений, а не по числу задач, и ваша скорость разбора результатов. Практики обычно держат 3–5 одновременных задач, но это их опыт, а не лимит продукта.

Чем параллельные облачные задачи отличаются от субагентов Codex?

Это разные механизмы. Облачная задача — отдельный контейнер со своей копией репозитория, работает без вашей машины и заканчивается диффом и pull request. Субагенты — потоки внутри одной локальной сессии, они делят вашу рабочую копию и нужны в первую очередь для чтения: разведки по коду, тестов, триажа. Цифры вроде «шесть потоков» относятся к субагентам и на облако не переносятся.

Что будет, если две задачи изменят один и тот же файл?

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

Сколько стоит —attempts 4 по сравнению с одной попыткой?

Порядка четырёхкратного расхода на эту задачу: флаг заказывает четыре независимые попытки одного и того же задания. Точную формулу списания OpenAI не публикует, поэтому считать стоит множителями: пачка обходится примерно как «число задач × число попыток» типовых задач. Держать --attempts больше единицы по умолчанию не стоит — это инструмент для задач с неочевидным решением.

Работает ли интернет внутри параллельных облачных задач?

В агент-фазе по умолчанию выключен, у setup-скриптов доступ есть. Включается интернет настройкой окружения, а не отдельной задачи, поэтому послабление сразу распространяется на все задачи этого окружения. Можно ограничить доступ списком доменов (пресет общих зависимостей содержит 71 домен) и разрешить только методы GET, HEAD и OPTIONS.

Можно ли ставить облачные задачи Codex из терминала?

Да, командой codex cloud exec --env <ENV_ID> с текстом задачи; базовая ветка задаётся флагом --branch, число попыток — --attempts. Следить за пачкой удобно через codex cloud list --json, забирать результат — командой codex apply <TASK_ID>. На codex-cli 0.147.0 команда codex cloud помечена как экспериментальная, поэтому набор подкоманд стоит сверять командой codex cloud --help.