GitHub Actions 受限 Codex 作业

解决的问题

Codex 在 CI 里跑不是新鲜事，问题在于怎么把它关进笼子。很多团队直接把 OPENAI_API_KEY 丢给一个 run: codex ... 就上线，结果 CI 里的 Codex 拥有和开发者一样的权限：能写任意文件、能推任意分支、能碰生产配置。一旦 prompt 被仓库里的内容诱导，或者被 PR 中精心构造的 diff 带偏，破坏范围就是整个仓库。

这个技能要解决的，就是在 GitHub Actions 中运行 Codex 做 PR 审查和仓库维护时，显式收紧权限边界——明确 workflow 授予哪些权限、Codex 以什么提示词运行、CI 边界在哪里止步。

如何工作

核心思路是利用 codex-action 把 Codex CLI 的安装和配置封装成一步，同时让工作流的权限策略由你自己定义。关键步骤包括：

• 配置提供方密钥：在 GitHub Secrets 中配置所选模型提供方的 API Key，例如 OPENAI_API_KEY，或走 Azure 时使用 AZURE_OPENAI_API_KEY。密钥只存在于 Actions 运行环境，不进入仓库。
• 设定安全策略：在 Linux/macOS 上可以选择不同的 safety-strategy。例如选择 drop-sudo，Codex 运行的后续步骤就无法再调用 sudo，这本身就是一个权限降级的硬边界。
• 指定 Responses API Endpoint：responses-api-endpoint 必须是完整 URL，包括查询参数。走 Azure 时形如 https://YOUR_PROJECT_NAME.openai.azure.com/...，这决定了 Codex 把请求发往哪里。
• 定义提示词与触发时机：PR 审查场景下绑定 pull_request 事件；仓库维护场景下用 schedule 触发。提示词写进 workflow，Codex 只执行你写的指令，不做无约束的自主发挥。

适用边界与注意点

• 仅限 GitHub Actions：前提是仓库已经使用 GitHub Actions，且有可用的 workflow 文件。这不是本地 CLI 工具，也不是自托管运行器专属。
• 权限收紧是双刃剑：选了 drop-sudo 之后，如果后续步骤里有需要 sudo 的逻辑（比如装某些系统级依赖），会直接失败。需要在设计 workflow 时提前想清楚哪些步骤需要特权、哪些不需要。
• 不要指望 Codex 自己决定边界：安全策略、endpoint、提示词都由你在 workflow 里写死。Codex 不会自己判断"这个操作不该做"，边界是 workflow 给的，不是模型悟出来的。
• 上游文档是权威来源：这个技能提取自 openai/codex-action 的官方 README，如果参数行为有疑问，先去上游确认，不要凭猜测写 workflow。