古法编程

OpenAI Codex 的 sandbox 用来限制命令、文件和网络访问，避免默认获得整机权限；当任务留在边界内时可自动继续，超出边界时才会进入审批流程。你可以在 Codex app、IDE extension 和 CLI 里切换权限模式，或在 config.toml 里配置 sandbox_mode、approval_policy、approvals_reviewer 和 sandbox_workspace_write.writable_roots 来固定默认行为。

OpenAI Codex Sandbox 沙箱与权限控制

OpenAI Codex 的 sandbox 负责划定边界，让编码代理在不暴露完整机器权限的情况下自动执行任务。它适用于 Codex app、IDE extension 和 CLI 中运行的本地命令。

当任务仍在沙箱允许范围内，Codex 可以继续读文件、改文件、运行常规项目命令，不必每一步都确认；一旦需要越过边界，就会回退到审批流程。

sandboxing 和 approvals 是两套不同的控制：

  • sandbox 决定技术边界。
  • approval policy 决定 Codex 什么时候必须停下来请求确认。

sandbox 会做什么

sandbox 作用于启动出来的命令，不只是 Codex 自带的文件操作。也就是说，如果 Codex 调用 git、包管理器或测试运行器，这些命令同样会继承相同的 sandbox 限制。

Codex 会按平台使用原生能力实现这套限制。macOS、Linux、WSL2 和原生 Windows 的实现不同，但目标一致：给 agent 一个有边界的工作区，让常见任务可以在清晰限制内自动完成。

为什么要用 sandbox

sandbox 的主要作用是减少审批疲劳。Codex 不需要为每个低风险命令都问你一次，而是可以在你已经批准的边界内继续读取文件、编辑代码、运行常规命令。

它也让 agentic 工作的信任模型更清楚。你信任的不只是 Codex 的意图，还包括它确实被限制在强制执行的边界里。这样既能让 Codex 独立工作，也知道它什么时候会停下来求助。

怎么开始使用 sandbox

默认 permissions mode 下，Codex 会自动应用 sandboxing。

前置条件

在 macOS 上，sandboxing 默认可用，依赖系统自带的 Seatbelt framework。

在 Windows 上，Codex 在 PowerShell 中运行时使用原生 Windows sandbox；在 WSL2 中运行时使用 Linux sandbox 实现。

在 Linux 和 WSL2 上，先用包管理器安装 bubblewrap：

Ubuntu / Debian 

sudo apt install bubblewrap

Fedora 

sudo dnf install bubblewrap

Codex 会使用 PATH 中找到的第一个 bwrap 可执行文件。如果系统里没有 bwrap，Codex 会回退到内置 helper，但这个 helper 需要支持创建 unprivileged user namespace。直接安装发行版提供的 bwrap 包，配置会更稳定。

如果缺少 bwrap，或者 helper 不能创建所需的 user namespace，Codex 会在启动时给出警告。在某些发行版上，AppArmor 会限制这一点；这种情况下，优先加载 bwrap 的 AppArmor profile，这样可以在不全局关闭限制的前提下继续使用。

Ubuntu AppArmor 提示： 在 Ubuntu 25.04 上，从 Ubuntu 软件仓库安装 bubblewrap 一般就够了，不需要额外的 AppArmor 配置。bwrap-userns-restrict profile 随 apparmor 包提供，路径是 /etc/apparmor.d/bwrap-userns-restrict。

在 Ubuntu 24.04 上，即使装了 bubblewrap，Codex 仍可能提示无法创建所需的 user namespace。可以复制并加载额外 profile：

sudo apt update
sudo apt install apparmor-profiles apparmor-utils
sudo install -m 0644 \
  /usr/share/apparmor/extra-profiles/bwrap-userns-restrict \
  /etc/apparmor.d/bwrap-userns-restrict
sudo apparmor_parser -r /etc/apparmor.d/bwrap-userns-restrict

apparmor_parser -r 会把 profile 加载进内核，不用重启。你也可以重新加载全部 AppArmor profiles：

sudo systemctl reload apparmor.service

