关掉文件系统沙盒反而更安全？Claude Code 2.1.216版本给了开发者这样一个看似反直觉的选项。7月20日发布的这个版本新增了sandbox.filesystem.disabled配置项，允许跳过Claude Code自身的文件系统隔离，但仍保留网络出站控制。不过这并非一个默认就该打开的开关——Anthropic的沙盒文档强调，有效的隔离必须同时具备文件系统和网络两重约束。新选项真正的用途，是当外界已经有一层一次性容器或虚拟机把文件系统封住了，Claude Code内部的这层隔离才可以选择解除。

在安全团队的视角里，这更像是一次责任转移，而不是安全增强。如果把filesystem.disabled置为true，意味着开发者必须自行保证容器或VM不会泄漏主机凭据、Shell启动文件、其他仓库的源码以及部署配置。因此Anthropic建议，即使切换到这种兼容模式，网络侧仍要设限，例如仅允许访问registry.npmjs.org，同时强制禁用未沙盒化的命令逃生通道（allowUnsandboxedCommands设为false）。

2.1.216除了这个可选的豁免项，还悄悄地修了几个沙盒边界的旧账。发布说明里列出了五个需要回归覆盖的变更：涉及worktree隔离的子代理、符号链接指向的.claude路径、回退操作以及恢复后台代理时的限制。这些问题都属于沙盒和状态恢复的边界失败，如果不升级，在复杂的仓库结构和长时间会话中可能出现隔离穿过的情况。但即便如此，这次修复并不让每一个命令都变得安全，也不能检查加密流量，内置的文件工具、Computer Use或MCP工具的权限仍需单独控制。

官方给出的升级门控很实际：先升级到2.1.216，接着选定一种隔离配置文件，然后在一次性仓库里跑至少五个非破坏性边界测试，把日志和哨兵哈希与基线做对比，通过后再逐步推广。这个测试无论如何都不要用真实凭证或生产环境的仓库——测试如果不能留下完整的证据链（版本号、操作系统、设置作用域、fixture提交、指令、提示、退出码和哈希），即使试跑通过，也很难区分是真的没触发问题还是根本没走到预想的代码路径。

对于日常要在本地、CI或后台代理中维护复杂工作流、定时任务和长期会话的开发者，这份清单刚好补上了通用不信任仓库沙盒指南中缺失的一块。前一份指南画出了信任边界，这一份则逐一验证v2.1.216在具体配置下能否守得住。等环境验证安全后，再用/claude的/verify和/code-review做输出质量的最终把关，才算走完整个流程。