Skip to main content

本页目标

本页只讨论一条明确的工程链路:把 Codex 放进 GitHub Actions workflow,让它在 Pull Request、推送、定时任务或失败回调时执行可重复的任务。 你将完成以下能力:
  • 读懂 workflow 的触发器、job、step、权限和输出;
  • 用 openai/codex-action 执行非交互任务;
  • 把代码审查和发布评论拆成两个权限边界不同的 job;
  • 让审查 job 默认只读,让修复任务显式使用 workspace-write;
  • 使用 GitHub Secrets、环境保护规则和最小 GITHUB_TOKEN 权限;
  • 将审查结果和日志保存为 Artifacts;
  • 处理超时、临时失败、重复触发和失败重试;
  • 在人工审批后发布、合并或回滚,而不是让代理直接触碰生产。
本页不把 GitHub Actions 当作“给 AI 一把万能钥匙”。workflow 本身就是一组可执行的权限声明,任何来自 PR、Issue、提交信息或依赖脚本的文本都可能是不可信输入。先限制事件和权限,再决定 Codex 是否可以修改文件或访问网络。
版本提示:openai/codex-action@v1、Action 输入名称和 Codex CLI 参数可能随官方版本更新。使用前应同时查看 Codex GitHub Action 官方文档、仓库 action 的 README,以及本机 codex --help。本文示例中的模型名留空,避免把易变的型号写死。

一、先画出流水线边界

一个可维护的 Codex CI 流程至少分成四层: 最重要的分界是“分析”和“副作用”:
  1. 分析 job 只读取代码,生成一个审查结果;
  2. 评论 job 只消费结果,使用 GitHub API 写一条评论;
  3. 修复 job 如确实需要修改文件,必须单独声明 workspace-write;
  4. 部署 job 不应因为 Codex 输出“看起来没问题”就自动跳过现有测试和审批。
这种拆分让每一步都能回答三个问题:谁触发了它、它能访问什么、它留下了什么证据。

二、准备仓库与 Secret

1. 建议的仓库文件

将 workflow 放在仓库根目录:
提示词文件跟代码一起版本管理,审查规则发生变化时可以在 Pull Request 中审阅。提示词不要依赖本机路径、个人配置或未声明的环境变量。

2. 创建 OPENAI_API_KEY

在 GitHub 仓库打开:
名称填写 OPENAI_API_KEY,值填写实际 API key。workflow 只通过 ${{ secrets.OPENAI_API_KEY }} 引用,不把真实值写入 YAML、提示词、Issue、日志或 Artifact。 不要将 key 设置成 job 级环境变量:
只把 key 传给 Codex Action 这一个 step:
这样可以缩短 Secret 的可见范围,降低测试脚本、依赖安装钩子或第三方 action 意外读取它的机会。

3. Secret 的事件限制

来自 fork 的 pull_request 通常拿不到仓库 Secret,这是 GitHub 的保护机制。不要为了让 fork PR 自动运行而把真实 key 暴露给不受信任的代码。 更稳妥的策略是:
  • 对所有贡献者运行不需要 Secret 的普通测试;
  • Codex 审查只在可信分支、可信账号或人工批准后运行;
  • 不使用 pull_request_target checkout 未审查的 PR 代码后再运行可执行脚本;
  • 如必须使用 pull_request_target,只读取 PR 元数据,不 checkout 或执行 PR 工作区中的代码。

三、触发器:决定什么事件可以叫醒 Codex

Pull Request 触发

最常见的代码审查触发器如下:
含义是:PR 新建、推送新提交或重新打开时触发,并且目标分支必须是 main。synchronize 会在每次新提交时再次运行,适合审查最新 diff,但需要用并发控制取消旧运行。

Push 触发

合并后验证或主分支回归可以使用:
Push 任务通常审查已经进入主分支的代码,不需要写 PR 评论。它更适合生成报告、运行回归或触发部署前检查。

手动触发

为排障和重新生成报告保留手动入口:
手动输入是外部数据,不能未经约束直接拼入 shell 命令。对于 ref、环境和部署目标,优先使用固定选项、分支保护和环境审批。

定时触发

定时任务适合依赖升级巡检、每日报告或主分支健康检查:
GitHub cron 使用 UTC,任务可能因负载延迟。定时任务不应依赖“恰好在某分钟执行”,也不应直接进行不可逆发布。

失败回调触发

