OpenAI Codex 沙箱与审批怎么配？让 AI 安全动手的双层防线新手指南

预计阅读 18 分钟 ｜ 目标：用新手能理解的方式讲清 OpenAI Codex 的沙箱（sandbox）与审批（approval）两层防线，看完知道默认配置安不安全、自己该用哪种组合、问得太频繁怎么调、出事了怎么回滚。

先看一个场景。你让 Codex 帮你清理项目里的临时文件，它生成了一条命令准备执行。如果这条命令试图删到工作区外的目录、或者要往 .git/ 里写东西，会发生两件事：第一，操作系统层的沙箱在命令真正执行前就把越界的部分拦下——这不是 AI「答应你不乱删」，是系统在执行入口直接拒绝；第二，对于那些沙箱允许、但风险够高的动作（比如要联网、要写工作区外），审批会停下来弹一句问你要不要放行。一条危险操作，先撞沙箱这道围栏，再过审批这道门铃——这就是 Codex 安全模型的全部骨架。

先别急着背配置项。你不需要先懂源码，也不需要一次记住所有参数；这篇只做一件事：把沙箱（AI 技术上能碰什么）和审批（AI 越界前问不问你）这两层拆开讲透，再给你一个能动手的最小安全配置。

30 秒答疑：先把结论拿走

如果你只想快速判断 OpenAI Codex 的沙箱与审批怎么配，一句话结论是：版本控制目录用默认的 Auto 预设（沙箱 workspace-write + 审批 on-request）就够安全，配合任务前 git commit 一次，绝大多数新手不用动任何配置。

下面这张表帮你对号入座：

• 这东西是干啥的：两层安全旋钮——沙箱管「AI 技术上能不能做」，审批管「AI 做之前要不要问你」。
• 新手先看什么：先理解「为什么要分两层」，而不是先背 config.toml 字段。
• 最小上手动作：什么都不配，直接 codex，让它在版本控制目录用默认 Auto 预设。
• 最常见错误：嫌审批烦就直接切 approval = never——等于把保护层整个关掉。

🔥 翔宇判断：很多新手第一反应是「怎么让 Codex 别老问我」，于是上来就搜怎么关审批。这恰恰把顺序搞反了。审批弹得勤，说明沙箱边界和你的工作流不匹配——正确做法是调沙箱可写范围，而不是关掉问询。关审批省下的那几秒，可能换来一次 git reset 都救不回的事故。

一、用一个比喻讲清楚 Codex 的沙箱与审批

你可能遇到的问题是：官方文档里 workspace-write、on-request、danger-full-access 每个词都认识，但放一起不知道到底在控制什么。先用比喻建立整体感。

把 Codex 让 AI 干活想成请装修师傅进你家施工：

• 沙箱（sandbox）= 圈定的施工区域。你先用警戒线圈出客厅，师傅只能在客厅动工，不能进卧室、不能拆承重墙。这是「技术上能不能做」的边界。
• 审批（approval）= 哪些动作要先喊你签字。师傅在客厅刷墙可以自己来，但要砸墙、要往外墙打孔、要叫外援进场，必须先问你一句。这是「做之前要不要确认」的开关。

💡 通俗讲：沙箱是「物理围栏」，审批是「叫你确认的门铃」。围栏决定 AI 进不进得去某块地方，门铃决定 AI 跨界前响不响。两者管的事不一样，所以是两个独立旋钮。

OpenAI 官方把这套机制定义为「two layers that work together」（协同工作的两层），并明确划分：沙箱定义技术边界，审批策略决定何时必须停下来问你。理解了「围栏 + 门铃」这个画面，后面所有配置都只是在调围栏多大、门铃在什么时候响。

第一次学不用追求完整理解。你只需要能向别人复述三句话：沙箱限制 AI 能碰哪些文件和网络；审批决定 AI 跨界前问不问你；默认组合（workspace-write + on-request）对新手已经够安全。

把沙箱想成圈定施工区域的警戒线、把审批想成动手前喊你签字的门铃——围栏管 AI 进不进得去，门铃管 AI 跨界前响不响。

二、为什么新手也需要懂这两层

