沙箱里跑 Chromium、rootless podman：sandbox.allowNestedUserNamespaces 怎么用、代价是什么

在 Linux 上开着 Claude Code 沙箱干活，有一类命令以前怎么都跑不起来：要起无头 Chromium 做端到端测试、要用 rootless podman 构建镜像。它们的共同点是需要自己再创建一层用户命名空间（user namespace），而沙箱本身就是靠命名空间把命令关起来的，默认不让里面的进程再嵌套一层。

CLI 2.1.305 为此加了一个开关：sandbox.allowNestedUserNamespaces。

它做了什么

打开后，沙箱里的命令在 Linux 上可以创建用户命名空间。官方举的例子就是 Chromium 和 rootless podman——前者的进程隔离、后者的无 root 容器，都依赖这个能力。

但更新说明里同时写得很直白：这样做会让这些命令绕开沙箱的文件保护。也就是说，它不是一个「顺手打开也无妨」的兼容开关，而是用一部分隔离强度去换可用性。

怎么配置

它是 sandbox 设置下的一个字段，写在 settings.json 里即可，比如放在项目的 .claude/settings.json：

{
  "sandbox": {
    "allowNestedUserNamespaces": true
  }
}

建议只放在确实需要它的项目里，而不是写进全局用户设置。这样换到别的仓库时，沙箱仍然保持完整的文件保护。

什么时候值得开

可以先问自己两个问题：

1. 这个仓库真的需要在沙箱里跑 Chromium / podman 吗？ 如果只是偶尔跑一次，让它在沙箱外执行、逐次确认，往往比永久放宽更稳妥。
2. 你对这个仓库里的代码和依赖有多信任？ 文件保护被绕过后，一段恶意的构建脚本或测试依赖能碰到的文件范围会变大。来源不明的仓库、刚克隆下来的第三方项目，不建议打开。

适合打开的典型情况：自己团队维护、依赖可控的项目，CI 或本地需要 Playwright/Puppeteer 起浏览器跑测试，或者开发流程离不开 rootless 容器。

同时别忘了，沙箱的网络限制和权限规则仍然是另一道防线，permissions 里的 deny 规则依旧照常生效，不要因为放开了这一项就把其它限制也一起放宽。

顺带：两处沙箱 / Bash 相关的小改进

• 磁盘写满时报错说人话（2.1.305）。 以前磁盘满了，Bash 命令会直接甩出一个带文件路径的原始 ENOSPC 错误；现在会明确告诉你磁盘已满，而且命令根本没有执行，不用再猜它跑到一半停在了哪里。
• denyRead 里带方括号的路径不再让沙箱起不来（2.1.304）。 如果 sandbox.filesystem.denyRead 的 glob 里有并非字符类的方括号，例如 Next.js 风格的 [user-id] 路由目录，旧版本在 Linux 上会导致沙箱命令启动失败，现已修复。

小结

• 2.1.305 新增 sandbox.allowNestedUserNamespaces，让 Linux 沙箱内的命令可以创建用户命名空间，Chromium、rootless podman 因此能跑；
• 代价是这些命令可以绕开沙箱的文件保护，只建议在可信项目里按项目开启；
• 同版本磁盘写满时的 Bash 报错更清楚，上一版还修了 denyRead 方括号路径导致沙箱启动失败的问题。