Codex exec 怎么用于自动化？JSONL、结构化输出与 CI 安全实践

适用场景：让 Codex 处理边界清楚、可验收的任务

非交互模式适合发布说明生成、失败日志归纳、依赖检查、代码审查、固定格式报告，以及在隔离环境中提出最小修复。它不适合把模糊的大型需求直接交给拥有广泛权限的流水线。自动化越强，输入范围、允许修改的目录、必须运行的测试和失败退出条件就越要写清楚。

官方文档指出，codex exec 可以在脚本、CI、预合并检查和定时任务中运行，也可以把最终输出通过管道交给其他工具。默认情况下，运行进度写到 stderr，最终代理消息写到 stdout，因此脚本可以只保存最终结论，同时把进度留给日志系统。若不希望把会话 rollout 文件持久化到磁盘，可使用 --ephemeral。

开始前可以先参考Codex 任务说明模板写清目标、约束和验收标准。ChatGPT Plus、ChatGPT Pro 与 Codex 的实际可用范围、额度和认证方式会随账号方案变化；需要核对会员充值或订阅入口时可访问 GPTUPCN 首页。GPTUPCN 是第三方中文信息与服务入口，并非 OpenAI 官方。

第一层输出：最终消息、完整事件流和结构化结果

最简单的调用是给 codex exec 一个单一任务说明。只关心最终文字时，让 stdout 保持干净，并用 -o 或 --output-last-message 把最后一条消息写入文件。需要观察每一步执行、文件修改、工具调用与用量时，使用 --json，此时 stdout 变成逐行 JSON 对象组成的 JSONL 事件流。下游解析器应按每一行独立解析，不要把整个文件当成一个 JSON 数组。

需要稳定字段时，使用 --output-schema 提供 JSON Schema，让最终回答符合预先约定的结构。它适合风险报告、版本信息和任务摘要，但不能替代测试：结构正确只说明数据形状可解析，不代表代码修改正确。最稳妥的做法是分别保存事件日志、最终结构化结果和 Git 差异，便于排障与审计。

第二层权限：从只读开始，只开放任务真正需要的范围

官方当前说明，codex exec 默认在只读沙箱中运行。只需分析仓库、日志或测试结果时，应保留只读；确实需要修改工作区时再使用 --sandbox workspace-write。danger-full-access 只适用于受控的隔离 runner 或容器，不能因为任务经常请求批准就直接开放整台机器。旧的 --full-auto 兼容标志已被标为弃用，新脚本应显式选择沙箱级别。

权限设计要把生成改动和发布改动分开。一个更安全的 CI 任务可以只读仓库并在工作区生成补丁文件，后续由另一个不持有模型凭据的作业审核、应用补丁和创建 Pull Request。即便 Codex 给出“测试通过”的最终文字，流水线仍应重新运行可信测试命令，检查退出码，并限定差异只能出现在允许目录。

若不清楚沙箱、网络访问与审批策略的差别，可先阅读Codex 权限与沙箱实践。组织管理员通过安全策略限制某些配置时，不应尝试绕过；应让自动化在策略允许的最小权限下失败得足够清楚。

• 分析任务：默认只读，不给写入权限
• 代码修复：只开放 workspace-write，并限定仓库工作目录
• 网络访问：仅在任务确实需要外部资料或依赖时开启
• 发布和合并：由独立人工或独立权限作业执行，不和生成步骤共用凭据
• 失败退出：命令错误、测试失败、Schema 不通过或越界修改都应阻断后续步骤

第三层认证：不要让仓库代码读取长期凭据

codex exec 默认可以复用本机已保存的 CLI 认证，但 CI 需要更严格的凭据边界。官方建议 GitHub Actions 优先使用 Codex GitHub Action，而不是在普通 shell 步骤里自行安装并暴露 API Key。不要把 OPENAI_API_KEY 或 CODEX_API_KEY 设置成检出并运行仓库代码的整个 job 都能读取的环境变量，因为构建脚本、测试、依赖生命周期钩子或被篡改的 Action 都可能读取它。

