沙箱
沙箱是代理能够自主执行操作、同时不会获得对你的计算机不受限制访问权限的边界。当本地聊天在 ChatGPT desktop app、Codex CLI 或 IDE extension 中运行命令时，这些命令会在受限环境中运行，而不是默认获得完整访问权限。
该环境定义了代理可以自行执行的操作，例如可以修改哪些文件，以及命令是否可以使用网络。当任务处于这些边界之内时，代理可以持续推进，而无需停下来请求确认。当它需要越过这些边界时，审批流程会接管。
沙箱和审批是协同工作的两种不同控制机制。沙箱定义技术边界，审批策略决定代理何时必须停下来，并在越过边界前请求许可。
沙箱适用于生成的命令，而不仅仅是内置的文件操作。如果代理运行 git、包管理器或测试运行器等工具，这些命令会继承相同的沙箱边界。
Codex 在每种操作系统上都使用平台原生的强制执行机制。macOS、Linux、WSL2 和原生 Windows 的实现各不相同，但在不同界面中理念相同：为代理提供一个边界明确的工作场所，使例行任务能够在清晰的限制内自主运行。
为什么这很重要
Section titled “为什么这很重要”沙箱可以减少审批疲劳。代理无需让你确认每条低风险命令，而是可以在你已经批准的边界内读取文件、进行编辑并运行例行项目命令。
它还为代理式工作提供了更清晰的信任模型。你信任的不只是代理的意图，也包括代理确实在强制执行的限制内运行。这样，你可以更放心地让代理独立工作，同时仍然清楚它何时会停止并请求帮助。
默认权限模式会自动应用沙箱。
在 macOS 上，沙箱使用内置的 Seatbelt 框架即可开箱即用。
在 Windows 上，当你在 PowerShell 中运行时，Codex 使用原生的 Windows sandbox；当你在 WSL2 中运行时，Codex 使用 Linux 沙箱实现。
在 Linux 和 WSL2 上，请先使用包管理器安装 bubblewrap：
Ubuntu/Debian：
sudo apt install bubblewrapFedora：
sudo dnf install bubblewrapCodex 使用在 PATH 中找到的第一个 bwrap 可执行文件。如果找不到 bwrap 可执行文件，Codex 会回退到随附的辅助程序，但该辅助程序要求支持创建非特权用户命名空间。安装提供 bwrap 的发行版软件包可以让此设置更加可靠。
当缺少 bwrap，或辅助程序无法创建所需的用户命名空间时，Codex 会在启动时发出警告。对于限制此 AppArmor 设置的发行版，建议加载 bwrap AppArmor 配置文件，以便 bwrap 能够继续运行，而无需全局禁用该限制。
Ubuntu AppArmor 注意事项： 在 Ubuntu 25.04 上，从 Ubuntu 的软件包仓库安装 bubblewrap 后，应该无需额外的 AppArmor 设置即可运行。bwrap-userns-restrict 配置文件随 apparmor 软件包提供，位于 /etc/apparmor.d/bwrap-userns-restrict。
在 Ubuntu 24.04 上，即使安装了 bubblewrap，Codex 仍可能警告无法创建所需的用户命名空间。请复制并加载额外的配置文件：
sudo apt updatesudo apt install apparmor-profiles apparmor-utilssudo install -m 0644 \ /usr/share/apparmor/extra-profiles/bwrap-userns-restrict \ /etc/apparmor.d/bwrap-userns-restrictsudo apparmor_parser -r /etc/apparmor.d/bwrap-userns-restrictapparmor_parser -r 会将配置文件加载到内核中，无需重启。你也可以重新加载所有 AppArmor 配置文件：
sudo systemctl reload apparmor.service如果该配置文件不可用，或无法解决问题，你可以使用以下命令禁用 AppArmor 对非特权用户命名空间的限制：
sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0权限的工作方式
Section titled “权限的工作方式”使用对应界面的权限控制，调整 Codex 处理本地操作的方式。
审批决定 Codex 何时会在执行操作前暂停，而沙箱决定命令可以访问哪些文件和网络资源。当审批提供不同范围（例如批准一次或批准整个会话）时，请选择能够让任务继续的最小范围。将项目边界作为默认范围；对于不相关的代码仓库，请使用独立的项目或工作树，而不是扩大跨仓库访问权限。
在 ChatGPT desktop app 中，使用输入框下方的权限控制。根据你的配置，菜单可能包含 Ask for approval、用于符合条件的审批请求的 Approve for me、Full access，以及命名或自定义的权限配置文件。
配置默认设置
Section titled “配置默认设置”如果希望每次开始时都使用相同的行为，请在 config.toml 中设置默认值。Config basics 介绍其工作方式，Configuration reference 记录了 sandbox_mode、approval_policy、approvals_reviewer 和 sandbox_workspace_write.writable_roots 的确切键名。使用这些设置来决定代理默认获得多少自主权、可以写入哪些目录、何时应暂停并请求审批，以及由谁审查符合条件的审批请求。
常见的沙箱模式包括：
read-only：代理可以检查文件，但无法编辑文件或运行命令，除非获得批准。workspace-write：代理可以读取文件、在工作区内编辑文件，并在该边界内运行例行本地命令。这是本地工作默认的低摩擦模式。danger-full-access：代理运行时不受沙箱限制。此模式会移除文件系统和网络边界，仅应在你希望代理获得完整访问权限时使用。
常见的审批策略包括：
untrusted：代理在运行不属于其信任集合的命令前请求许可。on-request：代理默认在沙箱内工作，需要越过边界时请求许可。never：代理不会因审批提示而停止。
当审批采用交互方式时，你还可以通过 approvals_reviewer 选择由谁进行审查：
user：审批提示显示给用户。这是默认值。auto_review：符合条件的审批提示会发送给审查代理（请参阅 automatic review）。
完整访问权限意味着同时使用 sandbox_mode = "danger-full-access" 和 approval_policy = "never"。相比之下，低风险的本地自动化预设是将 sandbox_mode = "workspace-write" 与 approval_policy = "on-request" 搭配使用，或使用对应的 CLI 标志 --sandbox workspace-write --ask-for-approval on-request。随后，你可以保留 approvals_reviewer = "user" 进行手动审批，也可以设置 approvals_reviewer = "auto_review" 进行自动审批审查。
如果需要代理跨多个目录工作，可通过可写根目录扩展其能够修改的位置，而无需完全移除沙箱。如果需要更宽或更窄的信任边界，请调整默认沙箱模式和审批策略，而不是依赖一次性例外。
当工作流需要特定例外时，请使用 rules。规则可以允许、提示或禁止沙箱之外的命令前缀，这通常比广泛扩大访问权限更合适。有关 IDE 特定设置的入口，请参阅 Codex IDE extension settings。
自动审查（如果可用）不会改变沙箱边界。它只是审批请求在该边界上的一种 approvals_reviewer，适用于沙箱升级、网络访问受阻，或仍需审批的会产生副作用的工具调用等情况。在沙箱内已经允许的操作无需额外审查。有关审查流程、触发类型、拒绝语义和配置详情，请参阅 automatic review。
平台详情请参阅特定平台的文档。有关原生 Windows 的设置、行为和故障排除，请参阅 Windows。有关沙箱和审批的管理员要求及组织级限制，请参阅 Agent approvals & security。