新手常见误区是：把沙箱与审批当成专家才需要的高级功能，默认能跑就不管。实际上越是新手越该懂——因为新手最容易在「让 AI 自动干活」时踩到误删、误改、误推的坑。

懂这两层至少有三个好处。第一，你能判断 AI 卡在哪一层：是沙箱拦住了（提示没权限写某文件），还是审批在等你点头。第二，出事时你知道是配置太宽还是太严，而不是一律怪「模型不行」。第三，你能按任务风险选组合：审查陌生代码用 read-only，日常开发用默认，自动化批处理才考虑放宽。

还有一层容易被忽略的好处：懂边界能让你更敢放手用。当你确认 AI 只能在工作区里写、跨界一定会问你，你就敢把一整个重构任务交给它，而不是每一步都盯着——这正是沙箱设计的初衷：减少「审批疲劳」，让低风险动作自动跑，把你的注意力留给真正该确认的跨界操作。

⚠️ 常见踩坑：不少人第一次用 Codex，看到一直弹审批就烦躁，直接把 approval 切成 never 图清净。结果某次 AI 跑了个带 rm 的命令，没有任何确认就执行了。这类事故的根因不是模型坏，而是把「保护层」当成了「打扰」关掉。保留确认点，是新手阶段最低成本的安全垫。

三、Codex 在哪里跑，沙箱就不一样

讲具体模式前先澄清一个新手常困惑的点：Codex 有云端（cloud）和本地（CLI / IDE 扩展 / 桌面 App）两套运行环境，沙箱机制不完全一样。

• Codex 云端：跑在 OpenAI 托管的隔离容器里，碰不到你的本机或无关数据。它用「两阶段」运行模型——准备阶段（setup）可以联网装依赖，之后的代理执行阶段默认离线，除非你为该环境显式开启联网。为云环境配置的密钥只在准备阶段可用，代理阶段开始前会被移除。
• Codex 本地（CLI / IDE / App）：用操作系统级机制强制沙箱，默认不能联网、写权限限制在当前工作区。你可以按风险偏好自定义沙箱、审批和网络设置。本文讲的沙箱模式与审批策略，主要针对这套本地环境——也是新手最常用的。

💡 通俗讲：云端是「在别人家的隔离房间干活，弄坏了不影响你」，本地是「在你自己家干活，所以要靠围栏和门铃保护你的东西」。

在动手翻具体模式前，先把两层防线管的事并排放一起看一眼。这张表是后面所有配置的总纲——记住「左边管能不能、右边管问不问」，你看任何一份 config.toml 都不会再把两层搞混：

两层正交（互不替代）是关键：沙箱再严，也不替你做「这步要不要确认」的判断；审批再勤，也不替你限制 AI 技术上能碰的范围。所以 Codex 给了你两个独立旋钮，而不是一个。下面两节分别拆开这两列。

四、沙箱三种模式：AI 技术上能碰什么

沙箱模式决定 AI「能不能技术上做某件事」。Codex 本地有三种主要模式，从严到松：

三种沙箱模式从严到松：只读 → 工作区可写（默认）→ 危险全访问，锁从闭合到敞开对应 AI 可写范围逐级放大。

注意 danger-full-access 名字里的 danger- 前缀——这是 OpenAI 故意留的提醒：这是异常配置，不是日常选项。新手绝大多数时候用默认 workspace-write 就好。

workspace-write 模式下，工作区到底包含什么

这是新手最容易误解的地方，讲清楚：

• 工作区默认包含：当前目录 + /tmp 这类临时目录（官方明示是「包含」而非排除）。你可以用 /status 命令查当前工作区到底有哪些目录。
• 工作区内仍然只读的保护路径（递归保护，目录下全部只读）：.git/（保护 git 历史和提交配置）、.codex/（保护 Codex 自己的安全配置）、.agents/（保护代理配置）。

这几个只读保护路径背后是同一条设计原则：即使在可写模式下，也不让 AI 碰能改变它自身行为或抹掉你退路的东西。.git/ 只读意味着 AI 不能偷偷改你的提交历史或注入 git 钩子；.codex/ 只读意味着 AI 不能改自己的安全配置把围栏放大；.agents/ 只读意味着代理配置不被 AI 自行篡改。所以你会看到 git commit 这类要写 .git/ 的操作往往需要越过只读边界、触发审批——不是 Codex 多事，是它在守住「不让 AI 篡改版本历史」这条底线。

