Codex и GitHub в работе команды: права, ветки, ревью и конфликты

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

• Способов связать Codex с GitHub три, и они не взаимозаменяемы: приложение поверх Codex cloud (задачи и ревью прямо в репозитории), GitHub Action openai/codex-action@v1 (агент внутри workflow) и локальный CLI рядом с рабочей копией. Первый требует плана ChatGPT: при оплате по API-ключу облачных функций нет вовсе.
• Приложение называется ChatGPT Codex Connector, издатель — OpenAI. Полного списка прав на его публичной странице нет: команда увидит их только на экране установки в GitHub — и это стоит сохранить скриншотом.
• GitHub Issue назначить на Codex нельзя. Запрос на нативную интеграцию задач закрыт как не запланированный, а упоминание @codex официально работает только в комментариях к pull request.
• Открытие pull request — шаг человека, а не финал задачи: агент показывает итог и дифф, PR открываете вы.
• Главная боль команды не в агенте, а в правилах GitHub: апрув отклоняется как устаревший при новом пуше, а агент, дорабатывающий PR по замечаниям, всегда оказывается последним пушившим. Лечится черновым PR и настройкой правила про «апрув не от последнего пушившего».
• Ревью Codex не заменяет обязательный апрув — так прямо сказано в документации самого вендора. Это дополнительный сигнал до человека, а не merge gate.

Всё, что ниже, проверено по состоянию на 13 августа 2026: официальная документация Codex и GitHub, состояния задач в трекере openai/codex через GitHub API, локальный запуск Codex CLI версии 0.147.0.

Три способа связать Codex с GitHub и чем они отличаются

Выдача по запросу «codex github» смешивает три разные вещи в одну кашу, и из-за этого команды берут не тот инструмент. Разведём сразу.

Первый путь — GitHub-приложение поверх Codex cloud. Это то, что имеют в виду, когда говорят «интеграция»: агент получает доступ к репозиторию, выполняет задачи в изолированном облачном окружении и отвечает на упоминания в pull request. Официальная документация OpenAI по этой интеграции описывает именно этот механизм.

Второй путь — GitHub Action openai/codex-action@v1. Здесь Codex живёт внутри вашего workflow: действие ставит CLI, поднимает прокси к API и запускает codex exec с теми правами, которые вы явно выдали. Это не «интеграция репозитория», а запуск агента в CI под вашим контролем.

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

Третий путь — локальный CLI. OpenAI Codex в терминале умеет ревьюить изменения до того, как они попадут в GitHub: команда codex review работает против базовой ветки, против незакоммиченных правок или против конкретного коммита. Никакой связи с репозиторием на стороне сервиса здесь нет вообще — всё происходит на вашей машине.

Nutanix заменила Copilot и Claude кластером за $20 млн: окупаемость — год

OpenAI раскрыла масштаб взлома Hugging Face: 1200 агентов и 12 дней без обнаружения

Рефакторинг легаси-кода с Codex: разведка репозитория, тесты и режимы одобрения

Perplexity Portable Computer: агент считает на вашей RTX, счёт за токены — ноль

Claude Code включил форк-субагентов по умолчанию: разбор релизов с 2.1.232 по 2.1.239

Дальше в статье речь идёт в основном о первом пути — именно он и есть «интеграция Codex с GitHub» в терминах вендора. Второй путь остаётся в кадре там, где без него нельзя объяснить поведение проверок.

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

Подключение репозитория к Codex: порядок шагов и чьи права нужны

Официальный порядок из документации выглядит так, и отступать от него смысла нет — каждый следующий шаг опирается на предыдущий.

1. Войдите в Codex под своим аккаунтом ChatGPT.
2. Подключите аккаунт GitHub и выберите репозитории, к которым Codex получит доступ. Здесь важно понимать: выбор делается на стороне GitHub, и это первый рычаг ограничения — не выдавайте доступ ко всей организации, если задача про один сервис.
3. Создайте окружение для репозитория. Здесь настраиваются зависимости, инструменты, переменные окружения и секреты, которые нужны задаче.
4. Запустите первую задачу, выбрав это окружение.
5. Примите результат: посмотрите итог и дифф, попросите доработать или откройте pull request.