如果该 profile 不可用，或者加载后问题仍然存在，可以关闭 AppArmor 对 unprivileged user namespace 的限制：

sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0

怎么控制 sandbox

大多数人先在产品里的 permissions controls 里切换模式。

在 Codex app 和 IDE 中，可以在 composer 或 chat 输入框下方的 permissions selector 里选择模式。这里可以使用 Codex 的默认权限、切换到 full access，或者使用自定义配置。

在 CLI 中，可以在会话期间用 /permissions 切换模式。

怎么配置默认值

如果你希望 Codex 每次启动都用同样的行为，可以使用自定义配置。Codex 会把这些默认值保存在本地设置文件 config.toml 中。Config basics 说明了它的工作方式，Configuration reference 则列出了 sandbox_mode、approval_policy、approvals_reviewer 和 sandbox_workspace_write.writable_roots 的准确键名。

这些设置分别用来决定：

  • Codex 默认获得多少自主权限。
  • 它可以写入哪些目录。
  • 什么时候必须暂停并请求审批。
  • 谁来审核符合条件的审批请求。

常见的 sandbox modes 有：

  • read-only：Codex 可以查看文件，但不能编辑文件，也不能在没有审批的情况下运行命令。
  • workspace-write：Codex 可以读取文件，在 workspace 内编辑，并在这个边界内运行常规本地命令。这是本地工作里默认低摩擦的模式。
  • danger-full-access：Codex 不受 sandbox 限制运行。它会取消文件系统和网络边界，只适合你明确希望 Codex 获得完整访问时使用。

常见的 approval policies 有：

  • untrusted：Codex 会在运行不属于受信任集合的命令前请求确认。
  • on-request：Codex 默认在 sandbox 内工作，需要越界时才会请求审批。
  • never：Codex 不会停下来显示审批提示。

如果审批是交互式的，还可以用 approvals_reviewer 选择谁来审核：

  • user：审批提示直接显示给用户。默认值。
  • auto_review：符合条件的审批请求会交给 reviewer agent 处理，见 Auto-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" 走自动审核。

如果你需要 Codex 同时处理多个目录，可以用 writable roots 扩展它可修改的位置，而不是完全移除 sandbox。若你需要更宽或更窄的信任边界，优先调整默认 sandbox mode 和 approval policy，不要依赖一次性的例外。

当某个工作流只需要特定例外时，可以用 rules。rules 可以允许、提示或禁止 sandbox 外的命令前缀，通常比直接扩大访问范围更合适。关于 app 里的 approvals 和 sandbox 行为总览，可参考 Codex app features；IDE 专属设置入口见 Codex IDE extension settings。

自动审核在可用时，不会改变 sandbox 边界。它只是边界上的一种 approvals_reviewer，适用于 sandbox 升级、网络访问被阻止、或者仍需审批的有副作用工具调用。已经在 sandbox 内被允许的动作，不会因为自动审核而额外复核。关于 reviewer 生命周期、触发类型、拒绝语义和配置细节，见 Auto-review。

平台级细节放在各平台文档里。原生 Windows 的安装、行为和排查见 Windows。管理员要求和组织级 sandbox/approval 约束见 Agent approvals & security。

常见问题

OpenAI Codex 的 sandbox 和 approval policy 有什么区别？

sandbox 负责技术边界，比如文件、目录和网络访问；approval policy 决定 Codex 在什么时候必须停下来请求确认。两者会一起工作，但控制的层面不同。

OpenAI Codex 在 Linux 和 WSL2 上为什么要装 bubblewrap？

Codex 在 Linux 和 WSL2 上会依赖 bwrap 来实现 sandbox。系统里没有 bwrap 时，Codex 可能回退到内置 helper，但这个 helper 需要支持 unprivileged user namespace，所以安装发行版提供的 bubblewrap 更稳定。

Codex 为什么会提示无法创建 user namespace？

常见原因是系统没有正确提供 bwrap，或者 AppArmor 限制了 unprivileged user namespace。Ubuntu 24.04 可以尝试安装并加载 bwrap-userns-restrict profile；如果仍无效，再考虑关闭相关 sysctl 限制。