Codex CLI 参数：用命令行选项控制模型、目录和运行方式

适用场景

这篇手册适合经常在终端里使用 Codex CLI 的用户。命令行参数可以让你在不修改全局配置的情况下，临时控制模型、目录、审批、沙箱和运行方式。

OpenAI 官方 CLI reference 列出了当前可用参数。参数会随版本变化，自动化脚本中建议固定 CLI 版本并定期检查参考文档。

步骤 1：先决定参数是否应该临时使用

适合放在 CLI 参数里的内容：

• 本次运行目录。
• 本次使用的模型或 profile。
• 本次是否非交互运行。
• 本次审批或沙箱策略。
• 本次输出格式。

适合放在配置文件里的内容：

• 你长期使用的默认模型。
• 固定 MCP server。
• 团队共享 profile。
• 稳定的权限策略。

原则很简单：一次性的用参数，长期的进配置。

步骤 2：在正确目录运行

CLI 任务最容易出错的是目录不对。运行前先确认当前路径。

pwd
codex

如果要在脚本中运行，建议明确指定目录或先切换目录：

cd your-project
codex

不要在父目录、桌面或包含多个项目的目录里直接让 Codex 自动猜测目标。

步骤 3：临时切换模型或 profile

当某次任务需要不同配置时，可以通过 CLI 参数或 profile 切换，而不是改全局默认。

适合临时切换的任务：

• 一次复杂审查。
• 一次发布前检查。
• 一次只读分析。
• 一次脚本化批处理。

稳定使用后，再考虑把它沉淀成 profile。

步骤 4：非交互任务要写清楚验收

使用非交互模式或脚本化运行时，Codex 无法像聊天一样随时向你确认细节，因此提示词必须更完整。

示例：

请检查 content/manual 中所有文章 frontmatter 是否包含 source 和 status。
只报告问题，不要修改文件。

如果允许修改，要写清楚：

允许修改 content/manual 下的 MDX 文件。
修改后运行 lint 和 build，并总结变更。

步骤 5：脚本中保留日志

自动化运行时，建议保留输出日志，方便排查。

需要关注：

• Codex 是否在正确目录运行。
• 是否触发了审批或沙箱限制。
• 是否跳过了测试。
• 是否修改了预期之外的文件。
• 是否输出了敏感信息。

脚本化并不等于免审查，尤其是会写文件的任务。

常见错误

不要为了临时任务改全局配置。改完忘记恢复会影响后续任务。

不要在脚本里依赖模糊自然语言。非交互任务要写清楚输入、范围和验收。

不要忽略 CLI 版本差异。参数名和行为应以当前官方 reference 为准。

小结

Codex CLI 参数适合控制当前一次运行。长期默认写进 config.toml，临时差异用参数覆盖，非交互任务写清楚范围和验收，脚本化运行后保留日志和 diff。