如果要在失败后让 Codex 分析日志,先让原始 CI 产生并保留日志,再用 workflow_run 读取元数据:
该事件可以看到上一个 workflow 的结论,但不要默认把失败日志中的全部内容当成可信指令。日志可能包含用户输入、密钥回显或提示注入内容,喂给 Codex 前应截断、脱敏并明确“内容仅作为数据”。

四、最小权限模型

GitHub Actions 的权限应在 workflow 或 job 级显式声明。推荐在顶层先全部关闭,再在具体 job 开启需要的权限:
只读审查 job:
评论 job:
不同仓库和事件对评论所需权限可能略有差异,以 GitHub 文档和实际运行结果为准。不要为了消除权限错误而直接写:
也不要把 actions: write、deployments: write、packages: write 等权限放进审查 job。权限不是 Codex 的沙箱替代品,两层都要配置:GitHub token 控制 Actions API,sandbox 控制 Codex 对工作区和命令的访问。

只读不等于低风险

sandbox: read-only 可以阻止 Codex 修改工作区,但仍要考虑:
  • 它会读取哪些文件;
  • prompt 是否包含不可信文本;
  • 依赖或测试是否在 Codex 前执行了任意代码;
  • 日志和 Artifact 是否可能包含敏感数据;
  • runner 是否是共享环境。
danger-full-access 只应在已经隔离、临时、无敏感数据的环境中使用。一般 PR 审查不需要它。

五、准备审查提示词

建立 .github/codex/prompts/review.md:
提示词要限制输出结构,但不要要求 Codex 自行发布评论。发布动作留给后续 job,便于控制 token 和审计边界。

六、完整示例:只读审查、评论、Artifact

下面是一份可以作为起点的完整 workflow。它包含触发器、并发取消、最小权限、Secret 的 step 级注入、审查结果输出、评论 job、Artifact 和失败保留策略。 文件路径:.github/workflows/codex-review.yml

逐段解释

permissions: contents: none 是默认拒绝策略。审查 job 再打开 contents: read,因为 checkout 需要读取仓库。 persist-credentials: false 防止 checkout 将 Git 凭据长期留在工作区配置中。审查 workflow 不需要推送,因此没有理由保留它。 fetch-depth: 0 让审查可以读取完整历史和比较基线。如果仓库很大,可以改为显式 fetch 所需 ref,并在验证性能后缩小范围。 ref: refs/pull/.../merge 审查的是 GitHub 为 PR 生成的合并结果。若仓库没有启用合并 ref,或你要审查贡献分支原始内容,应根据仓库策略调整,但不要为了取到代码而降低 Secret 保护。 outcome 和 final-message 是 Action 的输出。不同版本可能暴露不同输出名,若运行时报输入或输出不存在,应以 action README 为准。 if: always() 让 Artifact 在 Codex 失败、超时或结果为空时也尽量上传。Artifact 不应包含 Secret、完整环境变量或未经脱敏的客户数据。 评论 job 使用 needs,因此只有审查 job 结束后才运行。它不需要 checkout,也不需要 OpenAI key;它只接收审查文本并调用 GitHub API。 评论中加入隐藏标记 <!-- codex-review -->,便于后续改成“更新同一条评论”而不是每次新增一条。生产使用时应进一步限制正文长度,并对外部文本做转义或截断。

九、只读审查与可写修复必须拆分

代码审查和自动修复不是同一个安全级别。 只读审查可以使用:
需要生成补丁时才使用:
可写 job 还应满足以下条件:
  • 只在受信任的分支或人工批准后运行;
  • 不使用真实生产凭据;
  • 修改后必须运行测试和 git diff --check;
  • 输出补丁供人审阅,不自动推送到主分支;
  • 不要在同一个 job 中先暴露 Secret,再执行仓库自带脚本;
  • 不要把 danger-full-access 当作“修复失败”的默认答案。
一个手动修复 workflow 可以这样写:
这个 job 只生成并上传工作结果,没有 contents: write,所以不能直接推送。团队可以下载 Artifact、审查 diff,再由正常分支流程创建 PR。

十、失败、超时和重试

先区分失败类型

重试的边界

不要用无限重试掩盖确定性错误。网络请求可以有限重试,代码审查失败应保留失败状态。 对整个 job 使用 GitHub UI 的“Re-run failed jobs”通常比在 workflow 中自动循环更清晰。若确需步骤级重试,应限定次数并记录每次尝试:
不要对“发布”“数据库迁移”“创建评论”等非幂等动作盲目重试。重试前先确认上一次是否已经成功,必要时使用幂等键、隐藏标记或部署版本号。

