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

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

• Codex Code Review — это облачный ревьюер, который читает диф pull request и оставляет обычное GitHub-ревью. Включается тумблером в настройках Codex, запускается комментарием @codex review или автоматически на каждый новый PR.
• В GitHub он показывает только находки уровня P0 и P1 — самые серьёзные. Это встроенное отсечение, а не сбой: если ревью «ничего не нашло», чаще всего оно просто промолчало про мелочи.
• Главный рычаг качества — секция ## Code Review Rules в файле AGENTS.md. Правила можно раскладывать по подкаталогам, но все инструкции вместе ограничены 32 КиБ.
• Ревью тратит отдельный бюджет Code Reviews / 5h, а не общий лимит сообщений. При этом на 13 августа 2026 конкретных чисел в этой колонке OpenAI не публикует — там стоит Not available на всех тарифах.
• На тарифе с API-ключом GitHub-ревью недоступно вовсе. Остаётся локальная команда /review или самостоятельная сборка через GitHub Action.
• Ревью не заменяет тесты, branch protections и обязательные аппрувы — это прямая оговорка вендора, и её стоит держать в голове при перестройке процесса.

Три разных «ревью» в Codex: @codex review, /review и auto_review

Это первое, обо что спотыкаются команды. В Codex есть три механизма со схожими названиями, и они решают совершенно разные задачи. Половина вопросов вида «включил авто-ревью, а в PR ничего не появилось» — это попадание не в тот тумблер.

Третий пункт — самый коварный. auto_review к ревью кода отношения не имеет вообще: это автоматическое одобрение запросов агента, когда он просится выполнить команду или сходить в сеть. Документация описывает его буквально как «подмену ревьюера, а не выдачу прав» — сам набор разрешений при этом не меняется. Если вы искали «автоматическое ревью PR», а нашли approvals_reviewer — вы не там.

Дальше в статье речь идёт только про первый столбец: облачное ревью pull request на GitHub.

Как подключить Codex Code Review к репозиторию на GitHub

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

BYBITВсё ещё смотришь со стороны?Рынок работает без выходных. Счёт на Bybit открывается за 2 минуты.Начать сейчас

Что нужно иметь до начала:

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

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

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

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

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

1. Настроенный Codex cloud для этого репозитория. Ревью PR — облачная функция, локальный агент её не выполняет. Если облако для репозитория не подключено, триггер просто не сработает.
2. Доступ к настройкам код-ревью Codex.
3. Право push или admin на настройки репозитория в GitHub. Доступа на чтение недостаточно — рядовой контрибьютор включить ревью не сможет.
4. Файл AGENTS.md — опционально. Он нужен, только если вы хотите, чтобы ревьюер следовал вашим правилам, а не общим представлениям о хорошем коде.

Сама процедура:

1. Настроить Codex cloud для нужного репозитория.
2. Открыть настройки Codex (страница настроек код-ревью — chatgpt.com/codex/settings/code-review).
3. Включить Code review для конкретного репозитория.

После этого ревью работает в ручном режиме — по упоминанию. Автоматика включается отдельным тумблером, о нём ниже.

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

Триггеры: @codex review, автоматика на каждый PR и точечный фокус

Запустить ревью можно тремя способами, и они не взаимоисключающие.

Ручной запуск. В комментарии к pull request написать:

@codex review

Codex ставит под комментарием реакцию «глаза» — это сигнал, что задача принята и ревью пошло. Затем он публикует обычное code review, как это сделал бы коллега. Реакция важна практически: если её нет, ревью не стартовало, и дальше есть смысл идти в диагностику, а не ждать.

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

Автоматика на каждый PR. В настройках Codex включается тумблер Automatic reviews. После этого ревью публикуется каждый раз, когда кто-то открывает новый pull request на ревью, — упоминание больше не нужно.

Точечный фокус. Ревью можно сузить до конкретного участка изменений прямо в комментарии:

@codex review for issues in the database migration

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

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

@codex fix the P1 issue

Тогда запускается облачный чат с этим PR в контексте, и Codex может запушить правку в ветку — но только если у него есть на это право. Разделение намеренное и полезное: ревьюер, который сам молча переписывает ваш PR, был бы гораздо неприятнее.

Отдельно стоит запомнить: любое упоминание @codex с текстом, отличным от review, запускает не ревью, а обычную облачную задачу с этим PR в контексте. Например, @codex fix the CI failures — это уже не ревьюер, а исполнитель.

Почему Codex пишет только P0 и P1 и молчит про остальное

Самая частая претензия к автоматическому ревьюеру звучит так: «прогнали на PR с очевидными косяками, а он написал две строчки». Это ожидаемое поведение, а не поломка.

