沙箱，是让 Codex 可以自主行动、但又不会默认获得你整台机器无限访问权限的边界。当 Codex 在 Codex App、IDE 扩展 或 CLI 中运行本地命令时，这些命令默认会在受约束的环境中执行，而不是直接拥有完全访问权限。
这个环境定义了 Codex 能自主完成什么，例如它可以修改哪些文件、命令是否允许使用网络。当任务始终待在这些边界内时，Codex 就能继续推进而不必停下来确认；一旦需要越界，它就会退回到审批流程。
沙箱做了什么
沙箱不仅作用于 Codex 的内建文件操作，也作用于它启动出来的命令。如果 Codex 运行 git、包管理器或测试运行器之类的工具，这些命令同样会继承相同的沙箱边界。
Codex 在不同操作系统上使用各自原生的限制机制。实现方式会因 macOS、Linux、WSL 和原生 Windows 而不同，但整体思路一致：为智能体提供一个边界清晰、可受控的工作区，让常规任务能在明确限制内自主完成。
为什么这很重要
沙箱可以减少审批疲劳。与其让你确认每一个低风险命令，不如让 Codex 在你已经接受的边界内自由读取文件、修改代码、运行常规项目命令。
它也让智能体式工作的信任基础更明确。你信任的不只是智能体的意图，还包括它始终处在明确且会被强制执行的边界之内。这样一来，你既能更放心地让 Codex 自主工作，也能清楚知道它会在什么时候停下来向你求助。
开始使用
当你使用默认权限模式时，Codex 会自动启用沙箱。
前提条件
在 macOS 上，沙箱基于内建的 Seatbelt framework，开箱即用。
在 Windows 上，当你在 PowerShell 中运行时，Codex 会使用原生 Windows sandbox；当你在 WSL2 中运行时，则会使用 Linux 沙箱实现。
在 Linux 和 WSL2 上，请先通过包管理器安装 bubblewrap：
sudo apt install bubblewrapsudo dnf install bubblewrapCodex 会优先使用 PATH 中找到的第一个 bwrap 可执行文件。如果没有，它会退回到自带 helper，但这个 helper 需要开启 unprivileged user namespaces。对大多数发行版来说，安装系统自带的 bubblewrap 包是最稳定的方案。
当缺少 bwrap 或无法创建 user namespaces 时，Codex 会在启动时给出警告。对于默认通过 AppArmor 限制非特权 user namespace 的发行版，你可以这样启用：
sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0你如何控制它
大多数人一开始都是通过产品中的权限控制来管理沙箱。
在 Codex App 和 IDE 扩展中，你可以在 composer 或聊天输入框下方的权限选择器中切换模式。这个选择器允许你使用 Codex 的默认权限、切换到完全访问，或使用自定义配置。
在 CLI 中，你可以使用 /permissions 在会话中切换模式。
配置默认值
如果你希望 Codex 每次启动都使用同一种行为，可以通过自定义配置来实现。Codex 会把这些默认值写在本地设置文件 config.toml 中。配置基础 解释了它的工作方式，配置参考 记录了 sandbox_mode、approval_policy 和 sandbox_workspace_write.writable_roots 等精确配置键。你可以通过这些设置决定 Codex 默认能获得多大自主权、它可以写哪些目录，以及它应该在什么时候暂停等待审批。
从高层来看，常见的沙箱模式有：
read-only：Codex 可以检查文件，但不能编辑文件，也不能在未获审批的情况下运行命令。workspace-write：Codex 可以读取文件、在工作区内编辑，并在这个边界内运行常规本地命令。这是本地工作中摩擦较低的默认模式。danger-full-access：Codex 不受沙箱限制运行。这会移除文件系统和网络边界，只应在你确实希望 Codex 以完全访问权限工作的情况下使用。
常见的审批策略有：
untrusted：对于不在可信集合中的命令，Codex 会先询问你。on-request：Codex 默认在沙箱内工作，只有在需要越界时才请求审批。never：Codex 不会停下来弹出审批提示。
Full access 指的是同时使用 sandbox_mode = "danger-full-access" 和 approval_policy = "never"。而 --full-auto 则是风险更低的本地自动化预设：sandbox_mode = "workspace-write"，approval_policy = "on-request"。
如果你需要让 Codex 同时跨多个目录工作，可以用 writable roots 扩展它可写入的位置，而不必完全去掉沙箱。如果你需要更宽或更窄的信任边界，优先调整默认的沙箱模式与审批策略，而不是依赖临时例外。
如果你希望复用一组可重复使用的权限设置，可以把 default_permissions 指向某个命名权限档案，再通过 [permissions.<name>.filesystem] 或 [permissions.<name>.network] 定义规则。托管网络权限则使用 [permissions.<name>.network.domains] 和 [permissions.<name>.network.unix_sockets] 这样的 map table 来配置域名与 Unix socket 访问策略。
当某个工作流只需要一个特定例外时，请使用规则。规则允许你针对沙箱外的命令前缀设置 allow、prompt 或 forbid，这通常比直接扩大整体访问范围更合适。若想看 Codex App 中审批与沙箱行为的更高层说明，可参见 Codex App 功能；若想看 IDE 专用设置入口，可参见 Codex IDE 扩展设置。
平台相关细节见各平台专门文档。关于原生 Windows 的设置、行为与故障排查，请参见 Windows。关于组织级别的沙箱与审批要求，请参见 智能体审批与安全。