用 GitHub Action 跑 Codex
基于官方 Codex GitHub Action 教程，面向新手讲清 openai/codex-action@v1 适合什么 CI/CD 任务、权限怎么给、结果怎么验收。
Codex GitHub Action，也就是 openai/codex-action@v1，是在 GitHub Actions 里运行 Codex 的官方入口。官方说明它会安装 Codex CLI；当你提供 API key 时启动 Responses API proxy；然后按你指定的权限运行 codex exec。
所以它不是另一个独立 Agent 产品。它本质上是把 codex exec 包进 GitHub workflow，适合 PR review、release prep、迁移检查、质量 gate 和自动修复提案。
先理解：什么时候用 Action
适合用 Action：
- 你想在 PR 上自动生成 Codex review。
- 你想把 Codex 检查放进 CI pipeline。
- 你不想自己安装和管理 Codex CLI。
- 你需要把最终 Codex message 传给后续 GitHub steps。
- 任务已经可以用
codex exec清楚描述。
不适合用 Action：
- 你还没写清 prompt。
- 你不知道应该给 read-only 还是 workspace-write。
- 你打算让来自任意 fork 的输入直接驱动 Codex。
- 你没有准备好保护 OpenAI key 和 GitHub token。
- 你希望 Codex 无限制自动改主分支。
新手先做只读 PR review，再做自动修复 PR。不要第一版就让它直接推送到主分支。
怎么判断 prompt 放哪里
如果任务很短，可以用 inline prompt。
如果任务会长期维护，放进 .github/codex/prompts/ 之类的 prompt file。这样更容易 review、版本管理和复用。
官方要求 prompt 和 prompt-file 二选一。两个都设置会报错。
新手推荐 prompt file，因为它能被团队审查。CI 里的 prompt 也是代码资产，不应该随手写在 workflow 里没人维护。
权限怎么给
GitHub job permissions 先收紧。只读 review 通常只需要 contents read；要回写 PR comment 才给 pull-requests write。
Codex sandbox 也先收紧。只读审查用 read-only；需要生成 patch 才用 workspace-write；danger-full-access 不应该作为默认。
官方 Action 默认 safety-strategy 是 drop-sudo，会在运行 Codex 前移除 sudo，降低 runner 上 secrets 暴露面。Windows 需要 unsafe，但这不是新手默认路线。
如果要更严格，可以让 Codex 在 unprivileged user 下运行，但要提前处理 repository checkout 的读写权限。
触发条件要保守
不要让任何人都能触发带 secret 的 Codex job。官方 Action 支持 allow-users 和 allow-bots 这类控制，默认也会限制触发者。
对来自 PR、issue、commit message 的内容要当成不可信输入。把它们交给 Codex 前，要意识到 prompt injection 风险。
如果工作流会使用 OPENAI_API_KEY 或 GitHub token，尤其要小心 fork PR 场景。
输出怎么用
Action 会提供最终 Codex message。你可以把它作为 job output，交给后续 step 发 PR comment、上传 artifact 或写入报告。
如果只需要人读，保存 final message 就够。
如果要程序解析，应该让底层 codex exec 使用结构化输出，例如通过额外参数传 schema。
新手不要一开始就做“自动应用 + 自动提交 + 自动评论”。先保存输出、人工看，再逐步自动化。
新手常见坑
- 把 Action 当成能替代 CI 的质量系统：Codex 建议要配合真实测试。
- prompt 太宽：让 Codex “审查所有问题”容易输出泛泛意见；应该限定检查维度。
- 权限太大：workflow、GitHub token、Codex sandbox 都要分别收紧。
- secret 暴露：不要在日志、artifact 或 prompt 输出里泄露 OpenAI key、auth 文件和私有配置。
- 同时设置
prompt和prompt-file。 - 没有 checkout 代码：Codex 读不到 repository contents。
- 让不可信用户触发带写权限的 job。
一个稳妥落地顺序
第一版：只读 PR review。Codex 只输出风险点，不改文件。
第二版：把结果发成 PR comment。GitHub token 只给评论所需权限。
第三版：在受控分支上生成 patch，并复跑测试。
第四版：只有测试通过时，才开自动修复 PR，仍然由人 review。
这个顺序能让团队先建立信任，再扩大自动化范围。
怎么验收
你能证明 Action 运行前已经 checkout 正确 diff。
你能说明 GitHub job permissions、Codex sandbox、safety strategy 分别是什么。
你能在日志里看到 Codex 最终输出，但看不到 OpenAI key、auth 文件和私有 token。
你能在失败时判断是 prompt 配置、API key、proxy、sudo strategy、文件权限还是触发者权限问题。
你能让同一个 PR 重跑得到稳定格式的结果。