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 під вашим контролем.

BINANCE SIMPLE EARNЗмусь крипту працюватиВідсотки на USDT і BTC без блокування — гроші лишаються під рукою.Розмістити

Третій шлях — локальний 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».

BINANCE SIMPLE EARNЗмусь крипту працюватиВідсотки на USDT і BTC без блокування — гроші лишаються під рукою.Розмістити

А тепер неприємна частина. Публічного переліку прав у цього застосунку немає. На сторінці застосунку станом на 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 під час встановлення застосунку: вибирається конкретний перелік репозиторіїв, а не вся організація. Право користуватися хмарними сценаріями — окреме налаштування воркспейсу, воно не збігається ні з членством у воркспейсі, ні з правами в репозиторії. Відкликання робиться у двох місцях: окремо відкликається токен доступу, окремо — доступ до репозиторіїв, і одне не скасовує іншого.