Read 拒绝规则不再被 @ 引用绕过：符号链接与变量前缀补洞

很多团队会在 settings 里写 Read 的 deny 规则，比如禁止读 .env、密钥目录或客户数据。规则写对了，Claude 主动去读时会被拦住。但 CLI 2.1.289 修掉的几处问题说明：有些路径以前并不经过这道拦截。

这次一共补了几个口子，可以分成「读文件」和「跑命令」两类。

读文件：符号链接和 @ 引用

修复前的问题：文件如果是通过符号链接进来的，下面三种方式会绕开 Read deny 规则：

• 你在输入框里 @ 引用了这个文件；
• 这个文件被改动后，内容被带进上下文；
• 你在 IDE 里选中了它，选区被同步给 Claude。

换句话说，规则按真实路径写了禁止，但从符号链接那一侧进来就没拦住。2.1.289 起，这几种入口也会按 Read deny 规则检查。

对谁影响最大：

• 仓库里用符号链接挂了共享配置、密钥目录或 monorepo 子包的团队；
• 习惯用 @ 引用一把拉文件进上下文的人。

跑命令：环境变量前缀与变量赋值

另外两条修复都发生在沙箱自动放行打开的时候：

1. 命令前面带了环境变量前缀，而且值需要展开，例如 TZ="$HOME" rm -rf build，以前 Bash 的 deny 和 ask 规则可能认不出后面真正执行的是 rm。
2. 命令前有一个单独的变量赋值，再接真正的命令，deny 或 ask 规则也可能被跳过。

还有一条针对企业托管机器：复合命令里嵌套的那一段命中了 deny 或 ask 规则，以前可能被用户自己装的 mod 的批准盖过去；现在规则优先。

这几条和前几个版本的修复是一个方向：危险 rm 加重定向不再漏问，以及 2.1.288 修的 bash -c / sh -c 脚本里危险 rm 在 bypassPermissions 模式下不提示的问题。都是在堵「换个写法就能溜过规则」的口子。

团队该怎么自查

1. 全员升级到 2.1.289 及以上，托管机器优先。
2. 列出仓库里的符号链接：find . -type l，看有没有指向 deny 规则保护的目录。
3. 用 @ 引用一个经符号链接、且应该被 deny 的文件，确认现在会被拦住。
4. 在沙箱自动放行的会话里，试一条带变量前缀、本应命中 ask 规则的命令（用无害的目标），确认会先问你。
5. 回顾 权限与沙箱的基础配置：deny 写真实路径还是通配，是否覆盖了常见的别名路径。

规则本身也值得再看一眼

这次是客户端把漏洞补上了，但规则写得宽一点能多一层保险：

• 敏感目录尽量用通配覆盖整个目录，而不是只列单个文件名；
• 真正不能碰的东西（生产密钥）尽量不放在工作目录里，靠规则拦只是第二道线；
• 允许用户自装 mods 的团队，要清楚 mod 的批准和托管规则谁优先。

小结

• 2.1.289 起，经符号链接 @ 引用、被改动或在 IDE 里选中的文件，也会走 Read deny 规则。
• 沙箱自动放行时，带环境变量前缀或前置变量赋值的 Bash 命令，不再漏掉 deny / ask。
• 托管机器上，复合命令里嵌套那一段的规则不再被用户 mod 的批准盖过。

权限规则的价值在于「怎么绕都绕不过去」，升级之后照上面几步自查一遍，比出事后再查要省心得多。