帖子说了什么
@timwork_notes 一句话点破：权限提示有多可靠，取决于它给你看了什么。 在 Claude Code 2.1.310 之前，当 Claude 想读一个看起来很普通的文件时，权限提示并不会告诉你这个文件其实是一个符号链接（symlink），真正指向的可能是 ~/.aws/credentials 这类凭证文件。你以为批准的是 notes.txt，实际放行的是你的云账号密钥。作者的结论是：符号链接仍然是绕过人工确认最便宜的办法。
官方 CHANGELOG 的 2.1.310 条目确认了这一点：修复了文件读取权限提示不显示符号链接指向位置的问题。
为什么和账号安全有关
很多人给 Claude Code 的防线就是「它要读什么我都会看一眼」。但如果提示里只显示链接本身的名字，这一眼就失效了。攻击者只要能在仓库里放一个文件（比如通过一个你克隆下来的第三方项目），把它做成指向你家目录凭证的链接，再在 README 或配置里诱导 Claude 去读，凭证就可能进入对话上下文，之后再被带出去。
同类问题官方此前也处理过：Claude Code 的安全公告 GHSA-5j29-h97v-84ch 描述过写入时跟随符号链接导致写到项目外的问题（2.1.129 修复）。符号链接是一个反复出现的攻击面。
你可以立刻做的几件事
- 升级到 2.1.310 或更新版本，
claude --version确认。 - 批准读权限前看完整路径，看到「指向 / links to」字样时停下来想一想：这个文件真的需要读吗？
- 给凭证目录加 deny 规则，例如在 settings 里对
~/.aws/、~/.ssh/、~/.config/gh/**等加Read拒绝，并配合沙箱的文件系统限制，不只靠人眼。 - 打开陌生仓库前先查链接：
find . -type l -exec ls -l {} +看看仓库里有哪些符号链接、分别指向哪里。 - 怀疑已被读取就轮换：相关云密钥、Token 直接作废重建，比事后排查对话记录更稳。
小结
你批准的应该是「这个文件」，而不只是「这个名字」。升级让提示把真实指向显示出来，再用 deny 规则把凭证目录挡在外面，两层一起，才不怕一个符号链接骗过你。
