Git and GitHub Integration: PR Review

📚 Навигация по серии: Предыдущая статья 25 · Параллельная изоляция Worktrees научила вас использовать git worktree для создания «параллельных полос» движения для Codex, чтобы выполнять несколько задач одновременно без конфликтов. В этой статье мы перенесемся из локального терминала в репозиторий GitHub: вы узнаете, как внедрить Codex в свои Pull Request, чтобы он автоматически делал ревью кода, находил ошибки по вашим правилам и отправлял исправления прямо в ветку. В следующей статье 27 · Автоматизация и CI/CD мы перенесем этот процесс в конвейер CI для работы в режиме «без участия человека».

Начнем с классической ситуации, которая происходит в командах каждый день. С момента создания PR до его слияния львиная доля времени уходит вовсе не на само ревью, а на ожидание ревьюера. Команда небольшая, все заняты, и ваш PR просто висит — день ожидания уже стал нормой.

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

Интеграция Codex с GitHub создана как раз для этого: упомяните его через @ в комментариях к PR, и он, как неутомимый коллега, проанализирует diff и укажет на критические риски прямо в PR в соответствии с правилами вашего репозитория. Вам не нужно выходить из GitHub, и он не пытается отобрать у вас право финального решения — ревью делает ИИ, а кнопку слияния нажимаете вы. Эту границу мы последовательно проводим начиная с 15-й статьи о правах доступа.

Прочитав эту статью, вы получите:

• Понимание того, как команда @codex review запускает проверку в PR, что отвечает ИИ и какие уровни проблем он находит (P0/P1 по официальной классификации)
• Инструкцию по включению «автоматического ревью» — когда каждый новый PR проверяется без необходимости вручную упоминать бота через @
• Способ настройки правил ревью с помощью раздела Review guidelines в файле AGENTS.md: запрет на логирование данных, проверка авторизации маршрутов и т. д. — пусть Codex ищет ошибки по вашим стандартам
• Использование команды @codex fix для автоматического исправления замечаний и отправки изменений обратно в ветку, а также разбор границ прав доступа в этом процессе
• Опыт использования локальной команды /review: проверка изменений в терминале перед отправкой PR, при которой код остается нетронутым
• Понимание того, какие задачи можно спокойно делегировать ИИ, а какие «красные линии» (например, слияние веток) вы должны контролировать лично

⚠️ Описываемое в статье ревью на GitHub (@codex review, авторевью) использует возможности Codex cloud, для этого требуется платная подписка и предоставление доступа к репозиторию. Локальная команда /review работает без облака. Мы разберем обе схемы отдельно, не путайте их.

---

01 Разделим два сценария: Codex на GitHub и Codex в вашем терминале

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

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

Применительно к Codex эти сценарии выглядят так:

Сценарий 1: Запуск через GitHub (облако). Вы пишете @codex review в комментариях к PR на GitHub. Codex запускает задачу в облаке, анализирует diff репозитория и оставляет комментарии к коду, как обычный участник команды. Вы находитесь в интерфейсе GitHub, а вычисления происходят на серверах OpenAI (подробнее об этом читайте в 10-й статье про Codex cloud). Важное условие: репозиторий должен быть подключен к Codex cloud, а в его настройках активирована функция Code review.

Сценарий 2: Локальный вызов через /review (CLI). Вы вводите команду /review в терминале внутри сессии Codex. Задача выполняется на вашей локальной машине. Codex анализирует указанный diff (незакоммиченные правки, разницу с целевой веткой, конкретный коммит...) и выводит отчет. Этот режим полностью безопасен для кода: ИИ работает в режиме «только чтение» и не изменяет файлы. Подключение к GitHub и облаку не требуется.

Параметр	Через GitHub: @codex review	Локально: /review
Где запускается	В комментариях к PR на GitHub	В терминале сессии Codex
Где выполняются вычисления	Codex cloud (облако)	Локальный компьютер
Что анализируется	Diff текущего Pull Request	Выбранный diff (незакоммиченные изменения / сравнение с веткой / коммит)
Где публикуется результат	В виде комментариев к строкам кода в PR	Выводится в консоль
Что требуется	Настройка cloud + включение Code review	Работает сразу «из коробки»
Меняет ли код	Нет (если только не дать команду @codex fix)	Исключено (режим «только чтение»)

