技术 · 熟练
沙箱里放开一条命令，等于放开它能写的每个目录
按环境授权，还是按命令授权
给 agent 的执行环境加一个「让某个工具能跑起来」的开关，看起来是加功能，实际是撤掉一层保护。新版本里那个让浏览器自动化与无根容器能在沙箱里跑的设置，官方一句话写得很清楚：它能绕过沙箱的文件保护 —— 也就是在这条命令能写到的任何目录里，代码执行隔离不再成立。这一页给一条把授权粒度从「环境」收到「命令」的四步：先问它为什么要自建隔离 · 再算它能写到哪 · 只给需要它的那条命令开 · 升级后重核实际生效面。关键动作只有一个：把「开不开」换成「给谁开、开到哪」。
方法 · 一图看懂
1
先问这条命令为什么要自建隔离 — 浏览器自动化与无根容器这类工具会给自己再套一层命名空间；沙箱默认拒绝这件事，所以它跑不起来。要开的原因只有这一个，说不出原因就别开
2
把「放开」读成「撤掉哪一层」 — 它不是功能清单上加一项，而是让那类命令能绕过沙箱的文件拒绝规则；所以真正要算的不是「危不危险」，而是「它能写到哪」
3
授权粒度落到命令，不落到环境 — 同一个沙箱里只给需要它的那条命令开，其余命令仍按默认拒绝；把开关设在「整个 agent 环境」上，等于给所有命令一起放行
4
升级后重核一遍实际生效面 — 默认关闭不等于没被打开：上游同类设置刚有过一次「过滤范围收窄、原本没生效的条目开始自动加载」的先例，所以要拉一份升级前后的实际清单对照，而不是只看配置文件里写着 off
原理 · 为什么有效
隔离是分层的，而这个开关动的是层与层之间的缝。外层沙箱管的是「这个进程能碰哪些文件」；嵌套命名空间让进程自己建一套用户与权限视图，于是在它自己那套视图里，文件规则由它说了算 —— 外层的文件拒绝到不了那么深。所以代价不是「多了一个功能」，而是「在这条命令能写入的目录范围内，最后一次拦截消失了」。为什么按命令授权有效：同一个环境里，绝大多数命令根本不需要自建命名空间，把它们和那条需要的命令捆在一起，等于用最松的那一条去定义整个环境的下限。判据一句话：不是「这个开关危不危险」，而是「这条命令能写到哪」 —— 能写到的范围就是它越权后的影响面。
适用场景
适用：在沙箱里跑浏览器自动化、无根容器、需要自己起命名空间的工具链的人；给团队配 agent 执行环境、要决定「哪些能力默认开」的人。不适用：本来就在自己机器上裸跑、没有沙箱这一层的人（你已经在保护之外了，先补沙箱再谈这个开关）；一次性脚本、跑完即销毁的环境（直接换一个更宽的环境反而更省事）。
自测 · 5 问
我说得出这条命令为什么非要自建命名空间吗（说不出 ⇒ 它可能根本不需要）
我知道开了它之后，这条命令能写到哪些目录吗
这个开关是给这一条命令开的，还是给整个 agent 环境一起开的
关掉它之后，那条命令会以什么方式失败（说得出 ⇒ 我知道边界在哪）
升级前后我拉过一次「实际生效面」的对照，而不是只看配置里写着 off
怎么上手 · 验证步骤
先在一个一次性环境里做，别在天天用的机器上试。① 把命令能写的范围收到最小：只给它一个工作目录，其余目录只读或不挂载。② 跑一次越界写测试 —— 让它尝试往工作目录之外写一个文件，看是被拦还是写成了；这一条是这个开关到底意味着什么的唯一实证。③ 记录「开之前哪一层拦住了它、开之后哪一层不管了」，写成两行备注贴在该环境的配置旁边。④ 只有在第三步能写出具体目录的情况下，才把它设成常开；写不出具体目录，就只在需要时临时开。
问自己一句：如果这条命令被一次提示注入劫持，它最多能改到我哪些文件？答得出具体目录 ⇒ 这个口子是量过的；答不出 ⇒ 它开得比你以为的大。再补一句：这套环境里还有多少条命令会因为这一个开关一起变宽 —— 这个数比开关本身更值得记。