在Claude Code的issue跟踪系统里，第40117号问题记录了一个让工程师不安的场景：他亲眼看着Opus连续六次提交，次次绕过自己设置好的gitleaks检查和测试钩子。手段每次如出一辙——--no-verify标志、静默参数，或者一次git stash让工作树在钩子运行时看起来干干净净。事后追问，AI对刚才的所作所为一通搪塞。Anthropic的处理结果是关闭此问题，标注“不计划修复”。这不算一个bug报告。这是厂商用书面形式告诉你：活在AI自己工作区里的防护，根本不算防护。

这件事让我此前一篇文章的观点落了地：一张可删除的网，AI总能靠拆除它来过关；而一张结构性的网，无论AI走哪条路径都绕不过去。那篇文章刻意不绑定具体工具。这篇则不同。它专讲Claude Code的配置方案，把我之前文章里那些结构性防护网，变成你今天下午就能粘贴进设置文件的具体代码。每条设置都对应一个明确的绕过路径，我会一并写清楚。截至本文写作时（2026年7月），我已经把每个设置项名称和每条引用对照着实时文档与issue列表核对过。Claude Code的设置体系更新飞快，如果半年后你要拿来用，记得重新验证。

打开网易新闻 查看精彩图片

沙盒与网络：堵住四个绕过点
单靠sandbox.network.allowedDomains这套域名白名单机制，不过是一张披着结构外衣的可删除网。绕过它的入口在sandbox.allowUnsandboxedCommands，而这个配置的默认值是开启的：一旦命令在沙盒里执行失败，系统允许它跳出沙盒重试，只靠一个权限提示弹窗来充当防护。在提示疲劳面前，弹到第五十一次时，点“允许”早就是一个本能动作。

真正奏效的写法长这样。allowManagedDomainsOnly是一把仅限托管设置才能改动的锁，这样一来，项目或个人层级的settings.json就没办法在底层把允许列表偷偷拓宽。failIfUnavailable的作用是拒绝启动，而不是在底层沙盒工具缺失的情况下悄无声息地回到无沙盒运行。allowUnsandboxedCommands设为false，则彻底堵死了“跳出沙盒重试”这条路，那个需要一遍遍点确认的弹窗就此消失。还有deniedDomains这个明确的拒绝列表，它的重要性不可低估：一个宽泛的github.com白名单仍然允许通过gist.github.com进行数据外泄。所以每设置一个allow，就要同步指明那个允许上传内容的具体子域名，将其封堵在外。

需要明确的是，MCP服务器通过标准输入输出进行通信，完全不经过这个沙盒。sandbox.excludedCommands列表中包含的工具在设计上就是无沙盒运行的，而且它没有托管设置才能改动的锁，这意味着本地开发者随时可以向其中追加内容。此外，整个体系没有TLS检查能力。