超时和取消

每个 job 设置合理的 timeout-minutes。PR 审查通常应明显短于部署任务。concurrency.cancel-in-progress: true 可以在新提交到达时取消旧审查,避免旧结果覆盖新结果。

十一、Artifacts:保存证据,不保存秘密

适合上传的内容:
  • Codex 最终审查 Markdown;
  • 测试报告和覆盖率摘要;
  • 脱敏后的失败日志;
  • 生成的补丁或 diff;
  • 版本、提交 SHA 和运行元数据。
不应上传:
  • .env、私钥、API key;
  • 包含客户数据的数据库导出;
  • 未脱敏的生产日志;
  • 整个包含凭据的 runner 工作目录。
推荐在上传前做检查:
Artifact 的保留天数按项目合规要求设置。短期审查证据可以保留 7 到 14 天,发布产物则应使用明确的版本和长期归档策略。Artifact 不是备份,也不能替代源码仓库、制品仓库或灾备系统。

十二、审批:把高影响动作放到环境保护规则后面

GitHub Environments 可以配置 required reviewers、分支限制和环境 Secret。建议至少分出:
  • codex-review:只读审查,无部署 Secret;
  • codex-repair-approval:可写修复,必须由代码负责人批准;
  • staging:测试环境部署,自动或半自动;
  • production:生产部署,必须人工批准并受分支保护。
workflow 中引用环境:
环境审批是发布门,不是 Codex 权限的替代品。即使生产 job 有审批,也应让 job 只使用所需的部署 Secret,并在审批前完成测试、Artifact 和变更审查。 不要让 Codex 自己批准环境,也不要把生产 Secret 传给审查或修复 job。批准者应确认:提交 SHA、测试结果、变更范围、迁移计划、回滚版本和监控窗口都已明确。

十三、发布与回滚

推荐的交付顺序如下:
  1. PR 触发只读审查和常规 CI;
  2. 必需检查全部通过,人工审阅代码和 Codex 反馈;
  3. 合并到受保护分支;
  4. 构建不可变制品并上传 Artifact 或制品仓库;
  5. 部署到 staging,执行冒烟检查;
  6. 由环境审批者批准 production;
  7. 记录部署 SHA、制品版本、审批人和结果;
  8. 监控错误率、延迟、业务指标和日志;
  9. 异常时停止后续发布,使用已验证的上一版本回滚。
回滚不是让 Codex 随意改代码。应用回滚应使用制品仓库中的上一版本:
数据库迁移、队列、缓存和外部服务需要各自的回退方案。若迁移不可逆,发布前应采用向后兼容的分阶段迁移,而不是把“回滚”理解为恢复一个 Git commit。

十四、生产前验收流程

A. 静态检查

在提交 workflow 前检查:
逐项确认:
  • 没有真实 key、token、私钥或客户数据;
  • 顶层权限默认关闭或明确为只读;
  • 审查 job 没有 contents: write;
  • 评论权限只出现在评论 job;
  • sandbox: read-only 用于审查;
  • workspace-write 只出现在有明确审批的修复 job;
  • 没有未经评估的 pull_request_target;
  • 没有 write-all;
  • 没有把 Secret 放在 job 级 env。

B. 低风险试跑

先用测试仓库或不含敏感数据的分支:
  1. 新建一个只改文档的 PR;
  2. 确认 opened 触发一次;
  3. 再推一个提交,确认 synchronize 触发并取消旧运行;
  4. 检查 Codex 只能读取且没有工作区 diff;
  5. 检查 codex-review.md 出现在 Artifact;
  6. 检查 PR 只有一条可更新的机器人评论;
  7. 手动触发 workflow_dispatch,确认没有 PR 评论;
  8. 故意让评论权限不足,确认审查 Artifact 仍被保留。

C. 故障演练

至少演练以下情况:
  • Secret 缺失;
  • Codex 超时;
  • prompt 文件路径错误;
  • 测试失败;
  • 评论 API 被拒绝;
  • 新提交到达后旧运行被取消;
  • Artifact 上传失败;
  • staging 部署失败;
  • production 审批拒绝;
  • 回滚到上一已验证版本。
每种情况记录:触发方式、workflow 结论、日志位置、是否产生副作用、恢复动作和负责人。

