沙箱与审批

沙箱是让智能体自主行动而不给它对你机器不受限访问的边界。当本地对话在 ChatGPT 桌面应用、Codex CLI 或 IDE 扩展里运行命令时，这些命令在受约束的环境里运行，而不是默认拥有完全访问权限。这个环境定义了智能体自己能做什么，例如能修改哪些文件、命令是否可以使用网络；任务停留在这些边界之内时，智能体可以不停下来确认继续推进，需要越过边界时由审批流程接管。沙箱和审批是不同的控制，配合工作：沙箱定义技术边界，审批策略决定智能体何时必须停下来询问才能越过它们。

沙箱做什么

沙箱适用于所生成的命令，而不只是内置的文件操作：智能体运行 git、包管理器或测试运行器等工具时，这些命令继承相同的沙箱边界。Codex 在每个操作系统上用平台原生的强制机制：macOS、Linux、WSL2 和原生 Windows 的实现各不相同，思路相同——给智能体一个有界的工作场所，让常规任务在清晰的限制内自主运行。沙箱减少了审批疲劳：智能体可以在你已批准的边界内读文件、做编辑、运行常规项目命令，而不是让你确认每条低风险命令。

默认行为

默认情况下，智能体在网络访问关闭的情况下运行。 本地时，Codex 用操作系统强制的沙箱限制它能触及的东西（通常是当前工作区），再加上控制何时必须停下来询问你的审批策略。在 Auto 预设（如 --sandbox workspace-write --ask-for-approval on-request）下，Codex 可以自动读文件、做编辑、在工作目录里运行命令；它在编辑工作区外的文件，或运行需要网络访问的命令时请求审批。想只聊天或做计划而不做改动，用 /permissions 命令切换到 read-only 模式。Codex 也可以对声明有副作用的应用（连接器）工具调用请求审批，即使该动作不是 shell 命令或文件变更；当工具声明了破坏性标注时，破坏性的应用/MCP 工具调用总是需要审批（除非该工具同时声明了读取标注，读取标注优先）。

不同的运行位置使用不同的沙箱：**Codex 云端（旧版）**在隔离的、OpenAI 管理的容器里运行，使用两阶段运行时模型：设置阶段在智能体阶段之前运行并可以访问网络来安装指定的依赖，然后智能体阶段默认离线运行，除非你启用互联网访问；Codex CLI / IDE 扩展用操作系统级机制强制沙箱策略，默认没有网络访问，写权限限于当前工作区，你可以按风险承受度配置沙箱、审批策略和网络设置。

前提条件

• macOS：沙箱开箱即用，使用内置的 Seatbelt 框架
• Windows：在 PowerShell 里运行时用原生 Windows 沙箱，在 WSL2 里运行时用 Linux 沙箱实现
• Linux 和 WSL2：先用包管理器安装 bubblewrap（Ubuntu/Debian：sudo apt install bubblewrap；Fedora：sudo dnf install bubblewrap）。Codex 使用 PATH 上找到的第一个 bwrap 可执行文件；没有可用的 bwrap 时回退到自带的辅助程序，但它需要支持非特权用户命名空间的创建。bwrap 缺失或辅助程序无法创建所需用户命名空间时，Codex 在启动时显示警告。在限制这项 AppArmor 设置的发行版上，优先加载 bwrap 的 AppArmor 配置，让 bwrap 在不全局禁用该限制的情况下继续工作：Ubuntu 25.04 上从仓库安装 bubblewrap 应当无需额外 AppArmor 设置就能工作；Ubuntu 24.04 上 Codex 仍可能警告无法创建所需的用户命名空间，官方给出安装 apparmor-profiles、apparmor-utils，把 /usr/share/apparmor/extra-profiles/bwrap-userns-restrict 安装到 /etc/apparmor.d/ 并用 apparmor_parser -r 加载的步骤；该配置不可用或不能解决问题时，可以用 sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0 禁用 AppArmor 的非特权用户命名空间限制

网络访问

在桌面应用、Codex CLI 或 IDE 扩展里，默认的 workspace-write 沙箱模式保持网络访问关闭，除非你在配置里启用：

[sandbox_workspace_write]
network_access = true

网络隔离（代理）：网络访问通过适用于命令所生成的脚本、程序和子进程的目标规则控制。命令的网络访问已启用时，打开 network_proxy 特性把该流量约束到你配置的网络策略；单独添加域名规则不会启用代理：

[features.network_proxy]
enabled = true
domains = { "api.openai.com" = "allow", "example.com" = "deny" }

一次性 CLI 会话可以只用布尔简写：

codex \
  -c 'features.network_proxy=true' \
  -c 'sandbox_workspace_write.network_access=true'

这个特性只改变已启用的网络访问如何被强制，它本身不授予网络访问：网络关 + network_proxy 开，网络保持关闭，该特性什么也不做；网络开 + network_proxy 关，网络保持开启且出站不受限；网络开 + network_proxy 开，网络保持开启且出站流量受配置的网络策略约束。代理特性同样适用于权限档案：档案的 network.enabled = true 授予命令网络访问，features.network_proxy = true 激活该档案域名规则的强制。管理员管理的 experimental_network 要求与用户的特性开关是分开的，不会在当前沙箱保持网络关闭时打开网络访问。

网络策略：域名规则以允许列表优先：精确主机只匹配自身；*.example.com 匹配 api.example.com 这样的子域名但不匹配 example.com；**.example.com 同时匹配顶级域名和子域名；全局 * 允许规则匹配任何没被拒绝的公共主机（把 * 当作宽泛的网络访问，尽量用有范围的规则）；deny 总是优先于 allow，全局 * 只对允许规则有效。默认 allow_local_binding = false 会阻止环回、链路本地和私有目标，需要例外时加精确的本地 IP 字面量或 localhost 允许规则。

迁移已退役的 untrusted 审批策略

Codex 不再支持 approval_policy = "untrusted"，保留这个设置可能让客户端无法启动：把它从用户或项目配置、profile 文件、启动脚本和托管默认值里移除。对交互式的只读使用：

sandbox_mode = "read-only"
approval_policy = "on-request"

或运行 codex --sandbox read-only --ask-for-approval on-request。on-request 下，沙箱允许的命令无需审批就能运行、读取可访问的文件，并在启用网络时使用网络。要保留更严格的命令审批规则，省略显式的 approval_policy，并在用户级 ~/.codex/config.toml 里添加项目条目：

[projects."/path/to/project"]
trust_level = "untrusted"

这样命令需要审批，除非执行策略规则允许它；这也会禁用项目本地配置。显式设置 on-request 会覆盖由项目推导的策略；托管的 allowed_approval_policies 必须包含 untrusted 才允许它。

安全监控

官方文档说明，较新的模型在 Codex 和 ChatGPT Work 里带有安全监控：监控异步运行，检测到可能不安全的模型行为时可以暂停任务；暂停可能在触发它的活动之后才到来，监控不取代沙箱、权限或对结果的审查。任务暂停时先阅读通知并（在可用时）审阅发现，确认任务可以安全继续后才恢复。在 Codex CLI 和手机上，完整的发现和恢复不可用，任务会结束；启用零数据保留、修改过的滥用监控或非美国数据驻留时同样如此。安全监控评估任务期间的模型行为，自动审批评审则在需要审批的单个动作运行前评估它们。