Codex CLI 自动同意怎么开：参数、配置与安全边界

更新于 2026-11-02 · onehop.cyou

简答：Codex CLI想减少反复确认，优先使用<code>--approve-for-me</code>，它会保留<code>on-request</code>审批策略和<code>workspace-write</code>沙盒；如果要永久保存，可在<code>config.toml</code>中设置<code>approvals_reviewer = "auto_review"</code>。不要把<code>--yolo</code>当作普通自动同意，它会同时绕过审批和沙盒，只适合外部隔离环境。

定义：Codex CLI“自动同意”是让符合条件的审批请求交给自动复核器处理，或在特定命令中关闭人工审批；它不等于无边界访问文件、网络和系统。

先看结论：3种CLI参数与自动复核不是一回事

本文是 OneHop 的第三方使用指南，不是 Codex 官方页面。以下内容按 2026-11-02 检索到的命令行参考和安全文档整理；不同安装版本仍应先用本机帮助输出核验。

官方命令参考明确说明，--approve-for-me与--sandbox、--yolo冲突，交互式CLI也不接受同时指定--ask-for-approval。查看 Codex CLI 命令行参数参考。

当前命令临时开启自动同意

如果只是想测试一次，先从项目目录启动，不要立即修改永久配置。下面命令只针对当前进程生效。

macOS/Linux Bash：交互式CLI

codex --approve-for-me

macOS/Linux Bash：非交互式执行

codex exec --approve-for-me "检查当前项目的测试配置，并给出修改建议"

Windows PowerShell：交互式CLI

codex --approve-for-me

Windows PowerShell：非交互式执行

codex exec --approve-for-me "检查当前项目的测试配置，并给出修改建议"

成功判定不是“完全不再弹出任何提示”，而是符合自动复核范围的请求不再逐项等待人工确认；如果任务涉及沙盒外路径、网络或其他受限能力，仍可能出现额外审批。命令参考将该参数定义为自动审批复核加workspace-write沙盒，因此不要把它理解成完全放权。

永久配置：自动复核与沙盒分开写

官方安全文档给出了自动审批复核的配置方式：在配置文件中保留approval_policy = "on-request"，再指定approvals_reviewer = "auto_review"。这是一种“自动处理符合条件的审批请求”的配置，不是无条件永久同意。

macOS/Linux：编辑配置文件

文件位置：~/.codex/config.toml

可按下面内容配置：

approval_policy = "on-request"
approvals_reviewer = "auto_review"
sandbox_mode = "workspace-write"

Windows：编辑配置文件

文件位置：%USERPROFILE%\.codex\config.toml

PowerShell中可先打开文件：

notepad "$env:USERPROFILE\.codex\config.toml"

然后写入与上面相同的三个配置项。保存后重启Codex，再用一个只会读取和修改当前工作区的低风险任务验证。

文档还展示了配置预设的做法：可以把不同权限组合保存为 profile，再通过codex --profile profile-name选择。查看审批、安全与配置示例。

日常开发、只读检查与CI应该怎么选

可以复制下面的CI风格示例，但请先确认运行器只挂载了必要目录，并清理环境中的敏感凭据：

Bash

codex exec --approve-for-me --json "运行项目测试并输出失败原因，不修改仓库外文件"

PowerShell

codex exec --approve-for-me --json "运行项目测试并输出失败原因，不修改仓库外文件"

官方参考将codex exec定义为非交互式运行方式，并支持将结果输出为文本或JSONL；在自动化环境中，应同时检查进程退出状态和输出内容，不能只看终端是否有文字。查看 exec 子命令说明。

为什么设置后仍然会询问确认

1. 把自动复核误写成永久无条件同意。“自动复核”只处理符合条件的审批请求，沙盒限制仍然存在。先检查sandbox_mode是否为workspace-write，并确认任务没有访问工作区外路径。
2. 把参数混用。--approve-for-me不能再和--sandbox、--yolo组合；交互式运行也不要同时追加--ask-for-approval。先删掉冲突参数，再单独测试。
3. 永久配置写进了错误位置。检查macOS/Linux的~/.codex/config.toml或Windows的%USERPROFILE%\.codex\config.toml，同时确认是否使用了其他CODEX_HOME或profile。
4. 本机版本不支持当前字段。先执行codex --help、codex exec --help，以实际帮助输出为准；不能仅凭旧文章判断当前参数仍有效。
5. 仍在使用已移除的untrusted审批策略。OpenAI帮助文档说明，Codex CLI 0.149.0及更高版本不再支持approval_policy = "untrusted"，也应检查活动profile、组织配置和--ask-for-approval untrusted引用。可先删除该项，再采用read-only + on-request的保守组合。查看官方迁移说明。

安全自查：开启自动同意前先确认这6项

• 当前目录是否是你明确授权的项目，而不是包含密钥、生产配置或个人文件的上级目录。
• 工作区外是否存在不必要的写权限；需要额外目录时，优先使用明确的目录授权，而不是直接使用--yolo。
• 是否把API Key、云凭据或SSH密钥放在Codex可能读取的目录中。
• CI运行器是否为临时环境，任务结束后是否会清理工作区和日志。
• 是否审查了项目中的脚本、hooks和依赖安装命令。
• 是否在升级或修改配置后重新执行codex --help和一个低风险测试任务。

最稳妥的实践是：本地开发用--approve-for-me，只读分析用read-only，CI使用最小目录和受控配置；只有在外部隔离已经完成、且你理解后果时，才考虑--yolo。官方参数参考也明确要求把绕过审批和沙盒的模式限制在外部强化环境中。

常见问题

Codex CLI有没有真正永久自动同意的配置？

可以把自动审批复核保存到config.toml，但官方文档展示的是approval_policy = "on-request"配合approvals_reviewer = "auto_review"，它不是无条件永久放权；沙盒限制仍然有效。

--approve-for-me和--ask-for-approval never有什么区别？

--approve-for-me使用自动审批复核，并固定采用on-request审批与workspace-write沙盒；--ask-for-approval never是不等待人工审批，沙盒仍由其他配置决定，两者不要在交互式CLI中混用。

--yolo是不是最简单的自动同意参数？

它确实会绕过审批，但也会绕过沙盒。官方参数说明要求只在外部强化隔离环境使用，因此不建议在日常真实开发目录直接启用。

为什么配置approval_policy = "untrusted"后Codex无法启动？

官方帮助文档说明，Codex CLI 0.149.0及更高版本不再支持该审批策略。删除该配置，并检查活动profile、组织配置和命令行参数中是否仍引用untrusted。

Codex exec能否用于无人值守任务？

可以。官方命令参考将codex exec定义为非交互式运行方式，适合脚本和CI；建议使用受控目录、最小权限配置，并检查退出状态与输出内容。

相关阅读

• 先用最小请求验证 API，再排查认证和路径问题
• 查看另一个 AI 工具的配置与报错排查方法
• 了解 API Key、Base URL 与模型名的核验思路

参考资料

1. Command line options – Codex CLI | ChatGPT Learn（learn.chatgpt.com）
2. Agent approvals & security | ChatGPT Learn（learn.chatgpt.com）
3. Using Codex with your ChatGPT plan | OpenAI Help Center