五、审批三种策略（加一种精细策略）：AI 跨界前问不问你

审批策略决定 AI「做之前要不要停下来问你」。三种主要策略：

审批四档决定 AI 跨界前问不问你：不信任逐条问、按需默认跨界才问、永不弹窗自动拒、精细策略按类别开关控制。

关于 never 有个关键认知：never 可以和任意沙箱模式组合，它的含义是「不弹窗确认」而不是「全部允许」。在 never 下，任何本来需要审批的动作（比如某个 MCP 工具申请批准）会被自动拒绝而不是放行。所以 never + read-only 是合法且安全的组合（只读非交互，常用于 CI 拉代码做检查）。

💡 通俗讲：never 不是「全放行」，是「不打扰你，该拒的自动拒」。真正「全放行」要靠 danger-full-access 把围栏拆了才行。

除了这三种，approval_policy 还接受第四种精细形式 granular——官方把它定位成 never（全关）和 on-request（一概问）之间的折中（a middle ground）：保留某些类别的审批问询、自动拒绝其余类别。granular 覆盖五个审批类别，每个用一个布尔开关控制，true = 该类提示仍然浮现给你（保留交互），false = 该类提示被自动拒绝（auto-reject）。五个类别按官方定义是：沙箱升级（sandbox_approval）、execpolicy 规则命中（rules）、MCP 提示（mcp_elicitations）、request_permissions 工具发起的提示（request_permissions）、技能脚本审批（skill_approval）。写进 config.toml 长这样（官方文档自带这段示例，可直接照抄再按需改 true/false）：

approval_policy = { granular = {
  sandbox_approval = true,      # 沙箱升级仍弹给我确认
  rules = true,                 # 规则命中仍弹给我确认
  mcp_elicitations = true,      # MCP 工具的批准请求仍弹给我
  request_permissions = false,  # request_permissions 提示自动拒
  skill_approval = false        # 技能脚本审批自动拒
} }

granular 是「问得太多」和「一刀切全关」之间的正解：只对真正危险的类别（沙箱升级、规则命中）保留确认，其余自动拒绝。新手暂时不用碰，但要知道它存在——等你用熟了会发现，它比直接切 never 安全得多，也比默认 on-request 顺手。

六、把两层拼起来：官方常用组合

沙箱和审批正交，理论上能组合出多种配置。官方对默认 Auto 预设的描述是：在 --sandbox workspace-write --ask-for-approval on-request 下，「Codex can read files, make edits, and run commands in the working directory automatically」（Codex 可以读文件、改文件、在工作目录里自动跑命令），只有要改工作区外或要联网时才问你。下面是官方给的常用组合，照着选即可：

落到配置文件 ~/.codex/config.toml，最常见的两段长这样：

# 日常开发默认（等价于 Auto 预设）
approval_policy = "on-request"
sandbox_mode    = "workspace-write"

# 最严格：每条命令都问、只读
approval_policy = "untrusted"
sandbox_mode    = "read-only"

命令行临时指定也可以，不写配置文件：

# 接受默认 Auto
codex

# 显式指定
codex --sandbox workspace-write --ask-for-approval on-request
codex --sandbox read-only --ask-for-approval on-request

⚠️ 常见踩坑：贴配置前先问自己「这段在控制什么」。看到 sandbox_mode 先翻译成「AI 能碰哪些文件、能不能联网」；看到 approval_policy 先翻译成「AI 跨界前问不问我」。没有这句翻译就别直接复制别人的 config.toml——你可能把别人 CI 环境的 never 抄进了自己的开发机。

七、底层怎么实现：操作系统层的硬约束

新手常怀疑：沙箱是不是只是「请 AI 别乱来」的软约束，AI 一句巧妙提示词就绕过去了？答案是：拦得住，因为沙箱是操作系统层的强制约束，对 AI 跑的所有命令（包括 git、包管理器、测试运行器）都生效，不是应用层的口头请求。

不同操作系统的实现机制：

沙箱是操作系统层的硬约束而非 AI 口头承诺：所有命令必须经过系统调用，操作系统在内核层执行前就设卡拦截越界动作。