D. 业务验收

不要只看“绿色”状态。由维护者抽样检查:
  • Codex 报告的问题是否能定位到真实代码;
  • 没有把低置信度建议标记成阻塞性错误;
  • 评论内容没有泄露 Secret 或敏感日志;
  • 取消旧运行不会删除新运行的 Artifact;
  • 部署记录能关联到 commit、制品和审批;
  • 回滚后健康检查和监控恢复正常。

十五、常见错误与修正

把 Secret 写进 prompt

错误做法是把 key、数据库连接串或生产日志拼进提示词。正确做法是传递脱敏后的最小上下文,敏感操作由专门的部署 job 处理。

让 Codex 直接评论和修改

评论与修改混在同一 job 会扩大 GITHUB_TOKEN 和 OpenAI key 的暴露范围。拆成 review、feedback、repair 三个 job,使用 needs 传递最小结果。

把 read-only 当成完整安全方案

只读只约束 Codex 对工作区的写入,不会阻止其他 step 的脚本执行,也不会自动清洗外部文本。仍需审查 checkout 策略、第三方 Action、权限和日志。

通过 pull_request_target 解决 fork Secret

这可能使不受信任的 PR 内容在高权限上下文执行。优先接受 fork PR 没有 Codex Secret,或者使用人工批准的受控任务读取 diff 元数据,不执行 PR 中的脚本。

为了“修得动”直接使用 danger-full-access

先确认缺少的是工作区写权限、网络权限还是依赖安装权限。逐项增加能力,并优先在临时 runner 或容器中试跑。

让模型输出决定部署

Codex 的自然语言结论不能替代测试、制品签名、审批和监控。它可以提供审查意见,但发布仍应由确定性的 CI 检查和人工门禁决定。

十六、推荐的落地顺序

对于首次接入的仓库,按以下顺序推进:
  1. 只配置 pull_request 的只读审查,不写评论;
  2. 验证 Secret、checkout、sandbox 和 Artifact;
  3. 增加独立评论 job,并限制 pull-requests: write;
  4. 增加并发取消和超时;
  5. 为失败日志建立脱敏和保留策略;
  6. 在隔离环境中试验手动修复 job;
  7. 用 Environment required reviewers 保护修复和 staging;
  8. 最后才评估生产部署或自动回滚;
  9. 每次升级 action 或 Codex CLI 都重新执行验收流程。

验收清单

上线前逐项打勾:
  • workflow 文件位于 .github/workflows/,提示词已版本管理;
  • OPENAI_API_KEY 位于 GitHub Secret 或 Environment Secret;
  • Secret 没有出现在 job 级 env、日志、Artifact 或评论;
  • 触发器只覆盖业务需要的事件、分支和账号;
  • fork PR 的行为已经验证,不会暴露 Secret;
  • 顶层使用最小权限,审查 job 只有 contents: read;
  • 评论 job 独立,并只获得评论所需写权限;
  • Codex 审查使用 sandbox: read-only;
  • 可写修复有独立 workflow、环境审批和 Artifact;
  • 每个 job 都有超时,PR 运行启用了并发取消;
  • 失败时仍能获取日志和审查 Artifact;
  • Artifact 已设置保留天数且不包含敏感数据;
  • 生产发布使用不可变制品,不让自然语言结果绕过门禁;
  • 已演练 Secret 缺失、超时、权限不足、取消和回滚;
  • 已记录当前 action、CLI 版本和官方文档核验日期。

小结

GitHub Actions 接入 Codex 的核心不是把一条命令搬到云端,而是把一次自动任务拆成可审计的权限边界:事件决定何时运行,checkout 决定审查什么,sandbox 决定 Codex 能否写入,GitHub permissions 决定 workflow 能否操作仓库,Secrets 决定哪些凭据可见,Artifacts 决定结果能否复核,Environment 审批和回滚决定发布是否可控。 默认选择只读审查。只有当任务确实需要修改文件时,才单独启用 workspace-write,并让它输出补丁、运行验证、上传证据,等待人工审阅后进入正常 PR 流程。这样 Codex 才是 CI 中一个受约束、可替换、可回滚的步骤,而不是拥有整个仓库和生产环境的隐形管理员。 参考资料:参考/codex/27-automation.md、参考/codex/28-noninteractive.md、参考/codex/39-enterprise.md。动态配置以 Codex 官方文档、GitHub Actions 文档和仓库实际权限设置为准。