Automation and CI/CD
📚 Навигация по серии: Предыдущая статья 〔26 Интеграция с Git и GitHub〕 научила вас использовать Codex для локального управления ветками, создания коммитов и отправки PR — всё это происходило, когда вы сидели перед компьютером, а ИИ помогал вам на месте. В этой статье мы настроим работу в режиме «без участия человека»: после настройки при открытии PR Codex автоматически проведет ревью, при падении CI предложит патч с исправлением, а каждый день по расписанию будет формировать отчет по вчерашним коммитам — и всё это без вашего непосредственного участия. В следующей статье 〔28 Неинтерактивный режим: codex exec〕 мы детально разберем ключевую команду, которая приводит всё это в действие.
Говорят, что главная ценность инструментов программирования на базе ИИ заключается в парном программировании и совместном обсуждении кода. Но честно говоря, это лишь половина правды.
Поработав с Codex более полугода, я пришел к выводу: настоящий рост производительности происходит тогда, когда вас нет на месте. При парном программировании вы должны присутствовать, контролировать процесс и одобрять каждый шаг ИИ. По сути, это схема «вы ведете, он помогает», и работа останавливается, как только вы отходите от компьютера. Но в разработке полно монотонных и регулярных задач: просмотреть новый PR, разобраться с упавшим посреди ночи CI, составить еженедельный отчет о проделанной работе. У этих задач есть общие черты: они рутинны, предсказуемы, и никто не хочет делать их вручную.
Именно для таких задач создана автоматизация. Подключив Codex к конвейеру CI и настроив запуск по расписанию, вы превращаете его из «помощника у монитора, за которым нужен глаз да глаз» в «ночного дежурного, патрулирующего ваш репозиторий». В этой статье мы разберем два направления: первое — интеграция Codex в GitHub Actions (со стороны CI/CD), второе — настройка регулярных фоновых задач в Desktop App (на вашей локальной машине). Вместе они обеспечат круглосуточную автоматическую поддержку вашего проекта.
Прочитав эту статью, вы получите:
- Понимание разницы между двумя путями автоматизации:
openai/codex-actionдля CI/CD и Automations для запуска фоновых задач по расписанию в Desktop App - Шаблон минимального работоспособного workflow для GitHub Actions с построчным разбором для ревью ваших PR
- Описание ключевых параметров
codex-action(prompt-file,sandbox,safety-strategy,final-message...), сверенное с официальной документацией - Правила безопасной настройки OpenAI key в GitHub Secrets и разбор критических уязвимостей
- Инструкцию по настройке Automations в Desktop App, просмотру результатов задач и выбору режима выполнения (Local или Worktree)
- Пошаговое практическое руководство по созданию и тестированию регулярного отчета о коммитах
⚠️ Параметры, имена команд и значения по умолчанию в этой статье основаны на официальной документации Codex (GitHub Action и Automations). Версии программного обеспечения и названия моделей могут меняться со временем, ориентируйтесь на актуальные данные в вашем интерфейсе.
01 Две дороги автоматизации: не путайте их в самом начале
Начнем с карты процессов. Автоматизация в Codex разделена на два направления, которые работают в разных средах и решают разные задачи:
- Направление 1: GitHub Actions (
openai/codex-action). Задачи выполняются на виртуальных машинах (runner) GitHub. Триггером служат события репозитория (создание PR, пуш кода, завершение сборки). Это часть процесса CI/CD (непрерывная интеграция и доставка). Сценарии ориентированы на командную работу: ревью PR, контроль качества кода, автоматическое исправление ошибок сборки. - Направление 2: Automations (автоматические задачи). Задачи выполняются на вашем компьютере с запущенным Desktop App Codex. Триггером служит время (настройка по расписанию или cron). Это персональный фоновый помощник. Сценарии ориентированы на индивидуальные задачи: подготовка ежедневного отчета, периодический аудит проекта, мониторинг долгих вычислений.
Почему важно разделять эти понятия? Самая частая ошибка новичков — попытка использовать неподходящий инструмент для задачи. Например, разработчик хочет настроить авторевью PR для всей команды, но прописывает Automation в своем Desktop App. В результате проверка перестает работать, как только он выключает компьютер. Или пытается настроить утреннее напоминание о локальной ветке через GitHub Actions, к которому облачный сервер просто не имеет доступа.
Аналогия: дежурный охранник vs личный дворецкий. GitHub Actions — это дежурный охранник офисного здания (вашего репозитория). Он живет на КПП (в облаке GitHub), следит за порядком в общих зонах и реагирует на события (кто-то пришел или сработала сигнализация). Он обслуживает всю компанию. Automations — это личный дворецкий в вашем доме (на локальном компьютере). Он выполняет ваши личные поручения по расписанию (например, «подать завтрак в 9 утра»). Если вы уехали и закрыли дом (выключили компьютер), он не работает. Охранник отвечает за общую безопасность и процессы компании, дворецкий — за ваш личный комфорт. Не просите охранника забрать вашу почту из домашнего ящика.
Сравнение двух подходов:
| Параметр | GitHub Actions (codex-action) | Automations (Desktop App) |
|---|---|---|
| Среда выполнения | Облачные раннеры GitHub | Локальный компьютер с запущенным Codex |
| Триггер запуска | События репозитория (push, Pull Request, CI) | Расписание / интервалы времени (cron) |
| Требуется ли ваше присутствие | Нет, выполняется полностью автономно | Компьютер должен быть включен, приложение запущено |
| Типичные задачи | Ревью PR, контроль качества, автоисправление багов | Ежедневные отчеты, регулярный аудит, мониторинг |
| Сфера применения | Интеграция в процессы команды (CI/CD) | Личная продуктивность, фоновые задачи |
Далее мы разберем GitHub Actions (разделы 02–05), затем перейдем к Automations (раздел 06) и закончим практическим примером (раздел 07).
💡 Резюме в одном предложении: Автоматизация делится на два типа: GitHub Actions (работает в облаке, реагирует на события репозитория, управляет процессами команды) и Automations (работает на вашем ПК по расписанию, решает ваши личные задачи). Выбирайте инструмент исходя из того, где и для кого должна выполняться задача.
02 Что такое GitHub Action: запуск codex exec в облачном конвейере
Разберем первое направление подробно. Экшен openai/codex-action — это готовый шаг для сборки GitHub Actions, который берет на себя установку Codex CLI, настройку прокси для API-ключей и запуск команды codex exec с заданными параметрами. Вам не нужно писать скрипты инициализации окружения самостоятельно.
Ключевое понятие здесь — codex exec. Это неинтерактивный режим работы (non-interactive mode) Codex CLI. В этом режиме утилита принимает текстовую инструкцию (prompt), выполняет ее и завершает работу, выводя результат. На нем построена вся облачная автоматизация. (Подробнее саму команду codex exec мы разберем в 28-й статье).
Из описания экшена:
Используйте Codex GitHub Action (
openai/codex-action@v1) для выполнения задач Codex, применения патчей или публикации результатов ревью в процессах CI/CD. Экшен устанавливает Codex CLI, запускает прокси-сервер для Responses API при передаче API-ключа и выполняет командуcodex execс указанными правами доступа.
Аналогия: чемоданчик с инструментами для командировок. Вы можете приехать на объект (облачный раннер) и начать собирать рабочее место с нуля: скачивать дистрибутивы, настраивать авторизацию, копировать ключи. А можете взять готовый сертифицированный чемоданчик от производителя (codex-action), в котором уже лежит настроенный инструмент, готовый к работе по вашей инструкции. Ценность этого решения — в безопасности и надежности развертывания окружения на чужой виртуальной машине, особенно в части работы с ключами доступа (подробнее в разделе 05).
Разработчики выделяют три основных сценария использования экшена:
- Автоматическая отправка замечаний и отчетов в ветки Pull Request или релизы.
- Блокировка сборки при непрохождении проверок качества кода от Codex (качество кода как ворота CI).
- Выполнение регулярных рутинных задач (проверка безопасности, подготовка к релизу, миграции файлов) по шаблону.
Важное отличие от интерактивного режима ревью: этот процесс не запускается вашим комментарием в чате. Это стандартный инструмент GitHub Actions, который описывается в файлах конфигурации workflow и реагирует на системные события.
💡 Резюме в одном предложении: Экшен
openai/codex-action— это готовый контейнер для CI, который устанавливает CLI, настраивает прокси-сервер для ключей и запускает командуcodex execна основе системных триггеров (push, PR и т. д.).
Общая схема процесса автоматизации через CI выглядит так:
Любое из событий репозитория (push, Pull Request, cron-расписание) запускает workflow. Виртуальная машина выполняет команду codex exec с заданным набором прав и возвращает результат в виде комментариев к PR, коммитов с исправлениями или отчетов.
03 Шаблон workflow: разбираем YAML-файл для ревью PR
Перейдем к практике. Ниже представлен рабочий шаблон workflow для GitHub Actions, который автоматически проверяет код при создании PR и публикует замечания в комментариях.
Аналогия: регламент работы двух дежурных на проходной. Первый дежурный (шаг codex) — это инспектор. Он проверяет документы, сверяет их с инструкцией (prompt-file) и записывает замечания в блокнот (выходной параметр final-message). Второй дежурный (шаг post_feedback) — это курьер. Он ждет, пока инспектор закончит работу, берет блокнот с записями и передает их в отдел кадров (публикует в комментарии к PR). Разделение ролей обусловлено безопасностью: у инспектора минимальные права доступа (только чтение), а курьер имеет права на публикацию сообщений.
Пример конфигурационного файла:
# Путь к файлу: .github/workflows/codex-review.yml
name: Codex pull request review
on:
pull_request:
types: [opened, synchronize, reopened]
jobs:
codex:
runs-on: ubuntu-latest
permissions:
contents: read
outputs:
final_message: ${{ steps.run_codex.outputs.final-message }}
steps:
- uses: actions/checkout@v5
with:
ref: refs/pull/${{ github.event.pull_request.number }}/merge
persist-credentials: false
- name: Run Codex
id: run_codex
uses: openai/codex-action@v1
with:
openai-api-key: ${{ secrets.OPENAI_API_KEY }}
prompt-file: .github/codex/prompts/review.md
output-file: codex-output.md
post_feedback:
runs-on: ubuntu-latest
needs: codex
if: needs.codex.outputs.final_message != ''
permissions:
issues: write
pull-requests: write
steps:
- name: Post Codex feedback
uses: actions/github-script@v7
with:
github-token: ${{ github.token }}
script: |
await github.rest.issues.createComment({
owner: context.repo.owner,
repo: context.repo.repo,
issue_number: context.payload.pull_request.number,
body: process.env.CODEX_FINAL_MESSAGE,
});
env:
CODEX_FINAL_MESSAGE: ${{ needs.codex.outputs.final_message }}Разберем структуру файла по блокам:
Блок 1: on (триггеры запуска). Настройка pull_request со статусами opened (создание PR), synchronize (новые коммиты в PR), reopened (повторное открытие). Сборка запускается при любом из этих событий.
Блок 2: checkout (получение кода). Инструкции требуют обязательного скачивания кода репозитория перед запуском шага Codex. Параметр persist-credentials: false запрещает сохранять учетные данные Git на раннере, а ref: .../merge скачивает код в состоянии после слияния с целевой веткой, что необходимо для корректного ревью.
Блок 3: Run Codex (непосредственно шаг Codex).
- uses: openai/codex-action@v1
with:
openai-api-key: ${{ secrets.OPENAI_API_KEY }}
prompt-file: .github/codex/prompts/review.md
output-file: codex-output.mdМы передаем три параметра: openai-api-key (ссылка на секрет), prompt-file (путь к файлу инструкции ревью в репозитории) и output-file (имя файла для сохранения результатов на диск раннера).
Блок 4: outputs и post_feedback (публикация результатов). Работа codex передает результат через выходной параметр steps.run_codex.outputs.final-message. Вторая работа post_feedback запускается только после успешного завершения первой (needs: codex), проверяет наличие текста ошибки (if: ... != '') и с помощью стандартного скрипта GitHub API оставляет комментарий в ветке PR.
Выходной параметр final-message — это основной результат работы экшена, содержащий итоговый текстовый отчет Codex. Его можно использовать для отправки уведомлений в мессенджеры, сохранения в артефакты или анализа в последующих шагах сборки.
Схема движения данных в этом workflow:
Событие PR запускает workflow → код скачивается на раннер → запускается codex-action с файлом правил → отчет передается в параметр final-message → скрипт публикует отчет в комментарии к PR.
Для передачи инструкций можно использовать либо файл (prompt-file), либо строку текста (prompt). Указывайте только один из этих параметров, одновременное использование приведет к ошибке сборки.
💡 Резюме в одном предложении: Шаблон workflow описывает цепочку: событие PR → получение кода → запуск
codex-actionпо правилам из файла → запись отчета вfinal-message→ публикация комментария скриптом. Шаг ИИ изолирован от процесса записи комментариев из соображений безопасности.
04 Настройка параметров экшена: управление поведением ИИ
Параметры экшена codex-action в YAML-файле транслируются в опции запуска локальной утилиты codex exec. Вы можете тонко настраивать поведение ИИ с помощью следующих ключей:
| Параметр в YAML | Назначение | Примечание |
|---|---|---|
prompt / prompt-file | Задача для ИИ (текстовая строка или путь к файлу) | Должен быть указан только один из параметров |
sandbox | Режим изоляции песочницы | Варианты: workspace-write, read-only, danger-full-access |
model / effort | Выбор модели и уровня детализации | По умолчанию используются рекомендуемые настройки, не пишите жесткие имена моделей |
output-file | Путь для сохранения отчета на диск | Позволяет использовать отчет на следующих шагах сборки |
codex-args | Дополнительные аргументы CLI | Передаются в виде массива JSON (["--ephemeral"]) или строки (--profile ci) |
codex-version | Фиксация версии CLI | Если не указан, используется последняя стабильная версия |
codex-home | Путь к домашней директории Codex | Используется для сохранения общих настроек и MCP между шагами |
Важные особенности настройки параметров:
Настройка уровня изоляции sandbox. В 15-й статье мы подробно разбирали три уровня ограничений песочницы: read-only (только чтение), workspace-write (запись в рабочую папку) и danger-full-access (полный доступ). Для процессов автоматизации действует правило: предоставляйте ИИ минимально необходимые права. Если задача Codex — только проверить код, используйте режим по умолчанию read-only. Если ИИ должен внести исправления в файлы проекта, явно укажите sandbox: workspace-write.
Внимание: по умолчанию команда codex exec запускается в режиме read-only! Если вы не укажете этот параметр, ИИ не сможет перезаписать файлы на диске раннера при попытке исправить баги.
Передача параметров через codex-args. Этот ключ позволяет передавать любые аргументы командной строки в CLI. Например, с помощью аргумента --output-schema можно потребовать от Codex вернуть результат строго в формате JSON, соответствующем заданной схеме, чтобы разобрать его на последующих этапах сборки.
Параметры model и effort. Производитель рекомендует оставлять эти поля пустыми. Codex сам выберет наиболее подходящую и экономичную модель для решения задачи. Это защитит ваш workflow от сбоев при выводе устаревших моделей из эксплуатации.
Сохранение результатов на диск (output-file) позволяет настроить их архивацию с помощью стандартного экшена actions/upload-artifact. Это полезно для ведения логов аудита безопасности проекта.
Экшен автоматически разворачивает Responses API прокси для защиты вашего API-ключа от утечки через процессы виртуальной машины.
💡 Резюме в одном предложении: Параметры экшена соответствуют ключам CLI
codex exec. Помните, что по умолчанию включен режимread-only, и для изменения файлов нужно явно прописатьsandbox: workspace-write. Параметры моделей лучше оставлять пустыми.
05 Безопасность API-ключей и прав доступа в CI
Использование секретов в автоматических сценариях требует строгого соблюдения правил безопасности. Утечка API-ключа может привести к финансовым потерям.
Правило 1: Использование GitHub Secrets для хранения ключей
В документации четко сказано:
Сохраняйте ваш OpenAI API-ключ в секретах репозитория GitHub (например, под именем
OPENAI_API_KEY) и ссылайтесь на него в workflow.
Никогда не пишите ключ в коде YAML-файла.
Аналогия: хранение ценностей в сейфе банка. Секреты GitHub — это защищенная ячейка. Вы кладете туда ключ один раз, после чего система скрывает его значение. В YAML-файле вы пишете не сам ключ, а запрос на его получение из ячейки (${{ secrets.OPENAI_API_KEY }}). Даже при публикации логов сборки GitHub автоматически маскирует эти значения звездками.
Для добавления ключа перейдите в меню репозитория Settings → Secrets and variables → Actions, нажмите New repository secret, укажите имя OPENAI_API_KEY и вставьте значение ключа.
Правило 2: Запрет на использование ключа на уровне окружения (job env)
Это неочевидная уязвимость, о которой авторы Codex предупреждают отдельно:
Не объявляйте переменные
OPENAI_API_KEYилиCODEX_API_KEYна уровне работы (job env) в workflow, если в рамках этой работы запускаются внешние скрипты или тесты. Любые скрипты сборки, тесты и хуки зависимостей могут прочитать эти переменные из окружения.
Если вы укажете ключ в глобальном блоке env работы, то любой скрипт, запускаемый в рамках тестов (например, вредоносный код в составе пакета npm), сможет прочитать его значение и отправить злоумышленникам. Передавайте ключ строго внутрь шага экшена через параметр with, как показано в нашем шаблоне.
Правило 3: Ограничение прав выполнения на раннере
По умолчанию виртуальные машины GitHub предоставляют процессам широкие полномочия. Настройте ограничения:
| Механизм защиты | Описание | Значение |
|---|---|---|
safety-strategy | Отзыв прав sudo перед запуском Codex для защиты памяти процесса | По умолчанию drop-sudo. На Windows-раннерах требует значения unsafe |
unprivileged-user | Запуск Codex от имени выделенного пользователя с низкими правами | Требует предварительной настройки учетной записи в системе |
read-only | Ограничение доступа к сети и файловой системе на уровне экшена | Не отменяет системные привилегии процесса |
sandbox | Внутренняя изоляция контейнера Codex | Настраивается через параметр sandbox в YAML |
allow-users / allow-bots | Список учетных записей, которым разрешено запускать workflow | По умолчанию запуск разрешен только пользователям с правами на запись |
Ключевые моменты защиты:
Параметр safety-strategy со значением drop-sudo отзывает права суперпользователя у процесса Codex, предотвращая чтение дампов памяти раннера. На Windows-системах эта функция не поддерживается, поэтому там приходится указывать unsafe, что снижает безопасность в многопользовательских средах.
Параметры allow-users и allow-bots защищают публичные репозитории от несанкционированного запуска сборки сторонними разработчиками через форки проекта.
Краткий чек-лист безопасности:
| ❌ Опасные практики | ✅ Рекомендуемые решения |
|---|---|
| Публикация открытого ключа в YAML-файле | Хранение ключа в GitHub Secrets |
Объявление ключа в глобальном блоке env: работы | Передача ключа строго в секцию with: экшена |
Отключение safety-strategy на общих раннерах | Использование режима drop-sudo по умолчанию |
| Запуск сборки на любых коммитах из внешних форков | Ограничение круга лиц через allow-users |
| Использование сырых текстов PR в промптах без очистки | Предварительная фильтрация входных данных на наличие инъекций |
Помните о риске prompt-инъекций (описанных в 16-й статье). Злоумышленник может отправить Pull Request с вредоносным текстом в описании, надеясь перехватить управление логикой ИИ на этапе сборки. Всегда очищайте внешние тексты перед их передачей в Codex. Рекомендуется запускать шаг Codex последним в цепочке сборки, чтобы возможные сбои не повлияли на предыдущие этапы валидации кода.
💡 Резюме в одном предложении: Безопасность в CI строится на трех правилах: шифруйте ключи в Secrets, не объявляйте их в глобальном окружении job env и ограничивайте права процесса через
safety-strategy: drop-sudoи параметры песочницы.
06 Настройка Automations: регулярные фоновые задачи в Desktop App
Второе направление автоматизации — фоновые задачи в Desktop App. Они запускаются на вашем компьютере по расписанию и помогают решать повседневные задачи разработчика.
Принцип работы Automations:
Задачи выполняются в фоновом режиме по расписанию. Результаты анализа Codex отправляет во встроенный почтовый ящик (Inbox / Triage). Если в ходе выполнения не обнаружено важных событий, задача автоматически архивируется, не отвлекая пользователя.
Аналогия: робот-пылесос с базой самоочистки. Он запускается по таймеру ночью, убирает квартиру и возвращается на базу. Если все чисто, он не присылает уведомлений. Но если он застрял или нашел ценную вещь, он подает сигнал на телефон. Так же работает и Automation: ИИ регулярно проверяет проект в фоне и беспокоит вас только при обнаружении проблем.
Примеры использования фоновых задач
- Подготовка утреннего отчета о коммитах: ИИ анализирует изменения в ветке
mainза последние 24 часа, группирует их по темам и оставляет отчет. Утром вы сразу видите картину изменений. - Регулярный аудит кода на наличие багов: ИИ раз в сутки сканирует новые коммиты на соответствие правилам безопасности и предлагает исправления.
- Мониторинг долгих процессов: ИИ периодически проверяет статус выполнения тестов или сборки на удаленном сервере и присылает отчет о завершении.
Типы автоматизации: Standalone vs Thread Automation
В Desktop App доступно два типа фоновых задач:
| Параметр | Standalone Automation (независимая) | Thread Automation (в потоке) |
|---|---|---|
| Контекст запуска | Каждый запуск создает новую чистую сессию | Выполняется в рамках одного существующего диалога |
| Сохранение истории | История предыдущих запусков не учитывается | Доступна вся переписка и контекст предыдущих шагов |
| Куда выводится результат | Новое сообщение в папке Triage (Inbox) | Добавляется новым сообщением в ветку текущего потока |
| Сфера применения | Регулярные изолированные отчеты (например, ежедневный дайджест) | Мониторинг процессов с накоплением данных (например, отслеживание сборки) |
При настройке Thread Automation промпт должен быть написан с расчетом на многократный запуск. Укажите ИИ, как реагировать на отсутствие изменений и в какой момент прекращать мониторинг.
Выбор рабочей директории: Local vs Worktrees
Для проектов под управлением Git вы можете выбрать, где выполнять фоновые задачи:
- Режим Worktrees (рекомендуется): Для задачи создается временная изолированная папка
worktree. Изменения кода в фоновом режиме не мешают вашей текущей работе в основном каталоге. - Режим Local: Задача выполняется прямо в вашей рабочей папке. Будьте осторожны: фоновый процесс может перезаписать файлы, которые вы редактируете в данный момент.
- Для обычных папок (без Git) задача всегда выполняется локально.
Поскольку частый запуск задач в режиме Worktree создает временные папки на диске, не забывайте периодически архивировать завершенные сессии в приложении для очистки дискового пространства.
Создание задач и права доступа
Самый простой способ создать автоматизацию — попросить об этом Codex в обычном чате. Опишите задачу, укажите расписание (поддерживается синтаксис cron) и выберите режим изоляции. Codex сам создаст нужный сценарий. Вы также можете управлять задачами вручную через вкладку Automations в боковой панели Desktop App.
Особенности выполнения задач:
1. Фоновые задачи используют глобальные настройки песочницы. Если на компьютере включен режим read-only, задачи по автоисправлению кода не смогут изменить файлы. Для работы таких сценариев требуется уровень доступа workspace-write.
2. Задачи запускаются с политикой approval_policy = "never". Фоновый процесс выполняется без вывода окон подтверждения команд. Защиту системы в этом случае обеспечивает правильно настроенная песочница и правила AGENTS.md. Если администратор запретил выполнение без подтверждения на уровне политик компании, автоматизация вернется к стандартному интерактивному режиму с запросом разрешений.
Перед запуском задачи по расписанию обязательно протестируйте промпт вручную в обычном диалоге, чтобы убедиться в правильности логики работы ИИ.
⚠️ Важное условие: Фоновые задачи в Desktop App выполняются только тогда, когда ваш компьютер включен, приложение запущено, а папка проекта доступна на диске. В отличие от GitHub Actions, этот метод привязан к вашей локальной рабочей станции.
💡 Резюме в одном предложении: Automations в Desktop App выполняют фоновые задачи по расписанию на вашем ПК. Рекомендуется запускать их в режиме Worktree для изоляции изменений и использовать ручное тестирование промптов перед постановкой на расписание.
07 Практика: настраиваем регулярный отчет о коммитах
Пройдем шаги настройки фонового отчета о коммитах в Desktop App Codex, чтобы увидеть автоматизацию в действии. Этот пример безопасен и работает локально.
Убедитесь, что у вас запущено Desktop App Codex и открыта папка любого Git-репозитория с историей коммитов.
Шаг 1: Тестирование промпта в чате
Откройте чат с проектом и отправьте сообщение:
Покажи коммиты в этом репозитории за последние 24 часа и составь краткий отчет на русском языке:
- Сгруппируй изменения по темам (не пиши хэши коммитов)
- Опиши суть изменений каждой группы одной фразой
- Если коммитов не было, выведи сообщение: «За последние 24 часа изменений не обнаружено»Ожидаемый результат: Codex прочитает историю Git и выведет структурированный отчет. Мы убедились, что формулировка промпта понятна ИИ и результат нас устраивает.
Шаг 2: Создание автоматической задачи
В этом же диалоге напишите команду:
Создай на основе этого промпта ежедневную независимую задачу (Automation) с запуском в 9:00.
Выполняй её в режиме worktree. Если изменений в коде нет, автоматически архивируй задачу.Ожидаемый результат: Codex подтвердит создание задачи, настроит триггер запуска на 9:00 и укажет режим изоляции Worktree.
Вы также можете настроить более сложное расписание с помощью cron-выражений (например, 0 9 * * 1-5 для запуска по будням) в окне настройки задачи.
Шаг 3: Проверка в списке задач
Перейдите во вкладку Automations в боковой панели приложения.
Ожидаемый результат: В списке должна появиться новая запись с описанием вашей задачи, расписанием запуска и пометкой типа (Standalone).
Шаг 4: Ручной запуск для проверки
Нажмите кнопку запуска (Run) рядом с созданной задачей в панели управления, не дожидаясь наступления утра.
Ожидаемый результат:
- Начнется процесс выполнения задачи в фоновом режиме.
- После завершения, если в репозитории были коммиты за сутки, в папке Triage (Inbox) появится новое сообщение с отчетом. Если коммитов не было, задача автоматически завершится и уйдет в архив без отправки уведомлений.
- Появление отчета в Inbox подтверждает правильность настройки всей цепочки.
Шаг 5: Анализ и очистка
Прочитайте полученный отчет. При необходимости скорректируйте формулировку промпта в настройках задачи. Если задача больше не нужна, удалите ее из списка Automations, чтобы освободить место на диске от временных папок.
Этот простой пример показывает, как переложить рутину по сбору информации о проекте на плечи ИИ.
💡 Резюме в одном предложении: Практическая настройка состоит из шагов: ручная проверка промпта → отправка команды на создание задачи в чат → проверка статуса в панели Automations → тестовый ручной запуск → анализ результатов в папке Inbox.
08 Итоги
В этой главе мы разобрали инструменты автоматизации Codex, позволяющие настроить фоновую работу ИИ без вашего непосредственного участия.
Основные выводы представлены в таблице:
| Задача | Инструмент | Ключевой момент |
|---|---|---|
| Интеграция в командные процессы | GitHub Actions (openai/codex-action) | Запуск в облаке по триггерам событий репозитория |
| Написание конфигурации CI | YAML-файл в папке .github/workflows/ | Двухэтапная схема: проверка ИИ с правами чтения → публикация скриптом с правами записи |
| Параметры запуска в CI | Аргументы YAML-файла экшена | Песочница по умолчанию закрыта на запись (read-only), для коммитов требуется workspace-write |
| Защита учетных данных в CI | GitHub Secrets | Передавайте ключ строго внутрь шага экшена, не используйте глобальные переменные job env |
| Фоновые задачи на локальном ПК | Раздел Automations в Desktop App | Запуск по расписанию; результаты направляются в папку Inbox |
| Изоляция фоновых задач на ПК | Режим Worktree | Защищает текущие рабочие файлы разработчика от случайной перезаписи ИИ |
Теперь вы умеете:
- Различать сферы применения облачной автоматизации процессов репозитория (GitHub Actions) и локальной автоматизации рутины разработчика (Automations).
- Настраивать безопасные workflow-файлы для автоматического код-ревью PR на базе экшена
openai/codex-action. - Управлять уровнями доступа песочницы в облаке и настраивать защиту ключей от кражи через переменные окружения.
- Создавать, тестировать и запускать фоновые задачи по расписанию в Desktop App с изоляцией файлов в Worktree.
Настройка автоматических процессов позволяет сэкономить время команды на код-ревью и сбор рутинной информации.
В следующей статье 28 · Неинтерактивный режим: codex exec мы заглянем под капот инструментов автоматизации. Мы детально разберем работу команды codex exec, которая является основой для запуска Codex в скриптах, узнаем разницу в обработке потоков stdout/stderr и научимся встраивать ИИ в собственные bash-скрипты.