Codex CLI 自动批准与跳过确认：安全模式和危险模式的区别¶
先看结论
- 只想取消确认、但仍限制文件范围：使用
-a never -s workspace-write - 还需要访问网络：在上面的基础上单独启用
sandbox_workspace_write.network_access=true --dangerously-bypass-approvals-and-sandbox会同时取消确认和沙箱，只适合外部已经隔离的环境
很多人搜索“Codex 自动同意”时，其实混合了两个问题：是否每次询问批准，以及命令能访问哪些文件和网络。这两个控制项必须分开选择。仅仅不弹确认框，并不意味着必须关闭沙箱。
直接复制：三种运行方式¶
1. 日常开发：保留确认与工作区沙箱¶
codex -a on-request -s workspace-write "Run tests and fix failures"
这是交互式工作的稳妥起点。Codex可以在工作区内修改文件，并在需要更高权限时请求批准。
2. 自动同意：不再询问，但保留工作区沙箱¶
codex -a never -s workspace-write "Run tests and fix failures"
-a never 只改变批准策略；-s workspace-write 继续限制文件访问范围。命令执行失败时，错误会直接返回给Codex，而不会请求在沙箱外重试。
如果任务确实需要下载依赖或调用API，再单独允许网络：
codex -a never -s workspace-write \
-c 'sandbox_workspace_write.network_access=true' \
"Update dependencies and run tests"
3. 完全绕过：仅限外部隔离环境¶
codex --dangerously-bypass-approvals-and-sandbox "Task"
这个选项同时跳过批准和沙箱。官方CLI帮助将它标记为“EXTREMELY DANGEROUS”，并说明它只适合已经在容器、一次性虚拟机或其他外部沙箱中运行的场景。不要在包含个人文件、凭据或生产密钥的普通电脑上把它设为默认值。
如何写入 config.toml¶
默认配置文件位于 $CODEX_HOME/config.toml；未设置 CODEX_HOME 时通常是 ~/.codex/config.toml。
approval_policy = "never"
sandbox_mode = "workspace-write"
[sandbox_workspace_write]
network_access = true
建议先用命令行参数测试，再决定是否持久化。命令行参数优先于配置文件，因此排查时要同时检查启动脚本、alias和IDE设置。
旧教程为什么容易误导¶
旧文章常把 --full-auto 当成“自动批准”的唯一答案，或者建议直接使用 danger-full-access。这样会把批准策略、文件沙箱和网络权限混在一起。
当前CLI已经明确列出三个独立选择：
| 控制项 | 常用值 | 作用 |
|---|---|---|
| 批准策略 | on-request / never | 是否向用户请求批准 |
| 文件沙箱 | read-only / workspace-write / danger-full-access | 命令可以访问的文件范围 |
| 网络访问 | sandbox_workspace_write.network_access | 工作区沙箱内是否允许出站网络 |
on-failure 已被CLI标记为deprecated。交互式运行优先使用 on-request，非交互式运行需要不询问时使用 never。
启动前的安全检查¶
- 先运行
codex --help，确认当前安装版本支持所用参数 - 工作目录只放本次任务需要的文件
- 不把
.env、SSH密钥、云凭据和生产令牌暴露给任务 - 自动化任务仍要经过测试、代码审查和部署门禁
- 需要完全绕过时，使用一次性容器或虚拟机，而不是日常主机
常见问题¶
Codex如何不再弹出确认？
使用 codex -a never -s workspace-write。它关闭批准提示，同时保留工作区文件沙箱。
自动批准后为什么curl或npm仍然失败？
批准策略和网络权限是两回事。保留 workspace-write，并添加 -c 'sandbox_workspace_write.network_access=true'。
应该直接使用danger-full-access吗？
通常不应该。先用 workspace-write；只有外部已经隔离且任务确实需要访问工作区外文件时，才考虑更强模式。