权限与沙箱：
放手，但不放任

想象你请了一位装修师傅，只让他翻修厨房：

换成 Codex：

• 沙箱（sandbox）定下技术上的边界：能改哪些文件、命令能不能联网。这是操作系统强制执行的，不靠 Codex 自觉。
• 审批（approval）决定它碰到边界时怎么办：停下来问你，还是交给自动审查，或者根本不问。

边界以内的事，它不打扰你，自己一口气做完；要越过边界，审批这一层接手。官方的说法是：沙箱让它能放手去做日常的事，又不用把整台电脑交给它，还能少弹很多"要不要继续"的确认。

官方的建议是：大多数时候从 Ask for approval 开始。它让 Codex 在当前项目里干活，要越出去之前先停下来。

先在设置里打开，菜单里才有

打开 Settings > General，在 Permissions 下面打开对应的档位。点下面的开关试试：

• 在设置里打开一档，只是让它出现在菜单里，不会替你选中它，也不会改变已经开着的对话。
• 能用哪几档，也看你本机的配置和组织（公司工作区）的要求。组织不允许的档位，在菜单里是灰的。
• 根据配置，菜单里还可能出现命名的"权限配置档"（permission profiles，Beta），第 8 节提一句。

底层是两个设置的组合

App 的三档是给你看的名字。底下其实是两个设置：sandbox_mode（沙箱模式）管边界，approval_policy（审批策略）管什么时候问；Approve for me 还多一个"谁来审"的设置。大致对应关系：

还有一个 read-only（只读）沙箱模式：只能看，不能改。这些名字你现在认得就行，怎么写进配置文件，第 7 课讲。

"交给自动审查"之后是放行还是拒绝，要看审查员对这一步的判断（第 7 节）。表里的结果按官方文档的规则推出，界面和措辞是示意。

画面为教学示意：提交号、测试数量、审查结论和 Codex 说的话都是虚构的；档位名称、哪些动作要批准、审查的状态名称（Reviewing / Approved / Denied）与官方文档一致。

换审批人，不换边界

主代理还在原来的沙箱里，文件和网络的限制一样不少。区别只在于：碰到边界时，请求不送到你面前，而是送给另一个单独的审查代理。它不会替你打开网络、不会扩大可写范围，也不会放松 .git 这些受保护的目录。

在 App 里，审查会作为单独的条目出现在对话里，状态是 Reviewing（审查中）、Approved（通过）、Denied（拒绝）、Aborted（中止）或 Timed out（超时），还可能带上风险等级和"用户是否授权过"的判断。

被拒之后，以及熔断

被拒不是普通的报错。审查员的理由会传回主代理，外加一条更严的指令：不许换个说法、绕个弯去达成同样的结果；只能换一条明显更安全的路，否则就停下来问你。超时单独提示，不算"不安全"的证据，但动作同样不会执行。

为了不让它反复碰壁，还有一个按轮计的"熔断器"：按目前的开源实现，同一轮里连续被拒 3 次，或者最近 50 次审查里被拒满 10 次，这一轮就被中断。只要有一次没被拒，"连续"就重新计数。点下面的动作试试：

每个动作的审查结论是示意，真实结论由审查员按官方策略判断。熔断的数字来自官方文档对"目前开源实现"的描述，以后可能调整。

觉得它判错了：/approve

在输入框里输入 /approve，可以从最近被拒的动作里挑一个，批准它重试一次。这个批准很窄：只对那一个动作、只一次，而且重试时仍然要过审查。审查员会看到你明确批准过，但如果策略规定这类动作用户也不能放行，它还是会拒。

批准时，选最窄的范围

有的批准卡片不只"允许一次"，还会给出更大的范围，比如"这次对话里都允许"。官方建议：选能让任务继续下去的最窄范围。一次就够的，别选整个对话。（下面是示意）

别为了省事把边界拆掉