Отдельно включается ревью. Чтобы настроить его для репозитория, нужны два условия: у репозитория должен быть настроен Codex cloud, и у вас должны быть GitHub push или admin права на настройки этого репозитория. Дальше в настройках Codex включается переключатель code review для конкретного репозитория, а при желании — и автоматическое ревью каждого нового pull request.

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

Права приложения ChatGPT Codex Connector: что видно и что скрыто

Приложение, через которое всё работает, называется ChatGPT Codex Connector, издатель — OpenAI, описание на его странице в GitHub: «Bring ChatGPT and Codex to your GitHub repositories».

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

А теперь неприятная часть. Публичного списка прав у этого приложения нет. На странице приложения по состоянию на 13 августа 2026 есть имя, издатель и одна строка описания — ни перечня прав репозитория, ни подписок на события. В документации Codex этого списка тоже нет: страницы про интеграцию, администрирование и роли описывают механику, но не перечисляют разрешения. Единственное место, где команда увидит полный набор, — экран установки приложения в GitHub.

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

Второй сюрприз касается того, что коннектор может оказаться читающим. В трекере продукта есть подробно описанный случай (задача №17475, открыта 11 апреля 2026, на 13 августа 2026 всё ещё открыта): в живой сессии права коннектора выглядели как pull: true, push: false, triage: false, admin: false, и операцию записи пришлось выполнять через утилиту gh с отдельной авторизацией в браузере. Человек при этом был уверен, что «GitHub подключён».

Отсюда правило, которое стоит записать в регламент до первого прогона:

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

Права агента на вашей собственной машине — отдельная тема со своей механикой: режимы одобрения и песочница к правам GitHub-приложения отношения не имеют и настраиваются независимо.

Почему GitHub Issue нельзя назначить на Codex и что делать вместо

Это самое живучее заблуждение вокруг темы. Половина материалов в выдаче написана в жанре «дал агенту issue — получил pull request», и читатель делает вывод, что задачу можно назначить на бота, как на разработчика.

Нельзя. Официальная документация описывает упоминание агента только в комментариях к pull request: «If you mention @codex in a comment with anything other than review, Codex starts a cloud chat using your pull request as context». Ни issue, ни назначение исполнителем в ней не фигурируют.

Больше того, это не пробел документации, а решение. Запрос «Integrate GitHub Issues» в трекере продукта — с формулировкой «начинать тред Codex прямо из issue, чтобы идти от находки к реализации без переключения контекста» — был открыт 5 февраля 2026 и закрыт 20 марта 2026 со статусом «не запланировано». Это состояние снято через GitHub API, а не пересказано с чужих слов.

Что делать вместо:

1. Скопируйте суть issue в текст задачи. Не ссылку, а требования: что должно получиться, какие ограничения, чем проверяется результат. Ссылку добавьте отдельно — она пригодится в описании PR.
2. Стартуйте задачу оттуда, откуда официально можно: с веба, из pull request, из Linear или из Slack.
3. Если у вас уже есть pull request по этой задаче (даже пустой черновик), работайте через него — тогда @codex получает контекст автоматически.
4. Ставьте задачу из терминала, если это привычнее: codex cloud exec --env <ENV_ID> --branch <BRANCH> "<текст задачи>". Подкоманда cloud в версии 0.147.0 помечена как экспериментальная.

Формулировка задачи здесь — не мелочь. Официальная рекомендация для длительной работы требует трёх вещей: результата, ограничений и способа проверки. Подробнее про то, как формулировать задачу агенту, — в отдельном разборе; для GitHub-процесса важно лишь то, что «сделай как в issue #412» задачей не является.

Путь задачи до pull request: где кончается агент и начинается человек

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

Обратите внимание на предпоследнюю строку. В документации открытие PR описано как действие после приёмки результата — «open a pull request when the work is ready», — а не как автоматический финал задачи. Переключателя «всегда открывать PR» в документации не описано.

Косвенное подтверждение приходит с неожиданной стороны: в сообществе OpenAI регулярно всплывают темы вида «кнопка Create PR пропала, хотя GitHub подключён». Такие обсуждения имеют смысл только в мире, где открытие pull request — отдельный ручной шаг с отдельными условиями.

Если результат нужен локально, а не в виде PR, у CLI версии 0.147.0 есть готовые команды:

