Codex GitHub Action: как запустить агента в CI и не отдать лишние права
Codex можно запускать не только вручную. Его можно поставить в GitHub Actions: пусть смотрит pull request, готовит feedback, проверяет release, помогает с повторяемыми задачами и оставляет результат прямо в workflow.
Звучит удобно. Но CI — это место, где рядом лежат secrets, permissions, checkout кода, события pull request и автоматические решения. Если просто добавить агента в pipeline, можно получить не контроль качества, а новый канал риска.
Правильный вопрос не «как подключить action». Правильный вопрос: что Codex имеет право делать в CI, кто может это запустить, какой prompt он получает, где появляется output и где человек принимает решение.
Почему CI-агент опасен без рамки
Обычный code review в чате можно остановить в любой момент. GitHub Actions работает иначе: workflow стартует по событию, получает доступ к repository checkout, может читать контекст PR и иногда имеет право писать комментарии, артефакты или файлы.
Если prompt берётся из pull request body, commit message или issue text, туда может попасть недоверенный input. Если permissions слишком широкие, action получает больше, чем нужно для review. Если output сразу используется следующим шагом, ошибка агента может стать частью automation chain.
Поэтому Codex GitHub Action надо воспринимать как CI guard, а не как игрушечный review bot. Guard начинается с границ.
Что документация говорит о Codex GitHub Action
Официальная документация OpenAI описывает openai/codex-action@v1 как GitHub Action, который запускает Codex в CI/CD jobs, может применять patches или публиковать reviews из GitHub Actions workflow.
Action устанавливает Codex CLI, запускает Responses API proxy при наличии API key и выполняет codex exec под теми permissions, которые вы задаёте.
Документация называет типовые сценарии: feedback на pull requests или releases, Codex-driven quality checks в CI pipeline, повторяемые tasks вроде code review, release prep или migrations.
Перед запуском нужно сохранить OpenAI key как GitHub secret, checkout сделать до запуска action, выбрать runner Linux или macOS, а для Windows явно поставить safety-strategy: unsafe. Prompt можно дать inline через prompt или файлом через prompt-file, но источник должен быть один.
Важная часть документации — не пример YAML, а блок про privileges: safety-strategy, sandbox, trusted users, trusted bots, read-only ограничения, output capture и security checklist.
Когда запускать Codex из GitHub Actions
Codex в CI полезен, когда задача повторяемая и проверяемая.
Например: каждый PR получает независимый review на риск; release branch получает summary изменений; migration получает checklist; security-sensitive diff получает дополнительный вопрос; документация проверяется на consistency.
Плохой сценарий: «пусть Codex сам решает, что делать с каждым PR». В CI нужно не расширять свободу агента, а сужать задачу.
Хороший workflow отвечает на три вопроса:
Что дать Codex перед настройкой workflow
| Вопрос | Хороший ответ |
|---|---|
| Когда запускается | на pull_request, release или manual dispatch с понятными условиями |
| Что делает | review, checklist, summary, patch proposal или structured output |
| Что не делает | не мержит, не раскрывает secrets, не запускается от недоверенных trigger без контроля |
Если попросить Codex «сделай GitHub Action», он может написать рабочий YAML. Но рабочий YAML ещё не значит безопасный workflow.
Перед настройкой нужно дать рамку:
- событие запуска;
- кто может запускать workflow;
- нужен ли комментарий в PR или только artifact;
- может ли Codex менять файлы или только читать;
- где лежит prompt-file;
- какой sandbox нужен;
- какая
safety-strategyдопустима; - какие GitHub permissions нужны;
- что делать с
final-messageиoutput-file; - какие input fields из PR нужно считать недоверенными.
Тогда Codex проектирует не просто action, а CI-правило.
Как ограничить права и trigger
Документация прямо говорит: Codex имеет широкий доступ на GitHub-hosted runners, если его не ограничить.
Первый слой — GitHub permissions. Если Codex только читает код и пишет review через отдельный job, не надо давать больше прав, чем нужно. В примере документации основной job имеет contents: read, а posting feedback вынесен в отдельный job с issues: write и pull-requests: write.
Второй слой — safety-strategy. Значение по умолчанию drop-sudo удаляет sudo перед запуском Codex и защищает secrets in memory. Для некоторых случаев можно использовать unprivileged-user. Документация отдельно предупреждает: read-only не стоит считать единственной защитой secrets, потому что он ограничивает Codex, но не решает весь runner risk.
Третий слой — sandbox. Его нужно выбирать под задачу: read-only для review, workspace-write для патчей, danger-full-access только там, где действительно нужна такая свобода и есть доверенный контур.
Четвёртый слой — trigger trust. allow-users и allow-bots ограничивают, кто может запускать workflow. По умолчанию action рассчитан на trusted collaborators, но extra accounts нужно перечислять явно.
Как должен выглядеть результат
Результат хорошего Codex workflow должен быть видимым и отделённым от решения.
Action может дать final-message. Его можно сделать job output и затем опубликовать в PR. Можно сохранить output-file, загрузить artifact или использовать structured output через --output-schema в codex-args.
Но output не должен незаметно становиться merge decision. Хорошая схема такая:
| Output | Кто смотрит | Что решает |
|---|---|---|
| PR feedback | автор и reviewer | нужно ли править |
| Output file | maintainer | достаточно ли аргументов |
| Structured JSON | CI или dashboard | есть ли blocker/warning |
| Patch proposal | engineer | применять или нет |
Codex может быть сильным reviewer, но merge всё равно должен оставаться человеческим или явно описанным policy.
Как проверить настройку без кода
Непрограммисту не нужно читать весь YAML. Нужно проверить контур.
Первый вопрос: кто может запустить action? Если ответ «любой PR извне», нужен пересмотр.
Второй вопрос: где хранится API key? Он должен быть GitHub secret, не текстом в workflow и не в prompt.
Третий вопрос: что Codex может делать? Только читать, писать files, post comments, apply patches? Это должно быть явно.
Четвёртый вопрос: какой prompt источник? Если prompt собирается из PR body или issue text, нужен sanity layer против prompt injection.
Пятый вопрос: где результат? Если feedback исчезает в logs, его не примут. Если feedback автоматически блокирует merge без policy, это тоже риск.
Шестой вопрос: что происходит при ошибке? Документация перечисляет типовые сбои: два prompt источника, proxy без key, неожиданно сохранившийся sudo, permission errors, unauthorized trigger. У workflow должен быть понятный owner для таких случаев.
Где остаётся человеческое решение
Codex может прочитать diff, применить prompt, дать review, сохранить output и предложить patch. Но он не должен сам решать, что ваш repository теперь безопасен.
Человек решает, какие события trusted. Человек решает, может ли Codex менять файлы. Человек решает, какие warnings становятся blockers. Человек решает, какие bots разрешены. Человек решает, можно ли пускать action на PR из fork. Человек решает, что делать с подозрением на secret exposure.
CI-агент полезен не потому, что снимает ответственность. Он полезен потому, что делает проверку повторяемой и видимой.
Шаблон запроса
Можно дать Codex такой запрос:
Помоги спроектировать безопасный GitHub Actions workflow с openai/codex-action@v1.
Задача:
[PR review / release prep / migration check / documentation consistency / другое]
Trigger:
[pull_request / workflow_dispatch / release / другое]
Trust boundary:
- кто может запускать workflow;
- можно ли запускать на PR из fork;
- какие users/bots разрешены;
- какие поля PR считаем недоверенным input.
Prompt:
[prompt-file path или inline prompt, но один источник]
Permissions:
[что нужно: contents read, issues write, pull-requests write, другое]
Codex behavior:
- sandbox: [read-only / workspace-write / danger-full-access];
- safety-strategy: [drop-sudo / unprivileged-user / unsafe only if unavoidable];
- может ли Codex менять файлы;
- нужен ли output-file;
- нужен ли structured output через codex-args.
Security checklist:
- где хранится OPENAI_API_KEY;
- как защищаем prompt injection;
- почему later steps не получают неожиданные state changes;
- что делать при подозрении на exposure.
Результат:
1. дай workflow boundary plan;
2. предложи минимальные permissions;
3. предложи prompt-file структуру;
4. опиши output handling;
5. перечисли человеческие решения перед merge.Так Codex GitHub Action становится не магическим ботом в CI, а понятным контрольным слоем: запускается в нужный момент, получает ограниченную задачу, работает с нужными permissions и оставляет человеку решение.