В этой главе мы сосредоточимся на первом сценарии (интеграция с GitHub), так как он лежит в основе совместной работы. Локальную команду /review мы детально разберем в разделе 06 как удобный этап самопроверки перед созданием PR.

💡 Резюме в одном предложении: Проверка кода в Codex разделена на два сценария: на GitHub по команде @codex review (запуск в облаке, публикация комментариев в PR) и в терминале по команде /review (локальный запуск в режиме «только чтение»).

---

02 Команда @codex review: находим ошибки в PR

Базовый способ использования невероятно прост: напишите комментарий @codex review в обсуждении Pull Request на GitHub.

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

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

На практике перейдите на GitHub и введите в комментарии к PR:

@codex review

После этого процесс пойдет по следующему сценарию:

1. Codex добавит реакцию 👀 к вашему комментарию — это подтверждение того, что задача принята в работу.
2. В облаке запустится контейнер, который скачает diff текущего PR и сверит его с правилами ревью репозитория (о них в следующем разделе).
3. После завершения анализа Codex оставит комментарии к конкретным строкам кода, указав на найденные проблемы.

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

На GitHub Codex отмечает только проблемы уровней P0 (критические) и P1 (высокий приоритет), чтобы не перегружать обсуждение мелкими замечаниями.

Говоря простым языком: он намеренно не спамит замечаниями по оформлению. Сообщения будут касаться только серьезных багов. По моему опыту, это отличное решение. В других инструментах на базе ИИ меня больше всего раздражало, когда на небольшой PR робот оставлял по 40 замечаний в духе «переименуйте переменную», из-за чего реальные уязвимости терялись в шуме. Лаконичность Codex гарантирует, что к каждому его комментарию стоит отнестись серьезно.

Реальный пример из моей практики: недавно коллега создал PR с изменениями в обработке платежных транзакций. Я сосредоточился на логике расчета сумм, а после запуска @codex review ИИ выставил замечание уровня P1 — в обработчике платежей отсутствовала проверка на идемпотентность, что могло привести к двойному списанию средств при повторном запросе. Я эту проблему при ручном осмотре проглядел.

💡 Резюме в одном предложении: Команда @codex review в PR запускает анализ diff в облаке. ИИ отмечает только критические проблемы P0/P1, не засоряя ветку комментариями о стиле, что делает каждое его замечание весомым.

---

03 Автоматическое ревью: проверка каждого нового PR без напоминаний

Команда @codex review запускается вручную, но о ней легко забыть, особенно когда PR создают другие разработчики в команде. Для автоматизации процесса предусмотрен переключатель Automatic reviews.

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

Как включить автопроверку? В документации указано:

Если вы хотите, чтобы Codex автоматически проверял каждый Pull Request, включите опцию Automatic reviews в настройках. После этого при открытии любого PR помощник сам проведет анализ, команда @codex review больше не потребуется.

Настройка выполняется в два шага в личном кабинете на сайте OpenAI (не на GitHub):