• codex cloud list --json --limit 10 — список задач;
• codex cloud diff <TASK_ID> — посмотреть дифф;
• codex cloud apply <TASK_ID> --attempt 2 — применить нужную попытку в рабочую копию;
• codex apply <TASK_ID> — то же самое командой верхнего уровня, как git apply.

Флаг --attempts N у codex cloud exec запускает несколько попыток одной задачи (best-of-N), а --attempt у apply выбирает, какую из них забрать. Для рискованного рефакторинга это дешёвый способ получить три варианта решения и взять лучший, не открывая три pull request.

Мелочь, которая экономит десять минут: в версии 0.147.0 команда codex cloud exec --help печатает справку верхнего уровня, а не справку подкоманды (то же самое с list и apply). Справка достаётся формой codex cloud help exec.

Из чего собирается понятный pull request: описание, коммиты, проверки

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

Шаблон pull request. GitHub подставляет в тело нового PR содержимое файла pull_request_template.md, если тот лежит в корне репозитория, в папке docs или в .github. Механизм работает и для PR, открытого по итогам агентной задачи, — но заполнять шаблон агент будет только в той мере, в какой вы попросили. Практика простая: требование «описание PR по нашему шаблону: что изменено, зачем, как проверить, что затронуто» должно лежать в AGENTS.md, а не только в самом шаблоне.

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

Проверки. Команды линта и тестов агент ищет в AGENTS.md — это прямо описано в механике облачного прогона. Если проект собирается нестандартной командой, а в файле инструкций её нет, агент честно попробует угадать и потратит на это время контейнера.

Минимальный набор требований, который стоит держать в файле инструкций именно ради читаемых PR:

## Pull request

- Описание PR заполняй по шаблону .github/pull_request_template.md.
- Первая строка описания — что изменилось для пользователя, не для кода.
- Отдельным коммитом: миграции, переименования файлов, изменения зависимостей.
- Перед сдачей прогони: pnpm lint && pnpm test.
- Если задача пришла из issue, добавь строку «Closes #<номер>».

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

Комментарии рецензентов: как довести PR до мержа без ручной правки

Итерации по замечаниям — самое ценное и самое недоописанное место интеграции. Маршрутов ровно два, и у них разные требования.

Маршрут первый: комментарий в самом pull request. Работает без вашей машины, прямо в GitHub.

1. Рецензент оставляет замечания обычным образом.
2. Вы (или рецензент) пишете комментарий вида @codex fix the P1 issue — или, если ревью делал сам Codex, @codex fix it.
3. Запускается облачный чат с этим pull request в качестве контекста.
4. Codex вносит правку и может запушить её обратно в ветку — при условии, что у него есть на это право.

Отдельно про запрос ревью: точный триггер — комментарий @codex review. Агент подтверждает приём реакцией-глазами на комментарий, после чего публикует ревью. В GitHub он помечает только проблемы уровня P0 и P1, чтобы комментарии оставались про высокоприоритетные риски. Разовый фокус задаётся в том же комментарии: @codex review for issues in the database migration.

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

1. Переключитесь на ветку pull request в проекте.
2. Откройте панель ревью — в боковой панели появятся контекст PR и замечания рецензентов, а в панели ревью комментарии встанут рядом с диффом.
3. Попросите Codex починить конкретные замечания (например: «Address the inline comments and keep the scope minimal»).
4. Проверьте получившийся дифф.
5. Застейджите, закоммитьте и запушьте изменения в ветку PR.

Критическое условие второго маршрута, которого нет ни в одном стороннем гайде: нужна установленная утилита gh и выполненный gh auth login. Без этого контекст pull request, комментарии рецензентов и список изменённых файлов могут просто не появиться — и вы будете думать, что интеграция сломана.

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

Ветвление и конфликты: почему апрувы PR обнуляются на итерациях

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

Три правила из официального справочника правил GitHub складываются в ловушку:

• Устаревшие апрувы. При включённой опции апрув отклоняется, если дифф изменился после одобрения — в том числе после пуша в ветку PR или нажатия «Update branch». Пока кто-то не одобрит заново, мерж заблокирован.
• Апрув не от последнего пушившего. Отдельным правилом можно требовать одобрение от кого-то, кроме человека, запушившего последним. Правило существует как защита от «угона» уже одобренного pull request.
• Строгий режим обязательных проверок. В strict-режиме ветка обязана быть свежей относительно базовой, иначе мерж не разрешён.

