沙箱机制:Codex 如何控制 AI 权限
与 GitHub Copilot 等行内补全工具不同,Codex CLI 是一个能够真正执行操作的 AI Agent——它可以修改文件、运行 shell 命令、安装依赖。这意味着需要一套权限控制机制来避免 AI"越权"。
Codex CLI 通过审批模式(approval mode)实现这个控制层,有三个级别:
| 模式 | 文件编辑 | Shell 命令 | 需要确认 | 适用场景 |
|---|---|---|---|---|
| suggest 默认 | 每次确认 | 每次确认 | 所有操作 | 日常开发、学习、代码审查 |
| auto-edit | 自动执行 | 每次确认 | 仅 shell 命令 | 重构任务、批量修改、日常开发加速 |
| full-auto | 自动执行 | 自动执行 | 无 | CI/CD、Docker 隔离环境、受信任的自动化任务 |
suggest 模式:最安全,人工全程把关
这是 Codex CLI 的默认模式。每次 AI 想要修改文件或运行命令,都会先展示 diff(或命令内容),等待你按 y 确认或 n 跳过。
$ codex
# 等同于:
$ codex --approval-mode suggest
在 suggest 模式下,Codex 会这样交互:
- AI 分析任务,生成操作计划
- 对每个文件修改,显示 unified diff,你选择「Apply」或「Skip」
- 对每个 shell 命令,显示命令内容,你选择「Run」或「Skip」
- 你也可以选择「Edit」手动修改 AI 的建议再应用
适合场景:
- 新手初次使用 Codex,观察 AI 的行为模式
- 处理生产代码,需要逐行审查变更
- 学习特定技术或代码风格
- 信任度还没建立的新项目
auto-edit 模式:自动改文件,手动审 shell
auto-edit 让 AI 自动完成文件修改,但执行 shell 命令前仍然需要你确认。这是大多数熟练用户在日常开发中的最佳平衡点。
$ codex --approval-mode auto-edit
# 简写标志:
$ codex --auto-edit
为什么 shell 命令仍然需要确认? 文件修改的影响是可见的、可逆的(Git 回滚)。但 shell 命令的潜在影响更广——比如 rm -rf、npm publish、修改系统配置——因此保留了人工把关这道防线。
适合场景:
- 已熟悉 Codex 输出风格的开发者
- 需要快速完成大量文件修改(重构、添加注释、类型标注)
- 在有良好 Git 历史记录的项目中工作(出错可回滚)
# 为所有 TypeScript 文件添加严格类型,文件自动改好,npm run check 需确认才执行
$ codex --auto-edit
# 然后输入:为 src/ 目录下的所有组件添加 PropTypes 定义
full-auto 模式:完全自主,适合 CI/CD
full-auto 模式下,Codex 会自主完成所有操作——包括文件修改和 shell 命令执行——不需要任何人工确认。这是 codex exec 在 CI/CD 环境中的标准使用方式。
# 交互模式(不常用,谨慎)
$ codex --approval-mode full-auto
# codex exec(常用——非交互,适合脚本和 CI)
$ codex exec --approval-mode full-auto "生成 CHANGELOG 条目"
# 或使用快捷标志:
$ codex exec --dangerously-auto-approve-everything "修复所有 lint 错误"
本地使用 full-auto 需谨慎:full-auto 意味着 AI 可以在你的机器上执行任意命令。推荐只在以下情况使用:① CI/CD 容器环境;② 已用 Git 保护代码(有回退能力);③ 任务范围明确、风险可控。不建议在有重要数据的本地机器上对模糊任务使用 full-auto。
适合场景:
- CI/CD 流水线(GitHub Actions、GitLab CI)
- 在 Docker 容器或临时环境中运行
- 明确、边界清晰的自动化任务(生成 changelog、修复特定错误)
- 已有完整测试套件,可验证 AI 输出的正确性
沙箱的边界:哪些操作 Codex 永远不会做
无论选择哪种审批模式,Codex CLI 都有一些内置的安全约束:
- 不会访问
~/之外的系统目录(除非明确被要求) - 不会主动联网(除正常的 API 调用外)
- 操作范围默认限制在当前工作目录
- macOS 上使用 Apple Sandbox,full-auto 模式下仍有系统级隔离
- 可通过 AGENTS.md 的
disallow_commands进一步限制允许执行的命令集
# 在 AGENTS.md 中禁止某些危险命令
disallow_commands:
- rm -rf
- git push --force
- npm publish
- pip install # 可在 CI 中解除限制
持久配置审批模式
每次用命令行参数指定审批模式略显繁琐。可以在配置文件中设置默认值:
全局默认(~/.codex/config.toml)
# 将全局默认改为 auto-edit(推荐熟练用户)
approval_mode = "auto-edit"
# 可选值: "suggest" | "auto-edit" | "full-auto"
项目级默认(AGENTS.md)
# 这个项目有完整 CI,本地开发可以更宽松
approval_mode: auto-edit
## 项目背景...
CI/CD 推荐配置
name: AI Code Tasks
on:
push:
branches: [main]
jobs:
codex-tasks:
runs-on: ubuntu-latest
permissions:
contents: write
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 0
- name: Install and run Codex
env:
OPENAI_API_KEY: ${{ secrets.OPENAI_API_KEY }}
run: |
npm install -g @openai/codex
# full-auto 在 CI 容器中是安全的
codex exec --approval-mode full-auto "更新 CHANGELOG.md 中的变更记录"
三种模式综合对比
| 维度 | suggest | auto-edit | full-auto |
|---|---|---|---|
| 文件修改 | 每次确认 | 自动 | 自动 |
| Shell 命令 | 每次确认 | 每次确认 | 自动 |
| 交互停顿 | 多 | 少(仅命令) | 无 |
| 误操作风险 | 最低 | 低 | 中(本地)/ 低(CI容器) |
| 适合 codex exec | - | 可用 | 推荐 |
| 推荐场景 | 学习、生产审查 | 日常开发 | CI/CD、自动化 |
最佳实践建议
推荐的渐进式配置策略:
- 初次使用:
suggest——观察 Codex 的行为模式,建立对工具的理解 - 熟悉后:切换到
auto-edit——提高效率,保留 shell 命令的安全把关 - CI/CD 场景:使用
full-auto——在隔离环境中最大化自动化效益
无论使用哪种模式,以下习惯能有效降低风险:
- 确保项目在 Git 版本控制下:所有变更都有回退路径
- 在 AGENTS.md 中限制高风险命令:特别是在 full-auto 模式下
- 优先用 codex exec 跑 full-auto:非交互的 exec 模式更适合批量任务,且在 CI 中有天然隔离
- 任务描述要精确:模糊的任务在 full-auto 下风险更高
在 CI/CD 中使用 full-auto?查看完整的 GitHub Actions 集成指南:CI/CD 集成指南 和 codex exec 完整指南。
常见问题
Codex CLI 默认是哪种审批模式?
默认是 suggest 模式。每次文件修改和 shell 命令执行前都会显示内容并等待确认,是最安全的模式。
full-auto 模式安全吗?
在 CI/CD 容器环境中是安全的——操作被限制在容器内,不影响本地机器。在本地使用需要谨慎:确保项目在 Git 版本控制下,任务描述精确,并在 AGENTS.md 中限制高危命令。
如何在 codex exec 中指定审批模式?
用 --approval-mode 参数:codex exec --approval-mode full-auto "任务"。也可以用快捷标志 --auto-edit 或 --dangerously-auto-approve-everything。在 config.toml 中设置 approval_mode = "full-auto" 可作为持久默认值。
auto-edit 和 full-auto 的主要区别是什么?
auto-edit 自动执行文件修改,但 shell 命令(如运行测试、安装依赖)仍然需要确认。full-auto 对所有操作(包括 shell 命令)都自动执行,适合完全自动化的 CI/CD 环境。
我在 full-auto 下 Codex 删了不该删的文件,怎么恢复?
如果项目在 Git 版本控制下,运行 git diff 查看变更,然后 git checkout -- <file> 恢复特定文件,或 git reset --hard HEAD 回滚所有未提交的变更。这也是在 full-auto 下工作前始终要确保代码在 Git 中的原因。