（想看某条命令在沙箱里会被怎么处理，可以用 codex sandbox macos / codex sandbox linux / codex sandbox windows（也叫 codex debug）本地试跑。OpenAI 还给了一份 Dev Container 安全参考实现，里面预装了 bubblewrap 和基于白名单的出站防火墙。）

💡 通俗讲：系统调用（syscall）是程序向操作系统申请「读文件、写文件、联网」的必经通道。Codex 在这个通道上设卡——AI 想写不该写的文件，操作系统在执行前就拒了。不懂内核也没关系，记住一句话就够：操作系统在动作执行前就拦截，比「让 AI 答应你不乱改」这种口头约束硬得多。

🔥 翔宇判断：这是 Codex 安全模型最值得新手记住的一点。市面上有些工具的「权限控制」其实只是在提示词里写「请不要删除文件」——这种约束一旦模型被绕过就形同虚设。操作系统层的沙箱不一样，它不依赖模型听不听话。理解了这层差别，你就能判断一个 AI 编程工具的安全承诺到底是真硬核还是纸糊的。

（在 Linux 容器如 Docker 里，如果宿主或容器配置挡住了 Codex 需要的命名空间能力，沙箱可能起不来。这时正确做法是让容器本身提供隔离，再在容器内用 danger-full-access 跑——把容器当外层围栏。）

八、4 类身份对号入座：你该用哪套组合

讲完零件，回到最实际的问题：你这类用户该配哪套？按下面四类对号入座。

flowchart TD
  A[你要让 Codex 干什么？] --> B{要不要改文件？}
  B -->|只想读/审查| C[read-only + untrusted]
  B -->|要改代码| D{在什么环境？}
  D -->|自己的开发机| E[workspace-write + on-request 默认]
  D -->|隔离容器/CI 一次性环境| F[danger-full-access + never]
  E --> G{审批弹太多？}
  G -->|是| H[加 writable_roots 或用 granular]
  G -->|否| I[保持默认]

① 完全新手（第一次用 Codex，怕 AI 乱改代码）

• 推荐：默认 Auto（workspace-write + on-request）。
• 为什么：默认配置在版本控制目录里已经够安全，你要做的只是任务前 git commit 一次。先别碰任何配置文件，跑熟「commit → 让 AI 干活 → diff → 合并」这套循环。

② 日常开发者（嫌审批弹窗太频繁，想顺手又安全）

• 推荐：workspace-write + on-request，配 writable_roots 扩可写目录。
• 为什么：频繁弹窗通常是因为你的项目要写工作区外的目录（比如同时改两个仓）。正确做法是把需要的目录显式加进可写范围，而不是关掉审批。

③ 资深 / 自动化使用者（CI、容器、批处理无人值守）

• 推荐：隔离环境里用 danger-full-access + never。
• 为什么：CI 和一次性容器本身就是隔离边界，AI 在里面出错销毁重建即可。这种环境才配得上全自动，且容器要干净、不含密钥。

④ 谨慎审查者（审查陌生代码、敏感系统）

• 推荐：read-only + untrusted。
• 为什么：你的目标是看懂代码而不是改它。只读模式让 AI 碰不了文件，untrusted 让任何命令都先问你，最大限度防止陌生代码里的恶意操作偷跑。

这四类里，新手和谨慎审查者占了大多数真实场景，而这两类用默认或更严的配置就好。真正需要放宽到全自动的只有自动化那一类，而且必须在隔离环境里。一个简单的自检：如果你发现自己想在主力开发机上切全自动，先停下来问问——是不是该把这个任务搬到容器里跑，而不是把开发机的围栏拆掉。

九、翔宇的真实路由：不同项目怎么配 + 受控开网络

这里给一套实操参考，不是让你照抄——按你自己的项目风险调：

• 个人练手项目 / 学习仓库：默认 Auto，任务前 git commit。够了，别折腾配置。
• 有价值的私有项目：默认 Auto，但审批弹出时认真看，尤其是涉及删除、跨目录写、联网的请求。绝不切 never。
• 需要 AI 联网的任务（装依赖、查文档）：在 workspace-write 下显式开网络，而不是切全访问。配置长这样：