Теперь наложите на это агента, который дорабатывает PR по замечаниям. Он всегда последний пушивший. Каждый цикл «нашли — попросили починить — агент запушил» обнуляет согласование: апрувы слетают как устаревшие, а правило про последнего пушившего требует, чтобы одобрил уже кто-то другой. На активном PR с тремя итерациями это три круга согласования вместо одного.

Что с этим делают на практике:

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

Правила репозитория для агента: AGENTS.md, CODEOWNERS, шаблон PR

Правила репозитория делятся на две категории, и путать их дорого: одни агент читает и исполняет, другие действуют поверх него силами GitHub.

Что Codex читает. Правила ревью задаются секцией ## Code Review Rules в файле AGENTS.md; подзаголовки уровня ### группируют связанные проверки. Дословный пример из документации:

## Code Review Rules

### Experiment cohorts

- Do not filter treatment comparisons on post-exposure behavior, including conversion or retention.
  Safe path: build cohorts from assignment or exposure; report conversion as an outcome.

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

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

Что действует поверх агента. Здесь три механизма GitHub, на которые Codex повлиять не может.

• CODEOWNERS. Владельцами кода могут быть только пользователи и команды с правом записи. Приложений в этом списке нет — то есть назначить Codex владельцем кода нельзя в принципе. Если у файла несколько владельцев, достаточно одобрения любого из них.
• Черновые pull request. Владельцев кода GitHub не зовёт автоматически на черновики: запрос уходит, когда PR переводят в готовый к ревью. Это тот самый рычаг из предыдущего раздела.
• Шаблон pull request. Файл pull_request_template.md подставляется в тело нового PR — но это работа GitHub, а не агента, и следить за заполнением приходится через инструкции проекта.

Может ли ревью Codex стать обязательной проверкой перед мержем

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

Со стороны OpenAI формулировка однозначная: «Code review rules guide Codex; they don’t replace tests, branch protections, or required approvals». То есть правила ревью направляют агента, но не заменяют тесты, защиту ветки и обязательные одобрения.

Со стороны GitHub картина такая же, только с технической стороны:

• Обязательный апрув считается от рецензентов с правом записи, а владельцами кода могут быть только пользователи и команды. Приложение в этой роли не предусмотрено.
• Обязательную проверку действительно можно привязать к конкретному приложению как к ожидаемому источнику статуса. Но приложение должно быть установлено с правом statuses:write, недавно присылать check run и быть связанным с уже существующей обязательной проверкой. А поскольку список прав приложения Codex публично не опубликован, гарантировать выполнимость этой схемы нельзя — это условие, а не рецепт.

Что реально работает вместо «сделаем ревью агента обязательным»:

1. Включить автоматическое ревью каждого нового pull request — тогда сигнал появляется всегда, без чьей-то дисциплины.
2. Обязательным сделать то, что детерминировано: тесты, линт, сборку, проверки безопасности в CI. Их статус машина выставляет однозначно.
3. Требовать резолва всех комментариев перед мержем — правило GitHub, которое не даст замести находки под ковёр, кто бы их ни оставил.
4. Не путать роли: агент отвечает за «поймать регресс раньше человека», человек — за «решить, что мы это мержим».

Отдельно стоит упомянуть Security Review — углублённое ревью безопасности, которое на 13 августа 2026 идёт в статусе research preview. Оно включается вместе с обычным ревью в настройках, вызывается вручную комментарием @codex security review, а полный отчёт открывается во вкладке Security Report у задачи. Механизм автоматического ревью как таковой заслуживает отдельного разбора и здесь намеренно не раскрывается подробно.

Монорепо и большие репозитории: окружение, кэш и область правил

В монорепо ломается не интеграция, а два допущения: что агент видит весь репозиторий одинаково и что правила лежат «где-то в корне».