В GitHub Codex публикует только находки уровня P0 и P1. Это классификация по приоритету: P0 — то, что ломает продукт или безопасность прямо сейчас, P1 — серьёзная проблема, которую нельзя оставлять в мерже. Всё, что ниже по важности, до комментариев в PR не доходит. Формулировка вендора прямая: отсечение сделано, чтобы комментарии оставались сосредоточены на рисках высокого приоритета.

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

Из этого следуют два вывода:

• Тишина в PR — это не всегда «всё хорошо». Это «нет находок уровня P0 и P1». Мелкие огрехи стиля и локальные шероховатости остаются на вас, вашем линтере и вашем ревьюере-человеке.
• Строгость нельзя «прикрутить» в настройках. У GitHub-ревью нет ползунка чувствительности. Единственный способ повлиять на то, что считается достойным комментария, — правила ревью в AGENTS.md. Если вам нужен более придирчивый разбор, локальная команда /review отдаёт находки без такого отсечения.

Правила ревью в AGENTS.md: секция, вложенность и лимит 32 КиБ

Вот здесь ревью перестаёт быть коробочным и становится вашим. Codex ищет в репозитории файлы AGENTS.md и выполняет те правила ревью, которые в них записаны.

Синтаксис. Правила живут в секции с фиксированным заголовком:

## Code Review Rules

### Экспериментальные когорты

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

Заголовок ## Code Review Rules — обязательный маркер, по нему секция и опознаётся. Подзаголовки ### нужны для группировки связанных проверок, когда правил становится много.

Вложенность. Правила кладутся в тот файл, который ближе всего к коду, которым они управляют:

• корневой AGENTS.md — правила на весь репозиторий;
• вложенный, например services/experiment_reporting/AGENTS.md, — правила конкретного сервиса.

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

Лимит, о котором почти никто не пишет. Суммарный объём инструкций ограничен 32 КиБ (параметр project_doc_max_bytes). По достижении лимита Codex просто перестаёт добавлять файлы. Отсюда неочевидное следствие: правила ревью делят бюджет со всем остальным содержимым AGENTS.md — командами сборки, соглашениями по коммитам, описанием архитектуры. Если файл разросся, часть правил ревью может молча не доехать до ревьюера, и вы об этом не узнаете — предупреждения не будет.

Практический вывод: раздутый AGENTS.md — это не только медленный старт агента, но и риск потерять именно те правила, ради которых вы всё затевали.

Как написать правило, которое не шумит: инвариант плюс safe path

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

Если свести рекомендации OpenAI к формуле, в ней три части: что защищаем, почему это важно, что делать автору вместо.

Плохо:

- Пиши понятный код и не ломай обратную совместимость.

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

Хорошо:

### Ломающие изменения

Ищи ломающие изменения во внешних точках интеграции:

- события сырых элементов ответа (`rawResponseItem/*`), даже если они помечены экспериментальными.

Здесь названа конкретная поверхность, и агент понимает, где именно смотреть.

Почему safe path обязателен. Без него ревьюер не может отличить настоящую проблему от ожидаемого поведения — и на всякий случай пишет замечание. С ним находка превращается в готовое решение. Вот как выглядит формулировка находки из примера OpenAI: потребители в облаке слушают это имя события, поэтому переименование их сломает, даже если событие экспериментальное; сохраните прежнее имя или добавьте обратно совместимое событие, как описано в AGENTS.md.

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

Рабочие ограничения, которые стоит принять сразу:

• Начинайте с двух-трёх правил, а не с полного свода. Широкие инструкции создают шум — об этом предупреждает сам вендор.
• Механику оставляйте в CI. Форматирование, линт и прочие детерминированные проверки в правилах ревью не нужны и только отнимают внимание.
• Правила должны переживать рефакторинг. Описывайте результат и границу, а не имена функций, которые завтра переименуют.
• Правило, которое шумит, — сужайте или удаляйте. Это штатная процедура настройки, а не признание поражения.

Насколько это вообще влияет на результат? По внутреннему замеру OpenAI, вариант с правилами находил 98% нужных специфичных проблем против 58,3% в контрольном прогоне без них. Цифру стоит читать с поправкой: это замер вендора на собственной выборке, методология и состав репозиториев не раскрыты. Порядок эффекта она показывает, точность — нет.

Чем ревью Codex отличается от линтера и от ревью человеком

Инструмент занимает узкую полосу между двумя привычными механизмами и не заменяет ни один из них.

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

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

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

Для сравнения с соседями по классу: Bugbot в Cursor и авто-ревью PR у Claude Code решают ту же задачу, но по-своему — с другой моделью оплаты и другими настройками строгости.

Лимиты ревью: свой бюджет, пустая таблица и сбой учёта

Здесь придётся сказать неудобную вещь, которую остальные обзоры повторяют друг за другом неверно.

