Sandbox 是让 Codex 可以自主行动、同时不获得你机器 unrestricted access 的边界。当 Codex 在 Codex app、IDE extension 或 CLI 中运行 local commands 时，这些 commands 会在受约束的环境中运行，而不是默认拥有完整访问权限。
这个环境定义 Codex 可以自行做什么，例如它可以修改哪些文件，以及 commands 是否可以使用 network。当任务留在这些边界内时，Codex 可以继续推进而不必停下来请求确认。当它需要越过边界时，Codex 会回退到 approval flow。
Sandboxing 和 approvals 是协同工作的不同控制。Sandbox 定义技术边界；approval policy 决定 Codex 何时必须在越过边界前停下来询问。
Sandbox 做什么
Sandbox 适用于 spawned commands，而不仅仅适用于 Codex 内置的 file operations。如果 Codex 运行 git、package managers 或 test runners 等 tools，这些 commands 会继承相同的 sandbox boundaries。
Codex 在每个 OS 上使用 platform-native enforcement。macOS、Linux、WSL2 和 native Windows 的实现有所不同，但跨 surfaces 的思路相同：给 agent 一个有边界的工作场所，让 routine tasks 可以在清晰限制内自主运行。
为什么重要
Sandbox 会减少 approval fatigue。Codex 不必要求你确认每一个 low-risk command，而是可以在你已经批准的边界内读取文件、进行 edits，并运行 routine project commands。
它也为 agentic work 提供更清晰的 trust model。你信任的不只是 agent 的意图，也信任 agent 正在被强制限制的范围内运行。这样更容易让 Codex 独立工作，同时仍然知道它何时会停下来请求帮助。
Getting started
当你使用 default permissions mode 时，Codex 会自动应用 sandboxing。
Prerequisites
在 macOS 上，sandboxing 会使用内置 Seatbelt framework 开箱即用。
在 Windows 上，当你在 PowerShell 中运行时，Codex 使用 native Windows sandbox ；当你在 WSL2 中运行时，Codex 使用 Linux sandbox implementation。
在 Linux 和 WSL2 上，请先使用 package manager 安装 bubblewrap：
sudo apt install bubblewrapsudo dnf install bubblewrapCodex 会使用它在 PATH 上找到的第一个 bwrap executable。如果没有可用的 bwrap executable，Codex 会回退到 bundled helper，但该 helper 要求支持 unprivileged user namespace creation。安装发行版提供 bwrap 的 package 可以让这个 setup 更可靠。
当 bwrap 缺失，或 helper 无法创建所需 user namespace 时，Codex 会显示 startup warning。在限制这一 AppArmor setting 的发行版上，建议加载 bwrap AppArmor profile，让 bwrap 在不全局禁用限制的情况下继续工作。
Ubuntu AppArmor note：在 Ubuntu 25.04 上，从 Ubuntu package repository 安装 bubblewrap 应该无需额外 AppArmor setup 即可工作。bwrap-userns-restrict profile 随 apparmor package 提供，路径是 /etc/apparmor.d/bwrap-userns-restrict。
在 Ubuntu 24.04 上，即使安装了 bubblewrap，Codex 仍可能 warning 说无法创建所需 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-restrictapparmor_parser -r 会把 profile 加载进 kernel，无需 reboot。你也可以 reload 所有 AppArmor profiles：
sudo systemctl reload apparmor.service如果该 profile 不可用，或无法解决问题，可以用下面的命令禁用 AppArmor unprivileged user namespace restriction：
sudo sysctl -w kernel.apparmor_restrict_unprivileged_userns=0如何控制 sandboxing
大多数人会从产品中的 permissions controls 开始。
在 Codex app 和 IDE 中，你可以从 composer 或 chat input 下方的 permissions selector 选择 mode。该 selector 让你可以依赖 Codex default permissions、切换到 full access，或使用自定义 configuration。
Default permissions
Codex 可以读取并编辑 current workspace 中的文件，并运行 routine local commands。它会在使用 internet 或越过 workspace boundary 前询问。
在 CLI 中，使用 /permissions 在 session 期间切换 modes。
配置默认值
如果希望 Codex 每次都以相同行为启动，请使用 custom configuration。Codex 会把这些 defaults 存在 config.toml，也就是它的 local settings file。 Config basics 解释其工作方式， Configuration reference 记录 sandbox_mode、approval_policy、approvals_reviewer 和 sandbox_workspace_write.writable_roots 的精确 keys。使用这些 settings 来决定 Codex 默认获得多少 autonomy、可以写入哪些 directories、何时应该暂停等待 approval，以及由谁 review eligible approval requests。
从 high level 看，常见 sandbox modes 包括：
read-only：Codex 可以 inspect files，但不能在没有 approval 的情况下编辑文件或运行 commands。
workspace-write：Codex 可以读取文件、在 workspace 内编辑，并在该边界内运行 routine local commands。这是 local work 的默认 low-friction mode。
danger-full-access：Codex 在没有 sandbox restrictions 的情况下运行。这会移除 filesystem 和 network boundaries，只应在你希望 Codex 以 full access 行动时使用。
常见 approval policies 包括：
untrusted：Codex 会在运行不属于 trusted set 的 commands 前询问。
on-request：Codex 默认在 sandbox 内工作，并在需要越过该边界时询问。
never：Codex 不会因为 approval prompts 停下来。
当 approvals 是 interactive 时，你还可以通过 approvals_reviewer 选择由谁 review：
user：approval prompts 会呈现给 user。这是默认值。
auto_review：eligible approval prompts 会进入 reviewer agent（参见 Auto-review ）。
Full access 指同时使用 sandbox_mode = "danger-full-access" 和 approval_policy = "never"。相比之下，较低风险的 local automation preset 是 sandbox_mode = "workspace-write" 搭配 approval_policy = "on-request"，或匹配的 CLI flags --sandbox workspace-write --ask-for-approval on-request。然后你可以保留 approvals_reviewer = "user" 进行 manual approvals，或设置 approvals_reviewer = "auto_review" 进行 automatic approval review。
如果需要 Codex 跨多个 directory 工作，writable roots 可以扩展它能修改的位置，而不必完全移除 sandbox。如果需要更宽或更窄的 trust boundary，请调整默认 sandbox mode 和 approval policy，而不是依赖一次性的 exceptions。
当 workflow 需要某个特定 exception 时，请使用 rules 。Rules 让你可以在 sandbox 外 allow、prompt 或 forbid command prefixes，这通常比广泛扩大 access 更合适。关于 app 中 approvals 和 sandbox behavior 的 high-level overview，请参见 Codex app features ；关于 IDE-specific settings entry points，请参见 Codex IDE extension settings 。
Automatic review 在可用时不会改变 sandbox boundary。它只是该边界上 approval requests 的一种可能 approvals_reviewer，例如 sandbox escalations、blocked network access，或仍然需要 approval 的 side-effecting tool calls。已经被 sandbox 允许的 actions 会直接运行，无需额外 review。关于 reviewer lifecycle、trigger types、denial semantics 和 configuration details，请参见 Auto-review 。
Platform details 位于 platform-specific docs。关于 native Windows setup、behavior 和 troubleshooting，请参见 Windows 。关于 sandboxing 和 approvals 的 admin requirements 与 organization-level constraints，请参见 Agent approvals & security 。