Окружение. При запуске задачи создаётся контейнер, репозиторий выкачивается на выбранной ветке или коммите, выполняется setup-скрипт, применяются сетевые настройки — и только потом работает агент. Для распространённых пакетных менеджеров (npm, yarn, pnpm, pip, pipenv, poetry) установка зависимостей происходит автоматически; для сложной сборки пишется свой setup-скрипт. Важная деталь: setup-скрипт выполняется в отдельной bash-сессии, поэтому export в фазу агента не переносится — переменные кладут в ~/.bashrc или в настройки окружения.

Кэш. Состояние контейнера кэшируется до 12 часов. При возобновлении кэша делается checkout нужной ветки и выполняется maintenance-скрипт, если он задан. Кэш инвалидируется автоматически при изменении setup-скрипта, maintenance-скрипта, переменных окружения или секретов; сбросить вручную можно кнопкой на странице окружения.

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

Область правил — самое неочевидное. В монорепо действуют два РАЗНЫХ механизма, и они охватывают разное:

Из этой таблицы следует практический вывод, который стоит проверить у себя прямо сейчас. Один и тот же файл services/payments/AGENTS.md повлияет на ревью любого PR, трогающего платежи, — но может не доехать до задачи, если суммарный объём инструкций по цепочке уже превысил 32 KiB. В большом монорепо с раздутым корневым файлом это происходит буднично и незаметно: агент просто работает без ваших сервисных правил.

Что делать:

• держать корневой AGENTS.md коротким — общие команды, стиль PR, запреты;
• сервисные подробности класть рядом с кодом, а не в корень;
• при упоре в лимит поднимать project_doc_max_bytes или дробить инструкции по вложенным директориям;
• помнить про AGENTS.override.md — он читается вместо обычного файла в той же директории, и это удобный способ дать команде временное исключение.

Небольшой расчёт для ориентира. 32 KiB — это примерно 32 тысячи символов, то есть около 15–20 страниц текста. Корневой файл на 4 KiB плюс семь уровней вложенности по 4 KiB — и лимит выбран целиком, хотя субъективно «файлы небольшие». В монорепо на 30 сервисов такая арифметика перестаёт быть теоретической.

Приватность кода и политики организации при подключении Codex

Разговор про приватность в выдаче обычно сводится к общим словам. Разберём предметно: что где оказывается и какими рычагами это ограничивается.

Куда уезжает код. При облачной задаче репозиторий клонируется в изолированный контейнер на стороне сервиса на выбранной ветке или коммите. Весь исходящий трафик окружения идёт через HTTP/HTTPS-прокси. Интернет в фазе агента выключен по умолчанию; при необходимости включается ограниченный (по списку доменов) или неограниченный доступ.

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

Какими рычагами это ограничивается. Их три, и они не совпадают:

1. Права аккаунта в GitHub. Именно подключённая система решает, какие репозитории видит Codex. В таблице ролей это зафиксировано прямо: доступ к Codex cloud даёт право пользоваться облачными сценариями, а права на репозиторий приходят из исходной системы.
2. Право на облачные сценарии в воркспейсе — отдельная сущность, не совпадающая ни с членством в воркспейсе, ни с правами в репозитории.
3. Настройки установки приложения в GitHub — конкретный список репозиториев, к которым приложение допущено.

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

Отзыв доступа делается в двух местах: отдельно отзывается токен доступа, отдельно — доступ к репозиториям. Одно не отменяет другое.

Риски GitHub-интеграции Codex: где процесс ломается

Список того, что реально идёт не так, — с датами проверки.

• Границу доступа лучше проверять глазами. В трекере продукта есть открытая задача №24548 (создана 26 мая 2026, на 13 августа 2026 открыта): после переустановки коннектор показывал посторонние подключённые аккаунты и приватный репозиторий с правом push. Отдельная задача №15476 (создана 22 марта 2026, закрыта на следующий день со статусом «не запланировано») описывает случай, когда Codex создал репозиторий публичным без явного указания видимости.
• Инъекция инструкций приезжает вместе с содержимым репозитория. Официальный чек-лист безопасности требует санитизировать вход из pull request, сообщений коммитов и тел issue и проверять HTML-комментарии и скрытый текст. Ревью чужого PR — это по определению чтение недоверенного текста.
• Права приложения непрозрачны — см. раздел про ChatGPT Codex Connector. Решение об установке принимается по экрану GitHub, а не по документации вендора.
• Согласование обнуляется на каждой итерации агента — механика разобрана выше; без настройки правил это скрытая налоговая нагрузка на команду.
• Ревью расходует квоту, а не идёт бонусом к подписке.
• Плюс в вашу пользу: дефолты консервативны. Сеть агента закрыта, секреты не доживают до фазы агента, доступ к репозиториям выбирается поштучно. Риск создаёт тот, кто эти дефолты ослабляет.
• Плюс второй: черновой PR даёт буфер. Владельцев кода не зовут на черновики — значит итерации агента не превращаются в поток уведомлений.
• Плюс третий: правила ревью не расползаются. Сервис в монорепо несёт свои проверки, посторонние изменения чужой контекст не тащат.

