Codex CLI 非交互模式：用 codex exec 执行一次性任务

适用场景

这篇手册适合想把 Codex 放进脚本、CI 或一次性自动化任务里的用户。比如生成变更摘要、检查文档 frontmatter、审查一段 diff、根据日志输出诊断建议。

OpenAI Codex 官方手册中把 non-interactive mode 作为程序化使用方式之一。相比普通 codex 会话，非交互模式更像一次命令：输入任务，等待结果，结束。

步骤 1：先判断任务是否适合非交互

适合：

• 目标清楚。
• 输入完整。
• 不需要多轮讨论。
• 输出格式可定义。
• 风险较低或已经配置好权限。

不适合：

• 需求还模糊。
• 需要频繁审批。
• 需要人工边看边决定。
• 可能大范围修改项目。

如果你不确定，先用普通交互模式跑一次，再沉淀成非交互命令。

步骤 2：用 codex exec 运行一次任务

基本形式类似：

codex exec "请检查当前项目的 README 是否说明了安装和运行命令，只输出缺失项。"

如果任务较长，可以把提示词写进文件，再传给命令。这样更容易版本管理，也减少 shell 转义问题。

步骤 3：明确输出格式

非交互模式最怕输出不稳定。提示词里应该写清楚格式。

示例：

请检查 content/manual 下所有文章的 frontmatter。
只输出 Markdown 表格：
文件 | 缺失字段 | 建议
如果没有问题，输出“全部通过”。
不要修改文件。

这样结果更适合被人或脚本继续处理。

步骤 4：限制权限和副作用

自动化任务应尽量只读。需要修改文件时，明确写：

只修改 content/manual 下的 MDX 文件。
不要删除文件。
不要联网。
完成后输出修改摘要。

如果运行在 CI 中，建议使用更保守的 sandbox 和 approval 配置。

步骤 5：把成功任务沉淀成脚本

当一个 codex exec 任务稳定后，可以放进项目脚本或团队文档。

例如：

codex exec "请检查本次 git diff 是否包含敏感信息。只报告风险，不修改文件。"

先从只读检查开始，不要一上来做自动修复。

常见错误

不要把模糊任务放进非交互模式，例如“帮我优化项目”。

不要默认允许高权限。自动化越强，越要收窄权限。

不要让非交互任务输出自由散文。尽量要求列表、JSON、表格或固定段落。

不要把密钥和未脱敏数据传进命令参数。

小结

codex exec 适合一次性、明确、可自动化的任务。先在交互模式里打磨提示词，再迁移到非交互模式，并保持只读、格式稳定、权限可控。