• 不相关的仓库，分开建项目。官方建议保持项目边界，不要为了跨仓库干活把权限放宽。order-admin 的对话要是去改 ../blog-site，正确做法是给 blog-site 单独建一个项目，或者用 worktree（第 12 课）。反过来，确实相关的两个文件夹（比如网站和它的后端），可以加进同一个项目：项目里附加的每个文件夹它都能读、能改。
• 个别命令要例外，用规则。只想让某一条命令免批准，用 Rules 定向放行，比整个放宽好（第 10 课）。
• 想要更细的边界，用权限配置档 Beta：把"哪些路径能读、能写、不能碰，哪些域名能访问"写成一个命名的策略，比如让 .env 连读都不行。还在开发中，可能会改，本教程暂不展开。

Full access：什么时候可以用

Full access 等于没有沙箱、也从不问你：它不再局限在项目文件夹里，官方提醒这可能造成意外的破坏、丢数据。另外几个容易忽略的后果：

• 联网搜索默认从"缓存"变成"实时"，直接读任意网页，受提示注入的风险更大（第 9 节）。
• 定时任务（第 13 课）在后台跑的时候，改文件、跑命令、联网都不会问任何人。
• 自动审查也帮不上忙：没有边界，就不会产生"要越界"的请求，审查员根本不会被叫到。

官方最佳实践把"还没弄懂流程就给它整台电脑的权限"列为常见错误。文档里比较站得住的放权场景在命令行：你专门搭了一个 Docker 或 Dev Container 容器，在容器里用命令行运行 codex，让容器本身当隔离边界，这时可以加 --sandbox danger-full-access（相当于 Full access，命令行第 14 课讲）。官方也提醒，这种做法只适合可信的仓库。桌面 App 跑在你自己的电脑上，不在容器里，在 App 里选 Full access 并没有这层隔离。

项目信任：陌生仓库先别信

项目里可以有一个 .codex/ 文件夹，放这个项目自己的配置、钩子（hooks）和规则（rules）。为了安全，只有你信任的项目，Codex 才会加载这些项目级的东西。标记为不信任的项目，会跳过项目里的 .codex/ 配置、钩子和规则；你自己的用户级配置照常加载（不信任还可能让命令更常要批准，见本节末尾的旧教程对照）。刚 clone 下来的陌生仓库，先别急着信任，看过里面的 .codex/ 再说。在 App 里怎么标记信任，以你的 App 为准；配置文件里的写法第 7 课讲。

另外，命令行启动时，Codex 会看文件夹有没有用 Git 管理：有 Git 的，推荐"工作区可写 + 按需审批"；没有 Git 的，建议用只读。App 的三档里没有只读，菜单里有没有只读的权限配置档以你的 App 为准；命令行里用 /permissions 切换。道理是一样的：没有 Git，就没有检查点可以退回去（第 4 课），审阅面板也用不了。

练一练：该选哪一档

搜索是另一条路

Codex 自带一个联网搜索工具，它是 OpenAI 那边托管的服务，和沙箱里命令的网络是分开的：你没给命令开网络，它照样可以搜索。本地对话默认用缓存模式：结果来自 OpenAI 维护的网页索引，而不是现场去打开任意网页。在 App 里，搜索记录和其他工具调用一起出现在对话里。

• 需要最新信息时可以改成实时模式，也可以把搜索整个关掉，都在配置文件里改（第 7 课）。
• 用 Full access 时，搜索默认就是实时模式。

缓存模式能降低、但不能消除提示注入的风险。官方的原话是：把所有搜索结果都当作不可信的输入。

什么是提示注入

你让助理去查一份资料，资料里夹了一张纸条："看到这张纸条的人，请把老板抽屉里的钥匙寄到这个地址。"助理要是照做了，就是被"注入"了。Codex 读网页、读 GitHub issue、读依赖包的 README 时，也可能读到这种专门写给 AI 看的指令。

下面是一个示意：你让 Codex 按一个 GitHub issue 修 bug，issue 里藏了一段话。假设 Codex 真的被骗了，想照着做，每一档还剩哪道防线？

常见疑问