Ревью действительно расходует отдельный бюджет. В таблице лимитов Codex есть самостоятельная колонка Code Reviews / 5h, и правило расхода сформулировано так: бюджет ревью тратится, только когда Codex выполняет ревью через GitHub — по тегу @codex в PR или по включённой автоматике. Ревью, запущенные локально или вне GitHub, идут в общий лимит. То есть /review в терминале ваш запас PR-ревью не съедает.

А вот конкретных чисел у этой колонки нет. На 13 августа 2026 в официальной таблице тарифов OpenAI колонка Code Reviews / 5h заполнена значением Not available — по всем моделям и на всех тарифах: Plus, Pro 5x, Pro 20x, Business и API. Для сравнения, соседняя колонка локальных сообщений числа содержит: например, на Plus для GPT-5.6 Sol это 10–100 за пятичасовое окно, на Pro 5x — 50–500.

Это стоит проговорить отдельно, потому что по сети гуляют уверенные цифры вроде «20–50 ревью за пять часов на Plus». На странице вендора этих чисел нет. Откуда они взялись у трекеров — неизвестно, и сверить их не с чем. Планировать нагрузку команды на такие числа не стоит.

Данные со страницы тарифов OpenAI на 13 августа 2026.

Отдельная боль — учёт. В обсуждении #8503 в репозитории openai/codex разбирается ситуация, когда ревью падает с ошибкой «You have reached your Codex usage limits for code reviews», хотя панель показывает 100% нетронутого остатка. К обсуждению подключились более двадцати участников с тем же симптомом, отвечали мейнтейнеры OpenAI, но решения в треде нет. Смежный запрос сообщества на вменяемые лимиты ревью висит отдельной задачей (#7598). Если вы упёрлись в лимит при полном счётчике — это известная ситуация, а не ваша ошибка настройки.

Приватность: куда уходит код и кто видит находки в публичном PR

Для ревью Codex получает содержимое дифа и контекст репозитория — иначе он работать не может. Дальше начинаются различия, которые стоит знать до подключения.

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

Права доступа. Codex работает с репозиториями, которые вы явно выбрали при подключении GitHub, и не обходит ограничения, выданные на стороне GitHub. Чтобы Codex запушил исправление, у него должно быть на это право — без него он ограничится комментарием.

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

Что это означает на практике: автоматическое security-ревью на публичном репозитории публикует описания найденных слабых мест туда, где их прочитает кто угодно — в том числе тот, кто ищет, за что зацепиться. Полный отчёт при этом остаётся внутри Codex, а в GitHub уходит только то, что проходит порог важности. Управление порогом здесь — инструмент приватности, а не качества.

Security Review: пороги важности и почему его нет на Plus

Security Review — не режим обычного ревью, а отдельный продукт поверх него, и правила у него свои. На 13 августа 2026 он находится в статусе research preview.

Доступность отличается от обычного ревью. Он доступен клиентам ChatGPT Enterprise, Business, Edu и Pro — и недоступен на Plus. Во вводный период он не расходует кредиты ChatGPT, хотя лимиты применяться могут. То есть команда на Plus получит обычное ревью, но не углублённый разбор безопасности.

Запускается вручную комментарием @codex security review, полный отчёт с оценкой серьёзности, вектором атаки, подтверждениями и рекомендациями по устранению открывается во вкладке Security Report связанной задачи Codex.

Настройка охвата живёт в разделе Repository preferences и состоит из двух независимых вопросов — какие PR и когда:

Строку про Review team PRs стоит перечитать дважды: название подсказывает «команда GitHub», а на деле речь про рабочее пространство ChatGPT. Это готовая ловушка при настройке в организации, где эти два состава не совпадают.

Пороги отчётности заданы по умолчанию по-разному для автоматики и ручного запуска: автоматические security-ревью сообщают о находках уровня High и Critical, ручные — Medium, High и Critical. Минимальную важность можно менять для этих режимов независимо и добавлять переопределения по путям.

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

GitHub Action openai/codex-action: ревью без подписки ChatGPT

Если у вас тариф с API-ключом, штатное GitHub-ревью недоступно: это облачная функция подписки. Карточка тарифа API Key говорит об этом прямо — облачных возможностей, включая GitHub code review, там нет. Выход — собрать ревью самостоятельно на официальном экшене openai/codex-action@v1.

Ключевые входы экшена: openai-api-key (из секретов репозитория), prompt или prompt-file с заданием, model и effort, sandbox со значениями workspace-write, read-only или danger-full-access, а также safety-strategy — по умолчанию drop-sudo, плюс варианты unprivileged-user, read-only и unsafe. Ограничить круг запускающих помогают allow-users и allow-bots. Результат работы отдаётся в выходе final-message — его и публикуют отдельным шагом как комментарий к PR.