Лимиты и тарифы: когда GitHub-интеграция Codex просто недоступна

Самый недооценённый факт всей темы: доступ к GitHub-интеграции — это техническое условие плана, а не вопрос цены.

На странице тарифов по состоянию на 13 августа 2026 у варианта с оплатой по API-ключу написано дословно: «No cloud-based features (GitHub code review, Slack, etc.)» — доступны только CLI, SDK и расширение IDE. У планов ChatGPT формулировка обратная: «Cloud-based integrations like automatic code review and Slack integration».

То есть команда, которая гоняет Codex на ключе платформы, приложение в GitHub не получит вообще. Единственный путь для неё — GitHub Action.

Второе, что стоит учесть при планировании: у ревью отдельная квота. В таблицах лимитов колонка «Code Reviews / 5h» стоит отдельно от «Local Messages» и «Cloud chats», причём последние две делят общее пятичасовое окно; дополнительно могут действовать недельные лимиты.

Практический смысл колонки лимитов простой. Включая автоматическое ревью на активном репозитории, посчитайте число pull request в неделю. Двадцать PR в неделю — это двадцать ревью плюс доработки по замечаниям, и каждая доработка это ещё и облачный чат. Планировать это как «бесплатный бонус подписки» — верный способ упереться в лимит в день релиза.

Прогон issue → pull request → мерж: пошаговый сценарий команды

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

1. Возьмите issue и превратите её в задачу. Скопируйте требования в текст задачи: что должно получиться, чего трогать нельзя, чем проверяется результат. Приложите ссылку на issue отдельной строкой.
2. Запустите задачу на актуальной ветке. Из терминала это codex cloud exec --env <ENV_ID> --branch main "<текст задачи>". Для рискованных изменений добавьте --attempts 3.
3. Дождитесь результата и посмотрите дифф. В интерфейсе — итог и список изменённых файлов; из терминала — codex cloud diff <TASK_ID>.
4. Если результат сырой, уточните задачу, а не правьте руками: следующая итерация должна опираться на тот же контекст.
5. Откройте pull request черновиком. Черновик прогонит CI и не поднимет владельцев кода раньше времени.
6. Запросите ревью: комментарий @codex review в PR. Дождитесь реакции-подтверждения и опубликованного ревью. Если ревью автоматическое, оно придёт само.
7. Разберите находки. Codex в GitHub отмечает только P0 и P1 — если он молчит, это не значит «идеально», это значит «критичного не увидел».
8. Попросите починить нужное: @codex fix the P1 issue. Либо разберите замечания из панели ревью на своей машине, если правок много.
9. Проверьте дифф после правки. Это обязательный шаг: агент чинит то, что понял, а не то, что имелось в виду.
10. Переведите PR из черновика в готовый. Вот теперь придут владельцы кода и обязательные проверки.
11. Соберите апрувы. Помните про правило последнего пушившего: если последним пушил агент, одобрять должен человек.
12. Мержите. В строгом режиме проверок сначала подтяните базовую ветку — и заново пройдите шаг 11.

Если на шаге 6 ничего не происходит, официальный список причин короткий: ревью не включено для репозитория; у репозитория не настроен Codex cloud; использован неточный триггер; для автоматических ревью — не включены автоматические ревью или событие pull request не подходит под настройки.

Ещё одна причина «PR вышел без проверок» лежит за пределами Codex и ловит многих: события, созданные штатным токеном GITHUB_TOKEN внутри Actions, не запускают другие workflow, а токен установки GitHub-приложения — запускает. Если агент у вас работает внутри workflow на штатном токене, отсутствие проверок на его PR — правило платформы, а не поломка агента.

