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

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

BINANCE COPY TRADINGКопітрейдинг на BinanceВідкрита статистика трейдерів, старт з $10, вимкнення одним кліком.Обрати трейдера

Що потрібно мати до початку:

OpenAI Codex у CI/CD: коди повернення, потік JSONL і ціна прогону

Пісочниця 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, як це зробив би колега. Реакція важлива практично: якщо її немає, рев’ю не стартувало, і далі є сенс іти в діагностику, а не чекати.

BINANCEДосі дивишся збоку?Ринок працює без вихідних. Рахунок на Binance відкривається за 2 хвилини.Почати зараз

Автоматика на кожен 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 здатен надіслати виправлення назад у гілку — за умови, що він має відповідні права доступу. Без явної команди рев’юер обмежується коментарями.