Codex GitHub Action：在 CI 里触发自动化代码任务

适用场景

这篇手册适合想把 Codex 接入 GitHub Actions 的团队。它适合自动化重复检查、生成报告、辅助修复和创建 PR，但需要非常清楚的权限边界。

OpenAI 官方 GitHub Action 页面介绍了 Codex 的 GitHub Action 使用方式。具体 workflow 字段和版本应以当前官方页面为准。

步骤 1：选择低风险自动化场景

适合接入 CI 的任务：

• 检查文档 frontmatter。
• 总结 PR 改动。
• 运行只读安全扫描。
• 根据失败日志生成修复建议。
• 为小范围问题创建 PR。

不适合一开始自动化：

• 修改认证、支付、安全核心代码。
• 自动合并 PR。
• 访问生产数据。
• 使用高权限长期 token。

从只读报告开始最稳。

步骤 2：限制触发条件

不要让所有事件都触发 Codex。

建议先使用：

• 手动触发。
• 指定 label。
• 指定分支。
• 指定路径变化。
• 指定 PR 评论命令。

这样能避免 Codex 在无关 PR 或未知输入上运行。

步骤 3：控制 GitHub 权限和 secret

workflow 权限应最小化。

检查：

• contents 是否需要写权限。
• pull-requests 是否需要写权限。
• 是否需要读取 issue。
• secret 是否只给必要 job。
• 是否会把 secret 输出到日志。

不要使用比任务需要更高的 token。

步骤 4：把任务提示词写进 workflow

自动化任务不能依赖临场沟通，因此提示词要完整。

示例：

请检查本次 PR 是否修改了 content/manual 下的 MDX。
确认每篇文章包含 source 和 status。
只输出报告，不要修改文件。

如果允许修复，要写清：

只允许修改 content/manual 下缺失 frontmatter 的文章。
不要修改 slug、日期或正文含义。

步骤 5：结果必须可审查

Codex Action 的输出应让人能判断是否可信。

建议输出：

• 改动摘要。
• 文件列表。
• 验证命令。
• 未覆盖风险。
• 是否需要人工确认。

如果它创建 PR，PR 描述也应包含这些内容。

常见错误

不要默认给 Action 写权限。

不要把 secret 打印进日志。

不要让任意外部 PR 触发高权限 Codex 任务。

不要自动合并未经 review 的改动。

小结

Codex GitHub Action 适合把重复检查和辅助修复接入 CI。落地时先从只读开始，限制触发条件和权限，明确提示词，并让所有结果进入人工可审查流程。