Codex GitHub Action 能接入 Xcode CI 吗？2026 部署指南

症状：Agent 已能读代码或提出修改，但 CI 还不能证明 iOS/macOS 项目构建、测试或签名成功。
最快解法：可以接入，但把 Codex 执行与 Xcode 构建、测试、签名验收放进权限边界清楚的阶段；不要让 Agent Job 默认拿到生产签名材料，也不要把它放进未经隔离的 Mac Runner。

这篇指南适合希望把 Codex 纳入代码审查或受控修改流程的 iOS/macOS 开发者、负责 GitHub Actions 与 Xcode Runner 分层编排的 DevOps 工程师，以及正在评估远程 Mac 节点权限与上线条件的研发平台负责人。

开工前：先冻结凭据与 Runner 信任边界

Codex GitHub Action 可以运行在 macOS Runner 上，但“Action 支持 macOS”不等于“该 Job 天然安全”。OpenAI 的 Action 文档说明，macOS/Linux 可用其安全策略；同一文档也提醒，drop-sudo 会改变执行主机状态，在复用的自托管 Runner 上影响可能延续到后续任务。因此，先决定运行在哪台主机、触发者是否可信、任务能读取哪些凭据，再配置 Action。具体支持状态和参数以OpenAI 官方 README及其安全说明为准。

把凭据分成不同授权对象，不要统称为“CI Secrets”：

• 模型 API 密钥：只交给需要调用 Codex 的 Job。它不应因此获得发布权限。
• 仓库令牌：GitHub Actions 的 GITHUB_TOKEN 应按 Job 配置最小权限；只读审查通常不需要写权限。
• 签名材料：证书、描述文件、Keychain 解锁凭据与发布权限，留给经过审批的签名阶段。
• Runner 主机权限：Action 的安全策略约束 Codex 的执行，不等于隔离了整台主机，也不能替代 GitHub 权限、Runner 生命周期和主机清理策略。

GitHub 指出，自托管 Runner 可能被不受信任的工作流代码持续影响；相较之下，GitHub 托管 Runner 使用临时、干净的虚拟机。若必须用自托管 Mac，应按任务隔离 Runner，并确认其不接收不受信任的拉取请求代码。GitHub 的安全使用说明与自托管 Runner 文档都应纳入上线审查。

第一次执行：从受信任触发器启动独立 Agent Job

试跑时优先采用受信任维护者手动触发，或只允许可信分支进入的受控工作流。不要为了让外部拉取请求“也能跑”就切换到高权限事件，再检出并执行其代码。GitHub 特别提示，pull_request_target 工作流拥有基础仓库的令牌和 Secrets；若再检出并运行拉取请求中的代码，会把不可信代码带进高权限环境。GitHub 的安全使用 pull_request_target 文档解释了这一风险。

下面是结构示例，尖括号中的值都是需要替换并审核的占位符。Agent 与 Mac 构建使用不同 Job；示例只展示审查摘要的传递，不自动把 Agent 修改应用到构建分支。

name: agent-and-xcode-ci

on:
  workflow_dispatch:

permissions:
  contents: read

jobs:
  agent:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@<REVIEWED_CHECKOUT_COMMIT>
        with:
          persist-credentials: false

      - name: Run Codex review
        id: codex
        uses: openai/codex-action@<REVIEWED_CODEX_ACTION_COMMIT>
        with:
          openai-api-key: ${{ secrets.OPENAI_API_KEY }}
          safety-strategy: read-only
          prompt: "Review the checked-out change and report findings."

      - name: Save review output
        env:
          REVIEW: ${{ steps.codex.outputs.final-message }}
        run: printf '%s\n' "$REVIEW" > agent-review.txt

      - uses: actions/upload-artifact@<REVIEWED_UPLOAD_ARTIFACT_COMMIT>
        with:
          name: agent-review
          path: agent-review.txt

  xcode:
    needs: agent
    runs-on: [self-hosted, macOS, <TRUSTED_RUNNER_LABEL>]
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@<REVIEWED_CHECKOUT_COMMIT>
        with:
          ref: <REVIEWED_COMMIT_SHA>
          persist-credentials: false

      - run: xcodebuild build -scheme "<PROJECT_SCHEME>"

      - run: xcodebuild test -scheme "<PROJECT_SCHEME>"

      - uses: actions/upload-artifact@<REVIEWED_UPLOAD_ARTIFACT_COMMIT>
        if: always()
        with:
          name: xcode-results
          path: <RESULTS_PATH>

<REVIEWED_COMMIT_SHA> 应指向经审查、允许构建的提交；不能因为上游 Job 上传了一个补丁，就直接在有签名权限的 Mac 上执行它。示例中的 read-only 适合只读审查，不代表模型密钥在所有运行方式下都不可触及；具体限制须按当前安全文档评估。GitHub 也提醒，Action 可通过 github.token 上下文取得令牌，因此仅仅不显式传入令牌，并不能代替最小权限配置。按工作流或 Job 设置权限，参考 GitHub 的 GITHUB_TOKEN 使用说明。

首次 Xcode 验证：在 Mac Job 中收集真实项目证据

让 Codex 参与 Xcode 构建与测试，较稳妥的路径是把它放在构建前的分析或受控修改阶段，再由具备匹配 Xcode 工具链的 Mac Runner 执行真实项目检查。开始前，确认 Runner 可见的 Xcode 版本、项目 Scheme、目标平台、模拟器或设备依赖与测试计划都符合项目要求；不符合就停止，不要用 Agent 的“看起来没问题”替代环境核验。

1. 固定待测提交，记录工作流运行标识与提交 SHA。
2. 在 Mac Job 检查 xcodebuild -version、可用 Scheme 与项目实际依赖；将环境记录保存在日志中。
3. 按项目要求运行 xcodebuild build，单独保存命令退出状态。
4. 再运行 xcodebuild test，把测试执行结果与构建日志分开记录。
5. 留存 .xcresult 结果包和必要日志，并在工作流产物中标明对应提交与 Job。
6. 只有经审批的后续发布 Job 才读取签名凭据；试跑阶段使用不含生产签名材料的配置。

Apple 说明，通过 Terminal 运行 xcodebuild test 会产生 Xcode 测试结果 .xcresults 包，其中可包含测试会话结果、代码覆盖率（启用时）及其他日志；测试状态需要结合 Xcode 的结果解释，而不是只看 Agent 摘要。Apple 的测试结果文档也介绍了按 Scheme 和测试计划运行测试的方式。本文不预设构建耗时或性能收益，因为它们取决于项目、工具链、测试范围和 Runner 环境。