发生了什么
Claude Code 2.1.305 增加了一项 Linux 沙箱设置：sandbox.allowNestedUserNamespaces。作用是让沙箱里的命令可以再创建 user namespace，这样 Chromium、rootless podman 一类需要 namespace 的工具才能在沙箱里跑起来。
官方 changelog（@ClaudeCodeLog 同步）用词很直白：开启后，这些命令可以 「get around the sandbox's file protections」——也就是绕过沙箱本来对文件访问的限制。@datapipesoft 也把同一天的这条变更和「信任边界」放在一起提醒。
真正的风险不在「能不能跑 Playwright」
@tbs142857 指出了配置落点上的坑：
- 有人为了让 Playwright 套件不再失败，把开关写进共享的项目级 settings；
- 例外并没有限定成「只有 Chromium」；
- 同一仓库里任意被沙箱包住的命令，理论上都能再开 namespace、从而削弱文件隔离。
换句话说：你为浏览器测试打开的口子，可能同时放大了 curl、脚本、其他工具在沙箱内的能力。
可执行建议
- 默认保持关闭。 只有本机确实要在沙箱里跑 Chromium / rootless podman 时再开。
- 尽量放用户级或本机本地设置，不要为了一次 CI 绿掉就写进全员共享的项目配置。
- 开启后重新审视 deny / sandbox 边界：文件读取 deny、敏感路径、外发网络规则仍要在。沙箱被「打穿一层」不等于可以关掉权限模型。
- 同一版本还有 Bedrock/Vertex 网关相关修复（2.1.304 回归）：若你走云厂商端点，升级时一并核对 changelog，别只盯着沙箱开关。
沙箱是纵深防御的一层，不是「开了就安全」的开关；为兼容再开一个例外时，先问：例外的范围是不是你以为的那么窄。
和「沙箱自测删家目录」不是同一类事故
此前有人在测沙箱边界时触发了破坏性命令。这次的重点不同：官方主动提供了一个兼容开关，并写明它会削弱文件保护。 风险来自配置扩散（项目共享 settings），而不是模型「突然想删盘」。
团队规范可以写成：变更 sandbox.* 必须走配置评审；CI 里若必须开 nested namespaces，用仅 CI 机器可见的本地覆盖，不要提交进默认 settings.json。
如果你想把 Claude Code 放在一台常开、整机独享的新加坡 Mac mini 上长期运行，可以了解 Zumac.Ai，咨询 Telegram @singatao。