Чек-лист внедрения Codex в GitHub-процесс команды

Пройдите по списку до того, как агент получит доступ к рабочему репозиторию.

Доступ и права

• Проверен способ оплаты: при API-ключе облачных функций нет, планируйте GitHub Action.
• Выбран конкретный список репозиториев в установке приложения, а не «вся организация».
• Скриншот экрана установки с полным списком прав сохранён в тикет.
• Проверено фактически, есть ли у приложения право записи (иначе доработка по ревью не доедет до ветки).
• Записано, кто в команде имеет push или admin права, чтобы включать и выключать интеграцию.

Правила репозитория

• В корневом AGENTS.md есть команды сборки, линта и тестов.
• Есть секция ## Code Review Rules с двумя-тремя правилами, специфичными для репозитория.
• Механические проверки (формат, линт) оставлены CI, а не описаны словами.
• Требование заполнять шаблон pull request продублировано в инструкциях проекта.
• В монорепо сервисные правила лежат рядом с кодом, а объём цепочки инструкций проверен на лимит 32 KiB.

Процесс и защита ветки

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

Безопасность и эксплуатация

• Секреты лежат в секретах окружения (доступны setup-скрипту), а не в переменных.
• Сетевой доступ агента оставлен выключенным или ограничен списком доменов.
• Команда предупреждена про инъекции через тела issue и описания PR.
• Посчитана недельная нагрузка на квоту ревью по числу pull request.
• В монорепо учтено, что сброс кэша окружения задевает всех его пользователей.

Что устареет первым. Быстрее всего в этой теме меняются: версия CLI и состав подкоманд (на 13 августа 2026 — 0.147.0, релиз от 7 августа 2026), статус Security Review как research preview, состав таблиц лимитов и набор триггеров в pull request. Проверять у себя стоит тремя способами: codex --version в терминале, страница настроек ревью в Codex и экран установки приложения в GitHub — именно там видно текущее положение дел, а не в статьях.

FAQ

Можно ли назначить GitHub Issue на Codex, как назначают на разработчика?

Нет. Официальная документация описывает упоминание @codex только в комментариях к pull request, а запрос на нативную интеграцию задач в трекере продукта закрыт 20 марта 2026 со статусом «не запланировано». Рабочая схема — скопировать требования из issue в текст задачи и приложить ссылку на неё, а стартовать работу с веба, из pull request, из Linear или из Slack.

Какие права запрашивает приложение ChatGPT Codex Connector в репозитории?

Публичного списка нет: на странице приложения по состоянию на 13 августа 2026 указаны только имя, издатель и описание. Полный набор разрешений вы увидите на экране установки в GitHub — этот экран стоит сохранить скриншотом. Практика показывает, что коннектор бывает и читающим: в трекере описан случай с правами pull: true, push: false, когда запись пришлось делать через утилиту gh.

Может ли ревью Codex засчитаться как обязательный апрув в защите ветки?

Нет, и это позиция обеих сторон. Документация Codex прямо говорит, что правила ревью не заменяют тесты, защиту ветки и обязательные одобрения. Со стороны GitHub обязательный апрув считается от рецензентов с правом записи, а владельцами кода могут быть только пользователи и команды — приложение в этой роли не предусмотрено. Обязательными делайте детерминированные проверки CI.

Работает ли GitHub-интеграция Codex, если платить по API-ключу, а не по плану ChatGPT?

Нет. На странице тарифов у варианта с API-ключом прямо написано, что облачных функций, включая ревью кода в GitHub и интеграцию со Slack, нет — доступны только CLI, SDK и расширение IDE. Команде на API-ключе остаётся третий путь: запускать агента внутри workflow через действие openai/codex-action@v1 с явно выданными правами.

Что делать, если Codex не реагирует на @codex review в pull request?

Официальный список причин короткий. Проверьте, что ревью включено именно для этого репозитория в настройках Codex; что у репозитория настроен Codex cloud; что использован точный триггер @codex review, а не его вольный пересказ. Для автоматических ревью дополнительно проверьте, что включён переключатель автоматических ревью и что событие pull request попадает под ваши настройки триггера.

Как ограничить Codex одним репозиторием организации и как отозвать доступ?

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