Codex 沙箱与审批模式怎么选

这篇适合谁、读完能做到什么

这篇适合想在本机用 Codex CLI 或 IDE 扩展跑命令、又担心它动到不该动的文件的人。读完你应该能分清沙箱和审批各管什么，会按场景挑合适的组合，知道 Linux 和 WSL2 上要先装什么，也会用 codex sandbox 先看一条命令在沙箱里会怎样。^[1]^[2]

沙箱和审批是两回事

沙箱是技术边界，决定 Agent 能修改哪些文件、命令能不能用网络。审批策略决定 Agent 在什么时候必须停下来问你，才能越过这条边界。两者配合使用。^[1]

沙箱作用在 Agent 启动的所有命令上，不只限于内置的文件操作。git、包管理器、测试命令这些工具也受同样的边界约束。^[1]

本地运行时，Codex 默认关闭网络访问，并用操作系统强制执行的沙箱，把 Agent 能碰到的范围限制在当前工作区。^[2]

三种沙箱模式

read-only：Agent 可以查看文件，但不能编辑文件，也不能在没有批准的情况下运行命令。^[1]
workspace-write：Agent 可以读文件、在工作区里编辑，并在这个边界内运行常规的本地命令。文档称它是本地工作默认的低摩擦模式。^[1]
danger-full-access：Agent 不受沙箱限制，文件系统和网络边界都被取消。文档说，只有在你确实希望它完全访问时才应使用。^[1]

完全访问的写法是 sandbox_mode 设为 danger-full-access，同时 approval_policy 设为 never。相比之下，风险较低的本地自动化组合是 workspace-write 配合 on-request。^[1]

两种审批策略

on-request：Agent 默认在沙箱里工作，需要越过边界时再询问你。^[1]
never：Agent 不会停下来弹出审批提示。^[1]

旧的 untrusted 已经不再是可选的审批策略。如果配置里还在用它，需要迁移。^[1]

审批由谁来看，由 approvals_reviewer 决定。默认值 user 会把审批弹给你；设为 auto_review 时，符合条件的请求会先交给一个审查 Agent。^[1]

常用组合怎么选

Auto 预设：--sandbox workspace-write --ask-for-approval on-request，也可以什么参数都不加。在这个组合下，Codex 能在工作目录里自动读文件、编辑、运行命令；要编辑工作区外的文件，或访问网络，就需要你批准。^[2]
只读的交互式使用：文档的迁移示例是 sandbox_mode = "read-only" 配合 approval_policy = "on-request"。^[2]
CI 等非交互场景：文档列出的只读模式组合是 --sandbox read-only --ask-for-approval never，只读，从不询问。运行 codex exec 时可以用 --sandbox workspace-write。^[2]
完全访问：--dangerously-bypass-approvals-and-sandbox，别名 --yolo，没有沙箱也没有审批。文档说它不推荐使用。^[2]

Linux 和 WSL2 为什么要先装 bubblewrap

在 Linux 和 WSL2 上，Codex 的沙箱依赖 bwrap（bubblewrap）。先用包管理器装好它：Ubuntu 或 Debian 用 sudo apt install bubblewrap，Fedora 用 sudo dnf install bubblewrap。^[1]

Codex 会使用 PATH 里找到的第一个 bwrap。如果找不到，它会退回到自带的辅助程序，而这个辅助程序需要系统支持非特权用户创建 user namespace。装好发行版自带的 bwrap 包，设置会更可靠。^[1]

如果缺少 bwrap，或者辅助程序无法创建所需的 user namespace，Codex 启动时会给出警告。^[1]

Ubuntu 24.04 的情况比较特殊：装好 bubblewrap 之后，警告仍可能出现。文档的做法是把 /usr/share/apparmor/extra-profiles/bwrap-userns-restrict 复制到 /etc/apparmor.d/bwrap-userns-restrict，再用 sudo apparmor_parser -r /etc/apparmor.d/bwrap-userns-restrict 加载。加载后无需重启。^[1]

macOS 和 Windows 上的情况

macOS 上沙箱开箱即用，用的是系统内置的 Seatbelt 框架。^[1]

Windows 上，在 PowerShell 里运行时用的是原生的 Windows 沙箱；在 WSL2 里运行时，用的是 Linux 沙箱实现。^[1]

试一下沙箱里的命令

codex sandbox 可以让你看一条命令在沙箱里会发生什么。三个平台的写法如下，方括号里的参数都是可选的：^[2]

# macOS
codex sandbox macos [--permissions-profile <name>] [--log-denials] [COMMAND]...
# Linux
codex sandbox linux [--permissions-profile <name>] [COMMAND]...
# Windows
codex sandbox windows [--permissions-profile <name>] [COMMAND]...

网络访问怎么开

workspace-write 模式下，网络访问默认是关闭的。要打开，在配置文件里写：^[2]

[sandbox_workspace_write]
network_access = true

打开网络后，还可以启用 network_proxy 功能，把出站流量限制在你配置的域名规则之内。这个功能默认关闭；它只约束已经开启网络的命令，本身不会授予网络访问。^[2]

域名规则是先允许后限制的白名单模式：精确的主机名只匹配它自己，*.example.com 能匹配 api.example.com 这样的子域名，但不匹配 example.com。deny 总是优先于 allow。^[2]

可写目录里的受保护路径

即使在 workspace-write 模式下，可写根目录里的 .git、.agents、.codex 和 .aws 只要存在，就会被保护为只读，而且保护是递归的。.git 不论是目录还是指向 Git 目录的文件，都受保护。^[2]

网页搜索的几个取值

web_search 默认是 cached，结果来自 OpenAI 维护的网页索引，而不是实时抓取。live 等同于命令行的 --search，会获取实时数据；indexed 让外部访问只在搜索索引放行时才发生；disabled 则关闭网页搜索工具。^[2]

文档提醒，要把网页结果当作不可信内容。使用 --yolo 或其他完全访问的沙箱设置时，网页搜索会默认切到实时结果。提示注入可能让 Agent 去抓取并执行不可信的指令，因此开启网络或网页搜索时要谨慎。^[2]

常见问题

装了 bubblewrap 还是有警告。 先确认 bwrap 在 PATH 里。在 Ubuntu 24.04 上，按上一节加载 bwrap-userns-restrict 配置文件。^[1]

在容器里沙箱不工作。 文档说，如果宿主机或容器的配置阻止了 Codex 需要的 namespace、setuid 的 bwrap 或 seccomp 操作，沙箱就可能不工作。这时应先由容器本身提供隔离，再在容器里用 codex --sandbox danger-full-access 运行。^[2]

限制

danger-full-access 和 --yolo 都没有沙箱保护。文档只建议在确实需要完全访问时使用 danger-full-access，并说明 --yolo 不推荐使用。^[1]^[2]
Dev Container 是一种外层隔离，但如果在容器里用 danger-full-access，恶意项目可以窃取容器内能访问的任何东西，包括 Codex 凭据。文档建议只在可信仓库里这样做。^[2]