在其他受控自动化环境中，应只为真正执行 Codex 的单个进程提供 CODEX_API_KEY，并确保同一进程环境没有运行不可信代码。ChatGPT 管理的认证文件包含访问令牌，应像密码一样保护，不能提交到 Git、粘贴到工单或聊天中。能够使用短期工作负载身份时，应优先使用可轮换、最小权限的身份，而不是复制个人长期凭据。

认证成功不代表会员方案、Codex 使用额度或 API 余额相同。ChatGPT Plus / Pro 订阅与 API 计费是不同系统，自动化运行前应确认当前使用的是 ChatGPT 管理认证还是 API Key，并在预算和额度检查中分别处理。遇到登录失败可对照Codex CLI 登录与凭据缓存排查。

一套可复用的 Codex exec 自动化流程

把非交互任务拆成六个阶段更容易验收。第一步固定仓库提交和依赖，避免分析过程中代码变化；第二步收集最小输入，例如失败测试日志和受影响文件，而不是把整个生产环境暴露给任务；第三步以只读模式让 Codex给出定位结论；第四步在独立工作区用 workspace-write 生成最小补丁；第五步由可信命令重新运行测试、格式化和静态检查；第六步保存 JSONL、最终报告和 diff，由人工或后续受限作业决定是否合并。

提示词要包含可以机器检查的条件，例如“只修改 src/payment 目录”“不要更新依赖”“运行指定测试”“若无法复现则停止并报告”。输出 Schema 可以规定状态、原因、变更文件、测试命令和剩余风险，但代码差异仍要由 Git 检查。完成后可按Codex 测试证据与交付验收核对证据链。

• 固定输入提交、运行目录与依赖版本
• 把任务目标、禁止项和验收命令写进同一个提示词
• 分析与修改分两次运行，前一步保持只读
• 保存 JSONL、最终结果、测试日志和补丁四类产物
• 让独立步骤检查越界文件、失败退出码和未提交敏感文件
• 未经审查不直接部署到生产环境

会话续接、Git 检查与常见失败

需要两阶段处理时，可以先运行一次审查，再用 codex exec resume --last 继续最近会话，或用指定会话 ID 续接。续接适合让第二步利用第一步的上下文，但流水线仍要保存显式输入和结果，不能把关键状态只留在会话里。为了降低破坏性修改风险，Codex 要求命令在 Git 仓库中运行；只有确认环境安全时才考虑跳过仓库检查。

常见失败包括：把 JSONL 当 JSON 数组导致解析报错；把进度日志混进 stdout 破坏结构化结果；Schema 缺少 required 或允许任意额外字段；工作区只读却要求修改；CI 运行了仓库脚本后才注入密钥；Codex 修改成功但测试步骤没有独立复验。排查时先看事件中的 turn.failed、error 和命令退出码，再查权限、认证和工作目录，不要一上来扩大权限。

如果同一脚本在本机成功、CI 失败，还要比较操作系统、shell 引号、当前目录、Git 状态、依赖缓存和组织策略。配置问题可参考Codex config.toml 优先级排查；云端初始化失败则参考Setup Script 与缓存排查。

结论：自动化的核心是可控输入、最小权限和独立验收

codex exec 提供了适合脚本与 CI 的非交互入口：默认最终消息可直接管道处理，--json 提供完整 JSONL 事件，--output-schema 让最终结果具备稳定字段，resume 可以续接分阶段任务。工程上真正重要的是，不把这些输出当成无条件可信的成功信号。

稳定做法是只给任务必要输入和权限，把模型凭据限制在单个受控进程，生成改动后由独立测试、差异检查和人工门槛决定是否进入下一步。这样既能利用 Codex 自动化重复工作，也能保留回滚、审计和故障定位能力。功能、参数与认证规则可能更新，正式接入前应再次核对执行当天的官方文档。