Важное ограничение платформы: на Windows поддерживается только стратегия unsafe — песочницы там нет. Для ревью на раннерах Linux и macOS доступны все стратегии, и для агента, который читает чужой код из пул-реквеста, режим только на чтение выглядит разумным умолчанием.

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

Codex не отвечает на @codex review: чек-лист из четырёх пунктов

Молчание в ответ на упоминание — самая частая эксплуатационная проблема. Официальная диагностика короткая, и проходить её стоит по порядку.

1. Проверьте, что тумблер Code review включён именно для этого репозитория в настройках Codex. Включение для организации не означает включение для каждого репозитория.
2. Убедитесь, что pull request принадлежит репозиторию с настроенным Codex cloud. Без облака ревью не выполняется.
3. Сверьте написание триггера. Нужен точный @codex review. Вариации вроде «codex, посмотри пожалуйста» или упоминание с другим текстом запустят обычную облачную задачу, а не ревью.
4. Для автоматики проверьте два условия сразу: включён ли тумблер Automatic reviews и попадает ли событие вашего PR под настроенные триггеры.

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

Риски Codex Code Review и пять сценариев, где он не подходит

Инструмент полезный, но у него есть очерченная зона неприменимости.

• Вам нужен придирчивый разбор стиля. Отсечение по P0/P1 отрежет ровно то, что вы ждёте. Это работа линтера и форматтера в CI.
• Вы работаете на публичном репозитории с чувствительными находками. Автоматическое security-ревью опубликует их там, где их увидят все. Либо поднимайте порог важности, либо оставляйте ручной запуск.
• Вам нужна предсказуемость до символа. Формулировки находок меняются между прогонами. Для gate-проверок, от которых зависит мерж, нужен детерминированный инструмент, а не вероятностный.
• У вас тариф с API-ключом и нет желания поддерживать свой workflow. Штатного ревью там нет, а самосборка на экшене — это код, который придётся сопровождать.
• Вы рассчитываете заменить ревьюера-человека. Вендор прямо говорит, что правила ревью не заменяют тесты, защиту веток и обязательные аппрувы. Экономия выйдет на внимании к мелочам, а не на ответственности за решение.

И честная оговорка про темп изменений: имена тумблеров, состав опций Security Review, статус research preview и особенно содержимое колонки лимитов — всё это в Codex меняется быстро. Всё, что описано выше, проверено 13 августа 2026 по документации вендора. Первое, что устареет, — числа лимитов (сегодня их нет, завтра могут появиться) и набор настроек Security Review; сверять стоит по странице интеграции с GitHub и по таблице тарифов.

FAQ

Делает ли Codex CLI ревью pull request само по себе?

Нет. Команда /review в CLI работает с локальным состоянием репозитория: диф ветки, незакоммиченные изменения или конкретный коммит. Она пишет находки в панель ревью и ничего не отправляет в GitHub. Ревью самого pull request с публикацией комментариев выполняет облако Codex по триггеру @codex review, и для него нужен настроенный Codex cloud.

Тратит ли @codex review лимиты моей подписки ChatGPT?

Да, но из отдельного кармана. У ревью через GitHub свой бюджет — колонка Code Reviews / 5h в таблице лимитов, — и он не расходует общий запас сообщений. Обратное тоже верно: ревью, запущенные локально через /review или вне GitHub, списываются с общего лимита. Конкретных чисел по бюджету ревью OpenAI на 13 августа 2026 не публикует.

Можно ли отключить автоматическое ревью для черновиков PR?

Отдельного переключателя именно под черновики у Codex нет — но охватом автоматики управлять можно. Для обычного Code Review это тумблер Automatic reviews в настройках Codex, а для Security Review — раздел Repository preferences с выбором, какие pull request попадают под ревью и когда оно запускается. Если автоматика создаёт шум на незрелых ветках, рабочий путь — выключить её и оставить ручной запуск по @codex review, когда PR действительно готов.

Обучается ли OpenAI на коде из моего репозитория?

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

Чем Code Review отличается от Security Review?

Code Review — обычное ревью дифа, доступное в том числе на Plus, с отсечением по P0/P1. Security Review — отдельный, более глубокий разбор рисков безопасности с моделью угроз и порогами важности, на 13 августа 2026 он в статусе research preview и доступен на Enterprise, Business, Edu и Pro, но не на Plus. Находки частично пересекаются, и это нормально.

Может ли Codex сам починить то, что нашёл, и запушить в ветку?

Может, но только по отдельной команде. Само ревью код не трогает. Если оставить в pull request комментарий вида @codex fix the P1 issue, запускается облачный чат с этим PR в контексте, и Codex способен отправить исправление обратно в ветку — при условии, что у него есть соответствующие права доступа. Без явной команды ревьюер ограничивается комментариями.