Codex / 概念
沙盒、权限和审批
理解 Codex 沙盒如何限制文件、命令和网络访问，以及它如何与审批策略一起控制本地智能体的自主程度。
沙盒是什么
Codex 的沙盒是让智能体自主行动时仍保持边界的运行环境。Codex 在 App、IDE 扩展和 CLI 中执行本地命令时，这些命令默认不会拿到整台机器的完整权限，而是在受限环境中运行。
沙盒边界决定 Codex 可以自己做什么，例如能修改哪些文件、命令能否访问网络、是否只能在当前 workspace 内工作。当任务停留在这个边界内，Codex 可以连续执行；当它需要越界，就会进入审批流程。
沙盒和审批是两套不同但互补的控制。沙盒定义技术边界，审批策略决定 Codex 什么时候必须停下来询问。理解这点很重要：允许更多审批并不等于扩大沙盒，扩大沙盒也不等于完全不需要审批。
- 沙盒约束的是模型生成并启动的命令，不只是 Codex 内置的文件编辑。
- git、包管理器、测试框架、构建脚本等子进程都会继承同一套沙盒边界。
- macOS、Linux、WSL2 和 Windows 的底层实现不同，但目标都是让智能体在明确范围内工作。
为什么需要沙盒
沙盒减少低风险操作带来的审批疲劳。你不需要为每一次读文件、改工作区文件或运行本地测试单独确认，但仍然可以知道 Codex 何时尝试越过边界。
它也让团队更容易建立信任模型：你不是单纯相信智能体“会做好事”，而是让它在操作系统或运行时强制执行的限制中工作。这样在处理真实仓库时，可以给它足够空间完成任务，又不会让它默认触碰主机、网络或敏感目录。
平台前提
Codex 会自动使用可用的平台沙盒能力。macOS 使用系统内置机制；Windows 可使用原生 Windows 沙盒或 WSL2 的 Linux 沙盒；Linux 和 WSL2 推荐安装 bubblewrap。
在某些 Linux 发行版上，bubblewrap 还依赖未特权用户命名空间或 AppArmor 配置。Codex 启动时如果检测到 bwrap 缺失或无法创建所需命名空间，会显示警告；这时应优先修复系统沙盒能力，而不是直接切到 full access。
sudo apt install bubblewrap
# 或
sudo dnf install bubblewrap| 平台 | 沙盒准备 | 注意事项 |
|---|---|---|
| macOS | 开箱即用 | 使用系统内置沙盒能力，通常不需要额外安装。 |
| Windows PowerShell | 使用原生 Windows 沙盒 | 详见官方 Windows 文档，系统权限与本地 shell 环境会影响可用性。 |
| WSL2 / Linux | 安装 bubblewrap | Codex 优先使用 PATH 中的 bwrap；缺失或命名空间受限时会提示。 |
如何控制沙盒
多数用户从产品里的权限控制开始。Codex App 和 IDE 可在输入框附近选择权限模式；CLI 会话中可以用 /permissions 切换。
会话中切换
在 CLI 中使用 /permissions 查看和切换当前会话允许的行为。适合从只读探索切到工作区编辑，或在任务变敏感时收紧权限。
/permissions启动时指定
在命令行启动 Codex 时显式给出 sandbox 和 approval policy，让一次会话从一开始就有清晰边界。
codex --sandbox workspace-write --ask-for-approval on-request写入默认配置
如果希望每次启动都保持相同行为，把默认值写进 Codex 的 config.toml，并按项目风险选择是否使用更严格的默认值。
sandbox_mode = "workspace-write"
approval_policy = "on-request"
approvals_reviewer = "user"常见沙盒模式
Codex 常用沙盒模式可以理解为三档：只读、工作区可写、完全访问。每一档都应和审批策略一起看。
| 模式 | Codex 可做什么 | 适合场景 |
|---|---|---|
| read-only | 可以检查文件，但编辑文件或运行需要更高权限的命令前会受限或请求审批。 | 代码理解、方案设计、敏感仓库、初次接手项目。 |
| workspace-write | 可以读取文件、在 workspace 内编辑，并运行边界内的常规本地命令。默认网络关闭。 | 日常本地开发、修 bug、补测试、改页面。 |
| danger-full-access | 取消沙盒限制，文件系统和网络边界都被放宽。 | 仅限外部已隔离的容器、CI runner 或一次性 VM。 |
推荐默认值
低风险本地自动化通常使用 workspace-write + on-request。它允许 Codex 在工作区内推进任务，同时在越界、联网或敏感操作时停下来询问。
审批策略
审批策略控制 Codex 什么时候暂停。官方常见策略包括 untrusted、on-request 和 never；当审批是交互式时，还可以选择由用户或 auto_review 审查。
auto_review 只审查本来就需要审批的请求，例如沙盒越界、被阻止的网络请求、request_permissions 提示或带副作用的 app/MCP 工具调用。已经在沙盒内允许的行为不会额外经过它。
approval_policy = "on-request"
approvals_reviewer = "auto_review"| 审批策略 | 行为 | 建议 |
|---|---|---|
| untrusted | 不在可信集合中的命令会询问。 | 适合不熟悉仓库或需要更频繁确认的场景。 |
| on-request | 在沙盒内继续，越界时请求审批。 | 推荐给大多数交互式本地开发任务。 |
| never | 不弹出审批提示，Codex 在既定沙盒内尽力完成。 | 适合非交互脚本，但必须提前收紧 sandbox。 |
| auto_review | 不是审批策略，而是审批 reviewer； eligible 请求先交给审核智能体。 | 适合减少人工审批，但不能改变沙盒边界。 |
网络访问
workspace-write 默认关闭命令网络访问。需要联网安装依赖、调用 API 或访问内部服务时，应明确打开网络，并尽量用域名规则限制出口。
network_proxy 不会单独授予网络权限，它只是对已启用的命令网络访问施加策略。也就是说，network_access 仍然决定命令有没有网络，network_proxy 决定这些网络流量可去哪里。
域名策略是 allowlist-first：精确主机只匹配自身，*.example.com 匹配子域，**.example.com 同时匹配根域和子域，deny 总是优先。全局 * allow 代表很宽的网络权限，应尽量避免。
[sandbox_workspace_write]
network_access = true
[features.network_proxy]
enabled = true
domains = { "api.openai.com" = "allow", "example.com" = "deny" }受保护路径
默认 workspace-write 里，部分目录仍保持只读。官方特别提到 .git、.agents、.codex 及其递归内容会被保护，防止任务意外破坏仓库状态或 Codex 自身配置。
如果 .git 是一个 gitdir 指针文件，解析后的 Git 目录同样只读。遇到 git commit、git reset、修改 Codex 配置等需求时，Codex 可能需要审批或明确授权。
- 不要为了让一次命令通过而直接切到 danger-full-access。
- 先判断任务是否真的需要写受保护路径，能否改用普通文件、临时目录或更小的审批例外。
- 完成后检查 diff，确认没有意外修改版本控制、配置或自动化文件。
无提示运行
如果要取消审批提示，可以用 --ask-for-approval never 或 -a never，但它仍然会受到 sandbox 模式约束。
这意味着 never 不等于全权限。更安全的非交互做法是 workspace-write + never，让 Codex 在工作区内自动执行；只有在外部环境已经隔离、没有主机风险时才考虑 danger-full-access + never。
如果确实需要读文件、写文件、运行命令并联网且完全无提示，官方也提供 danger-full-access 或 dangerously bypass 相关入口，但这些只应在受控环境中使用。
codex --sandbox workspace-write --ask-for-approval never "运行测试并修复失败"
# 高风险，仅限隔离环境
codex --sandbox danger-full-access --ask-for-approval never学习检查清单
把本页内容落到真实任务中，用入口、上下文、权限、验证和团队规则五个维度检查是否真正掌握。
学习检查清单
读完本页后，不要只记住概念名。你应该能把“沙盒、权限和审批”放回 Codex 的真实工程流程里：任务从哪里发起，系统会加载什么上下文，哪些动作需要审批，结果如何验证，失败时如何回退。
如果这是概念页面，要特别确认它如何影响真实任务：它改变上下文、权限、执行路径、验证方式，还是改变团队协作流程。
- 能用自己的话说明本页解决的具体问题，而不是只复述标题。
- 能写出一个最小示例任务，并标明目标、范围、禁止事项和验收标准。
- 能判断哪些信息应该放进当前提示，哪些应该沉淀到项目规则或配置里。
- 能说明哪些长期规则应该写进 AGENTS.md，哪些运行行为应该交给 config.toml、permission profile、skills 和 MCP。
- 能在任务完成后检查 diff、命令输出、测试结果、截图或 PR 说明，而不是只相信自然语言总结。
如果要把本页用于团队培训，可以让学员用 Codex 完成一个小任务：先只读解释，再提交计划，再执行最小改动，最后用真实验证命令和人工 diff 审查收尾。
Codex 实操注意事项
围绕本地环境、权限升级、远程入口、自动化失败和回滚补齐 Codex 使用中最容易被忽略的执行细节。
Codex 实操注意事项
这一页属于 Codex 的核心概念。学习时要把概念和真实执行联系起来：它会改变上下文、权限、任务拆分、验证路径，还是改变团队协作方式。
处理“沙盒、权限和审批”相关任务时，建议始终先确认当前 Git 状态和工作目录。Codex 可以很快完成修改，但它不会自动知道哪些未提交改动来自用户、哪些文件不能碰、哪些命令会影响生产环境。
- 本地任务优先使用低风险分支或工作树，完成后用 git diff 审查。
- 涉及安装依赖、联网、数据库、部署、push、删除、reset 时，先要求 Codex 解释影响再批准。
- 远程或协作入口生成的结果，也要回到 PR、CI、构建日志和测试证据中确认。
- 自动化任务要提前定义失败输出和退出条件，避免 Codex 在错误方向上反复尝试。
把 Codex 当成能执行命令的工程队友，而不是只会写文本的助手。越靠近真实系统，越需要明确边界、证据和回滚。