一个被忽略的权限漏洞：代理改自己的规则
无人值守、--dangerously-skip-permissions、长期挂机——这些已经够吓人。@itsmatthager 补充了更隐蔽的一点：
在 4,831 份「设置了 permissions」的公开 Claude Code 配置里，只有 31 份会拦住代理编辑自己的
.claude 设置。也就是说：绝大多数配置里，代理理论上可以改 settings.json、放宽自己的 allow、甚至拆掉你以为设好的护栏。他建议：至少对 .claude 相关路径加 deny，并同时 deny 读取 .env。
同系列扫描还给出：
- 约 85.6% 触碰了 permissions 块的公开配置，一条 deny 都没有（@razeenali01 转述为「85% 零 deny」量级）；
- 在 694 份「至少有一条 deny」的配置里，只有 5 份同时覆盖
.env、secrets、.claude、git push与rm。
deny-first：危险清单其实很短
@MiraZephyre 的建议是：先写短 deny，再观察一周实际用到的命令再放宽。起步五项可以是：
- 读取
.env与 secrets 目录； - 访问
~/.ssh一类密钥路径； rm -rf类破坏性删除；git push --force；curl/wget管道进 shell。
这和「CLAUDE.md 里写不许读 .env」不是一回事：CLAUDE.md 是请求，permissions deny 才是硬拦截。（今日另文已写过 CLAUDE.md ≠ permissions，此处不重复展开。）
可执行检查
- 打开项目的
.claude/settings.json（及用户级 settings），确认有deny段。 - 显式拒绝编辑/写入
.claude/**与读取.env、密钥目录。 - 不要长期依赖「全开 / skip-permissions」无人值守；若必须自动化，把不可逆操作留在 ask，并定期
/permissions棚卸。 - 可用社区权限打分工具自查，但不要把配置文件发给陌生第三方——本地检查即可。
为什么「改自己的设置」比读 .env 更危险
读到密钥是一次泄露；改掉 deny 规则是持续失去防线。代理若能编辑 .claude/settings.json，后续会话可能在你不知情时进入更宽的 allow，甚至打开 bypass。公开配置统计说明：社区整体还停在「会写 permissions」阶段，远没到「会锁住权限文件本身」。
建议把「禁止改 .claude」写成与「禁止读 .env」同级的默认模板，新仓库直接复制，而不是等出事后再补。
如果你想把 Claude Code 放在一台常开、整机独享的新加坡 Mac mini 上长期运行，可以了解 Zumac.Ai，咨询 Telegram @singatao。