[sandbox_workspace_write]
network_access = true

如果想进一步把网络限制在白名单域名，在命令网络已打开的前提下，再开 [features.network_proxy] 把出站流量约束到你配置的策略：

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

域名规则是先白名单（allowlist-first）：精确主机只匹配自己，*.example.com 只匹配子域、不含主域，**.example.com 匹配主域加子域，全局 * 放行任何未被拒的公网主机（视作宽网络访问，能用更窄规则就用窄的），deny 永远优先于 allow。注意 network_proxy 只改变「已开的网络如何被约束」，它本身不打开网络——开关仍是 network_access。开网络后要留意提示注入（prompt injection）风险——AI 可能被网页里的恶意指令带偏，官方建议把网页结果当不可信内容看待。

• 需要写工作区外目录：用 writable_roots 显式加，而不是切全访问：

[sandbox_workspace_write]
writable_roots = ["/path/to/extra/dir"]

• CI / 批处理 / 隔离容器：才用 danger-full-access + never，并且容器本身要是干净、可丢弃、不含密钥的。

⚠️ 常见踩坑（泛化经验）：把所有项目都配成同一套「最省事」组合是常见的错误倾向。开发机和 CI 的风险完全不同，用同一套配置要么平时被审批烦死，要么在重要项目上裸奔。按项目分档配置，比追求「一套配置走天下」稳得多。

十、新手必做：给 Codex 套一层 git 安全网

就算默认配置已经够安全，仍然建议新手养成一套「让 AI 干活前后」的固定动作。这套动作和你用什么沙箱模式无关，是成本最低的安全垫：

1. 任务前建检查点：git add . && git commit -m "before codex"。哪怕只是临时改动，先存一个干净的回退点。
2. 让 Codex 干活：用默认 Auto 预设跑你的任务。
3. 任务后看改动：git diff 通读一遍 Codex 改了什么。不要看「测试过了」就直接合并——测试绿不等于改动符合你的预期。
4. 发现意外改动就回滚：
   • 单文件回滚：git checkout HEAD <file>
   • 全部撤销未提交改动：git reset --hard HEAD~1
   • 部分接受：git add -p 交互式挑选要保留的片段
   • 已经 commit 了：git revert <commit-hash> 创建一个反向提交

⚠️ 常见踩坑：最常见的事故不是 AI 干了坏事，而是用户在脏工作区（有未提交改动）上直接让 Codex 动手，出问题后想回滚才发现连个干净检查点都没有，自己的改动和 AI 的改动混在一起分不开。先 git commit 一次，是预防这类事故的关键一步。官方也明确建议：让 Codex 干活前保持 git status 干净，并优先用基于 diff 的工作流，方便小步回滚。

十一、5 个新手常见坑与正确做法

1. 嫌审批烦直接切 never → 正确：调沙箱可写范围或用 writable_roots/granular，保留审批。
2. 在脏工作区直接让 AI 动手 → 正确：先 git commit 建检查点，再让 Codex 跑。
3. 看测试过了就直接合并 → 正确：先 git diff 通读改动，确认符合预期再合并。
4. 在主力开发机用 danger-full-access → 正确：全访问只在隔离 / 一次性环境用。
5. 抄别人的 config.toml 不看含义 → 正确：先翻译每个字段控制什么，再决定要不要用。

十二、进阶路径与自检清单

默认配置跑顺一两周后，可以按这个顺序往深走：

• 第 1 周：只用默认 Auto，跑熟 git commit → 让 Codex 干活 → git diff → 合并这套循环。
• 第 2 周：开始读审批弹窗到底在问什么——是要写工作区外，还是要联网，理解每次跨界的原因。
• 第 3 周起：按需学 writable_roots（扩可写目录）、granular 审批（按类别精细控制）、network_access（受控开网络）。
• 进阶：了解 auto_review（自动审批复核）和企业级 managed configuration（团队统一安全策略）。