1. Перейдите в раздел настроек Code review в Codex (ссылка по умолчанию: https://chatgpt.com/codex/settings/code-review или через меню профиля chatgpt.com → Codex → Settings → Code review).
2. Активируйте переключатель Automatic reviews.

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

Как выбрать между ручным и автоматическим режимами? Вот краткое сравнение:

Критерий	Ручной запуск (@codex review)	Автоматическое ревью
Активация	Комментарием под PR	Автоматически при создании/обновлении PR
Человеческий фактор	Легко забыть отправить команду	Работает всегда благодаря настроенному триггеру
Сфера применения	Личные проекты, небольшие репозитории	Командные репозитории с частыми PR
Гибкость	Можно запустить с уточнением задачи	Проверяет всё подряд по стандартному шаблону

💡 Резюме в одном предложении: Автоматическое ревью включается через опцию Automatic reviews в настройках Codex. После этого каждый PR проверяется без ручного упоминания бота, что идеально подходит для командной разработки.

---

04 Настройка правил ревью: описываем стандарты в AGENTS.md

Вы можете спросить: какими критериями руководствуется ИИ при поиске ошибок? По умолчанию он использует базовые правила качества кода, но вы можете переопределить их с помощью файла AGENTS.md.

Как мы разбирали в 11-й статье, AGENTS.md — это свод инструкций для Codex в вашем репозитории. Чтобы задать правила проверки кода, создайте в этом файле специальный раздел Review guidelines.

Аналогия: чек-лист для сотрудника отдела контроля качества на заводе. Базовые вещи он знает сам (изделие должно быть целым, без трещин), но для конкретной партии деталей вы даете ему список особых требований (например, проверить соответствие ГОСТу для экспорта). Раздел Review guidelines в AGENTS.md — это и есть такой чек-лист специфических требований для вашего репозитория.

Пример структуры раздела в AGENTS.md в корне проекта:

## Review guidelines

- Don't log PII.
- Verify that authentication middleware wraps every route.

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

Здесь работает принцип локальности настроек, который мы обсуждали в теме про AGENTS.md:

Codex применяет инструкции из ближайшего к изменяемому файлу AGENTS.md. Вы можете размещать файлы AGENTS.md во вложенных папках для переопределения правил для конкретных модулей.

Это означает, что вам не нужно писать все правила в одном корневом файле. Для модуля платежей можно создать src/payment/AGENTS.md со своими строгими правилами проверки. Они вступят в силу автоматически, как только изменения коснутся файлов в этой папке.

Пример для src/payment/AGENTS.md:

## Review guidelines

- Суммы должны рассчитываться только с использованием типа Decimal, использование float запрещено.
- Каждый запрос на списание средств должен содержать ключ идемпотентности для предотвращения дублирования транзакций.

Так при ревью кода в папке src/payment Codex будет уделять повышенное внимание именно этим критическим моментам.

Дополнительная возможность: разовые уточнения при запуске. Если вы не хотите менять глобальный AGENTS.md, но хотите направить внимание ИИ на определенный аспект в конкретном PR, укажите это в комментарии:

@codex review for security regressions

Эта команда просит сфокусироваться на проверке безопасности. Также в правилах можно задавать веса ошибок. Например, если написать в AGENTS.md: Treat typos in docs as P1. (Считать опечатки в документации ошибками уровня P1), то Codex начнет выставлять опечаткам высокий приоритет и выносить их в комментарии.

💡 Резюме в одном предложении: Инструкции для проверки кода описываются в разделе Review guidelines файла AGENTS.md. Благодаря принципу локальности вы можете задавать специфические правила для папок (например, для платежных модулей), а также временно уточнять фокус проверки прямо в комментарии на GitHub.

---

05 Быстрое исправление ошибок: команда @codex fix

Допустим, Codex провел ревью и оставил замечание уровня P1 в Pull Request. Что дальше? Вы можете попросить его самостоятельно исправить найденную ошибку и отправить коммит в ветку PR.

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

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

@codex fix the P1 issue

Технически это работает следующим образом:

Codex использует контекст Pull Request для запуска задачи в облаке. При наличии соответствующих прав доступа он вносит исправления и отправляет коммит в текущую ветку.

Обратите внимание на важные детали:

1. Команда @codex fix создает полноценную облачную задачу. ИИ не просто генерирует текст в чате, а запускает изолированный контейнер (Codex cloud), считывает контекст ветки, вносит изменения и тестирует их в рамках своего рабочего цикла.

2. Коммит отправляется в ветку только при наличии прав. Это напрямую связано с концепцией безопасности, описанной в 15-й и 16-й статьях: ИИ может изменять файлы только в рамках тех прав, которые вы ему явно делегировали при авторизации интеграции. Если прав на запись нет, коммит не будет отправлен, а ИИ лишь покажет код исправления в комментарии.

Важно помнить разницу в синтаксисе команд:

• @codex review — запускает специализированный сценарий проверки кода (только анализ и комментарии, без изменения файлов).
• @codex <любой другой текст> (например, @codex fix the P1 issue или @codex add tests for this method) — запускает стандартную задачу в облаке с контекстом вашего PR для изменения файлов.

Слово review является зарезервированным для запуска проверки. Любые другие фразы Codex воспринимает как руководство к действию по редактированию кода.

Здесь стоит повторить наше главное правило безопасности: Codex может написать код и отправить его в ветку PR, но финальное решение о слиянии ветки с основной (main/master) всегда остается за человеком. Вы должны лично нажать кнопку Merge после проверки предложенного ИИ исправления.

💡 Резюме в одном предложении: Команда @codex fix the P1 issue запускает облачную задачу по исправлению ошибки с последующей отправкой коммита в ветку PR (при наличии прав на запись). При этом финальное слияние ветки в main всегда выполняет человек вручную.

Схема процесса интеграции ревью выглядит так:

Схема показывает полный цикл работы: создание или обновление PR запускает проверку (автоматически или вручную через @codex review). Codex считывает diff, сверяет его с правилами Review guidelines из ближайшего AGENTS.md и публикует замечания уровня P0/P1. По команде @codex fix ИИ исправляет код и отправляет коммит обратно в ветку, после чего цикл проверки может быть запущен повторно.

---

06 Локальная команда /review: самопроверка перед отправкой PR

Все предыдущие функции требовали работы на GitHub. Но есть более быстрый сценарий: проверить код локально на своем компьютере до отправки изменений в удаленный репозиторий.

Аналогия: проверка сочинения перед сдачей учителю. Вместо того чтобы отправлять сырой код и получать замечания в PR (от коллег или от @codex review), вы предварительно прогоняете файлы через локальный фильтр, исправляя очевидные ошибки. Это существенно экономит время команды.

Для запуска проверки введите в консоли сессии Codex:

/review

После этого появится меню с вариантами проверки. Codex запустит локального ревьюера, проанализирует diff и покажет структурированный список проблем по приоритетам. При этом ваш рабочий код никак не изменится (режим «только чтение»).

Доступны следующие варианты:

• Review against a base branch (Сравнить с базовой веткой): позволяет выбрать ветку для сравнения (например, main). Codex найдет точку ветвления, построит diff ваших изменений и покажет риски до создания Pull Request.
• Review uncommitted changes (Проверить незакоммиченные изменения): анализирует все текущие правки в рабочей области (включая stage и unstaged файлы).
• Review a commit (Проверить коммит): позволяет выбрать конкретный коммит по его хэшу (SHA) для детального разбора.
• Custom review instructions (Пользовательские инструкции): позволяет задать фокус проверки текстом (например, «проверить только доступность интерфейса»).

Полезный совет по настройке: по умолчанию /review использует текущую модель сессии. Чтобы назначить для ревью более мощную модель, пропишите параметр review_model в файле config.toml. Для повседневного написания кода можно использовать быструю и дешевую модель, а для вдумчивого анализа — подключить максимальную версию ИИ.

Мой рабочий процесс выглядит так:

1. Я вношу изменения в код, затем запускаю в терминале /review с опцией Review uncommitted changes.
2. Изучаю список замечаний и исправляю найденные баги на месте.
3. Только после очистки кода локально я делаю коммит и отправляю PR. На GitHub авторевью проходит быстро и без лишних замечаний.

💡 Резюме в одном предложении: Локальная команда /review — это инструмент самопроверки перед созданием PR. Вы запускаете анализ изменений (незакоммиченных правки, сравнение с веткой или коммит) в режиме «только чтение», исправляете ошибки локально, и только затем отправляете чистый код в репозиторий.

---

07 Настройка GitHub CLI: доступ к контексту PR в Desktop App

Если вы используете для работы Desktop App Codex (раздел 07) или плагины для IDE (раздел 09), вам понадобится установленный инструмент GitHub CLI (gh).

Аналогия: пропуск в архив для вашего личного ассистента. Без пропуска он знает о существовании папки с делом, но не может изучить историю переписки и комментарии ревьюеров. Авторизация через gh дает Codex доступ ко всем материалам дела непосредственно в интерфейсе приложения.

В документации сказано:

Установите GitHub CLI (gh) и авторизуйтесь с помощью gh auth login. Это позволит Codex загружать контекст PR, комментарии ревьюеров и список измененных файлов. Без авторизации gh информация о PR не будет отображаться в боковой панели и окне ревью.

Инструкции по установке для разных платформ:

# macOS (через Homebrew)
brew install gh

# Windows (через winget)
winget install --id GitHub.cli

# После установки на любой платформе выполните авторизацию:
gh auth login

ℹ️ Для Linux способ установки зависит от дистрибутива (apt / dnf / pacman). Используйте официальное руководство по установке GitHub CLI. После завершения обязательно выполните команду gh auth login.

После настройки вы сможете работать по следующему сценарию в едином интерфейсе:

1. Откройте панель ревью на ветке вашего Pull Request.
2. Просмотрите контекст PR, замечания коллег и измененные файлы.
3. Попросите Codex исправить код в соответствии с конкретными комментариями.
4. Проверьте сформированный diff изменений в панели приложения.
5. После проверки самостоятельно закоммитьте и отправьте изменения в репозиторий.

Обратите внимание на шаг 5: действие по отправке изменений (push) вы выполняете лично. ИИ лишь помогает подготовить код.

И не забывайте о безопасности (тема инъекций из 16-й статьи): комментарии к PR и сообщения в трекере — это внешние данные. Теоретически злоумышленник может оставить комментарий с вредоносной инструкцией для ИИ. Поэтому при обработке комментариев с помощью Codex всегда проверяйте предложенные им изменения перед коммитом, особенно если в комментариях содержатся требования выполнить сторонние команды.

💡 Резюме в одном предложении: Установка и авторизация GitHub CLI (gh) необходимы для того, чтобы Codex мог отображать контекст PR и комментарии коллег прямо в Desktop App. При этом отправка исправлений в ветку контролируется вами, что защищает проект от потенциальных вредоносных инструкций в комментариях.

---

08 Границы безопасности: слияние веток и force-push контролирует человек

Мы много говорили о том, что можно поручить Codex. Теперь обсудим действия, которые ни в коем случае нельзя передавать ИИ. Эти правила безопасности развивают идеи из статей 15 и 16 применительно к работе с Git.

Аналогия: юрист может составить идеальный договор, но подпись и печать на документе ставит только генеральный директор. Подготовка документов и согласование правок делегируются помощнику, но финальное действие, влекущее юридическую ответственность, совершается лично руководителем. В Git аналогичными действиями с высокой степенью ответственности являются слияние веток (merge) и принудительная отправка изменений с перезаписью истории (force-push).

Сравним уровни ответственности операций:

Операция	Возможность отката изменений	Кто выполняет
@codex review / Локально /review	Абсолютно безопасно (только чтение)	✅ Codex
@codex fix с отправкой в ветку PR	Безопасно (изменения локализованы в ветке)	✅ Codex (после вашей проверки)
Слияние PR в основную ветку (merge)	Сложно отменить, влияет на всю команду	⚠️ Только человек
Принудительный пуш (git push --force)	Критично (может стереть чужие коммиты)	❌ Исключительно человек

Два правила, которые я соблюдаю неукоснительно:

Правило 1: Финальный Merge выполняет только человек. Codex может проверять код, исправлять ошибки и коммитить в ветку PR — всё это легко отменить в случае неудачи. Но слияние изменений в ветку main затрагивает работу всей команды. Вы должны лично оценить готовность фичи и нажать кнопку слияния на GitHub.

Правило 2: Команда force-push закрыта для ИИ. Команда git push --force перезаписывает историю репозитория и может безвозвратно стереть коммиты ваших коллег. Любые подобные операции выполняются исключительно вручную с обязательной проверкой целевой ветки. Я видел случаи, когда автоматические скрипты принудительно пушили изменения и затирали дневную работу нескольких разработчиков. Не давайте ИИ доступ к таким опасным инструментам.

Помните философию безопасности Codex: по умолчанию утилита codex exec запускается в режиме read-only (только чтение) в песочнице. Для записи требуется явное разрешение разработчика (--sandbox workspace-write). Этот же принцип «минимизации привилегий» должен работать и в Git: все потенциально опасные и необратимые действия требуют явного подтверждения человеком.

💡 Резюме в одном предложении: Доверяйте Codex рутину (ревью, исправление кода в ветках), но операции слияния веток (merge) и перезаписи истории (force-push) выполняйте только вручную. Это соответствует концепции безопасности Codex с ограничением прав по умолчанию.

---

09 Карта процессов: Codex как ревьюер, вы как контролирующий орган

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

Схема жизненного цикла PR: перед отправкой кода вы проводите локальную самопроверку через /review (режим «только чтение»). На GitHub облачный Codex проводит аудит (по команде @codex review или автоматически) и оставляет замечания P0/P1. Вы просите исправить код через @codex fix, проверяете коммит, и в финале лично подтверждаете слияние (Merge) ветки в основное русло.

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

💡 Резюме в одном предложении: Разделяйте зоны ответственности: Codex собирает информацию, указывает на ошибки и предлагает патчи, а вы принимаете решение о слиянии изменений в основную ветку репозитория.

---

10 Практика: запускаем локальное ревью кода

Поскольку облачное ревью на GitHub требует настройки аккаунтов и доступов, мы проведем практический тест с помощью локальной команды /review, которая работает на любом компьютере и не изменяет файлы проекта.

Шаг 1: Создайте тестовый репозиторий Git в терминале

mkdir review-demo && cd review-demo
git init
printf 'def get_user(uid):\n    return db.query("SELECT * FROM users WHERE id=" + uid)\n' > app.py
git add app.py && git commit -m "feat: initial get_user"

Ожидаемый результат: Инициализирован пустой репозиторий, создан коммит. В файле app.py мы намеренно допустили уязвимость SQL-инъекции (объединение строк в SQL-запросе). Посмотрим, обнаружит ли ее Codex.

Шаг 2: Внесите изменения в файл (без коммита)

printf 'def get_user(uid):\n    return db.query("SELECT * FROM users WHERE id=" + uid)\n\ndef delete_user(uid):\n    db.execute("DELETE FROM users WHERE id=" + uid)\n' > app.py

Ожидаемый результат: В файле добавлена функция delete_user, содержащая аналогичную уязвимость. Изменения не добавлены в индекс и не закоммичены.

Шаг 3: Запустите сессию Codex и вызовите ревью

codex

В интерактивном режиме введите:

/review

Ожидаемый результат: На экране появится меню выбора типа ревью. Выберите с помощью стрелок пункт Review uncommitted changes (Проверить незакоммиченные изменения) и нажмите Enter.

Шаг 4: Анализ результатов

Ожидаемый результат: Codex проанализирует изменения в файле app.py и выведет список предупреждений в консоли. Он должен указать на критическую уязвимость SQL-инъекции в новой функции delete_user и предложить использовать параметризованные запросы. При этом сам файл app.py останется без изменений.

ℹ️ Точный текст предупреждений зависит от выбранной модели ИИ. Главное — убедиться, что Codex указал на проблему безопасности и не изменил исходный файл.

Шаг 5: Очистка окружения (необязательно)

Выйдите из сессии Codex и удалите тестовую папку:

cd .. && rm -rf review-demo

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

💡 Резюме в одном предложении: Практический тест состоит из пяти шагов: создание репозитория с уязвимым кодом → внесение изменений → запуск /review → анализ предупреждений ИИ → удаление тестовой папки. Проверка выполняется локально и безопасно для файлов.

---

11 Итоги

В этой главе мы подробно разобрали принципы интеграции Codex с Git и GitHub. Главное — понимать разницу между типами проверок и контролировать права на запись.

Краткий итог в таблице:

Задача	Решение в Codex	Важный нюанс
Ревью конкретного PR	@codex review в комментариях	Запуск в облаке, фильтрация замечаний до уровней P0/P1
Автоматизация проверок	Опция Automatic reviews	Проверяет каждый новый PR без дополнительных команд
Собственные правила ревью	Раздел Review guidelines в AGENTS.md	Поддержка принципа локальности (файлы правил во вложенных папках)
Исправление замечаний ИИ	Команда @codex fix	Требуются права на запись для отправки коммита в ветку
Быстрая проверка перед PR	Локальная команда /review	Выполняется на компьютере в режиме «только чтение»
Контекст PR в приложении	Установка GitHub CLI (gh)	Необходима авторизация через gh auth login
Контроль целостности	Ручной merge и запрет на авто-force-push	Финальное слияние веток всегда подтверждает разработчик

Теперь вы знаете, как:

• Различать облачные проверки на GitHub по команде @codex review и локальные проверки на компьютере через команду /review.
• Настраивать автопроверки PR, задавать специфические правила контроля качества в файлах AGENTS.md и просить ИИ исправить код коммитом в ветку.
• Использовать GitHub CLI для интеграции контекста PR с Desktop App Codex.
• Контролировать процесс слияния изменений, оставляя за собой финальное право одобрения коммитов.

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

---

В следующей статье 27 · Автоматизация и CI/CD мы пойдем еще дальше по пути автоматизации. Мы разберем, как запускать Codex непосредственно в конвейерах сборки (например, в GitHub Actions) с помощью команды codex exec, чтобы он автоматически реагировал на падение тестов и отправлял готовые исправления в репозиторий, пока вы отдыхаете.

---

Рекомендуемое чтение

• Инструкции и навыки (Skills): создание переиспользуемых сценариев для Codex
• Комплексный пример: создание TODO-приложения с нуля и коммит изменений
• Использование Codex в IDE (VS Code и др.)