auto_review 值得单独说一句，因为它是「想半自动又不想裸奔」的折中方案。它由 approvals_reviewer 控制：默认 user（审批弹给你），改成 auto_review 后，那些本来要弹给你确认的请求会先交给一个复核代理（reviewer agent）评估。注意它只在审批本来就是交互式时才生效（on-request 或 granular 策略下），而且只评估已经需要审批的动作——沙箱内本就放行的动作不会多走这一步。官方说这个复核代理按一份策略检查四类风险：数据外泄、凭据探测（credential probing）、持久性安全削弱、破坏性动作。处置是分级的——低风险和中风险动作在策略允许时放行，关键风险（critical）直接拒绝，高风险动作要有足够的用户授权且没有命中拒绝规则才放行；连构建提示、复核会话、解析失败这些异常都按「失败即拒」（fail closed）处理。

auto_review 不改变沙箱边界，它只是替你先过一遍审批请求，代价是要多花模型调用、增加用量。新手阶段完全用不上，知道有这么个东西就行；等你真要做半自动流水线时，它比直接切 never 安全得多。这些进阶项（含 granular 字段、auto_review 行为）以官方当前文档为准，本文写作时已逐条核对官方 config-reference 与 agent-approvals-security 页。

发任务前对照勾一遍自检清单：

• [ ] 我知道当前是什么沙箱模式 + 审批策略（不确定就跑 /status 看）。
• [ ] 版本控制目录下用的是默认 Auto（workspace-write + on-request）。
• [ ] 任务前已 git commit 建了检查点。
• [ ] 我没有为了图省事在主力开发机切 never 或 danger-full-access。
• [ ] 需要联网时，我是开 network_access 而不是切全访问。
• [ ] 任务后我会 git diff 看改动再合并。

下一步学什么：3 个答案和导航

最后把 OpenAI Codex 沙箱与审批收成 3 个答案。

第一，这东西是干啥的？两层安全旋钮——沙箱管「AI 技术上能碰什么」（操作系统层强制），审批管「AI 跨界前问不问你」（应用层）。两层协同，让 AI 既能自动干活又不会越界闯祸。

第二，我该怎么配？版本控制目录用默认 Auto（workspace-write + on-request）就够安全，配合任务前 git commit。嫌审批多就扩可写目录或用 granular，别关审批。只有隔离 / 一次性环境才考虑全自动。

第三，我下一步做什么？按 § 十的 git 安全网跑一个真实小任务：先 commit、让 Codex 默认配置干活、git diff 看改动、确认后合并。跑顺再按 § 十二往深学。

同系列下一步：

• OpenAI Codex 完整学习指南：12 个知识点地图 + 该按什么顺序学
• OpenAI Codex 四个入口怎么选？CLI、App、IDE、Cloud 新手对比指南
• OpenAI Codex 提示词怎么写？模糊需求转工程任务的新手完整指南
• OpenAI Codex 上下文工程新手指南：5 层信息栈决定 AI 干对还是干错

• Claude Code 权限管理指南 —— 同类工具的对应专题，对照看更完整。

跨系列参考：

• CLAUDE.md 怎么写？项目记忆文件新手指南（附可抄模板）

外部参考（沙箱、审批策略、配置字段以官方当前文档为准，本文配置字段于 2026 年 6 月逐条核对官方原文）：

• Codex Sandboxing（沙箱机制）
• Agent approvals & security（审批与安全）
• Codex Config Reference（配置字段全表）

给新手的第一条操作建议：第一次配 Codex，什么都别改，直接在一个版本控制的练手项目里跑 codex，让它用默认 Auto 预设。先感受「沙箱内自动干、跨界才问你」是什么体验，再决定要不要调。

第二条建议：把「让 Codex 干活前先 git commit」变成肌肉记忆。这一个动作能挡住新手阶段绝大多数「改坏了回不去」的事故，成本只有一行命令。

第三条建议：审批弹窗别无脑点同意，也别嫌烦关掉。花两秒看它在问什么——要写哪个文件、要不要联网。看懂每次跨界的原因，比任何配置技巧都更能让你安全地用好 Codex。

下一步

• AI 编程实操课：Claude Code + Codex + Agent 工作流，覆盖一人公司、自媒体自动化、AI 副业全场景。237 篇实战教程 + 最佳实践 + 源码包，跟着做就出成果。国内版-FlowUS | 国际版-BMC
• YouTube 频道：翔宇工作流
• 微信公众号：搜索「翔宇工作流」