安装 Claude Code 扩展前先查权限

Claude Code 的 mod 可以扩展界面，也可能读取文件、启动程序、访问网络，甚至替你批准工具调用。作者对 891 个社区 mod 做了静态检查，想回答一个安装前更实际的问题：它声明的用途，是否需要这么大的权限？

结论不是「这些 mod 有问题」，而是安装前应该先看清它能触及什么、能拦截什么。对每天让 AI 读代码、跑命令的程序员来说，这比下载量和功能截图更值得先看。

安装前先看两行，比看星数更直接

据原文，mods 在 10 月 1 日的 Claude Code 2.1.287 中引入，而且不受沙箱隔离。mod 使用当前用户的权限，它启动的进程即使在开启沙箱时，也会运行在沙箱之外。

作者建议先对下载到本地的目录运行检查，再决定是否安装：

claude plugin validate ./some-mod

注意这里检查的是 mod 文件夹。按原文描述，这条命令读取代码，不执行 mod；输出中的 calls: 和 hooks: 才是需要重点读的两行。

calls: 表示它能调用哪些能力：

• $.http.fetch 可以访问网络。
• $.process.run、$.process.spawn 可以启动程序。
• $.fs.write 可以写文件。
• $.env.get 可以读取环境变量，API key 经常保存在这里。
• $.prompt.submit 可以代你提交提示词。
• $.model.complete 可以调用模型，消耗套餐额度或 API key 对应的资源。

这些能力都有正当用途。关键是用途和权限是否匹配：手机远程控制会话需要联网、代发提示词；一个只显示 token 数量的组件如果也要联网，就应该继续读代码找原因。

hooks: 则表示它能在哪些事件中介入。没有花括号过滤条件的 tool.call，能够看到并修改每次工具调用；prompt.submit 能看到每条提示词；session.append 能在对话记录存储前改写记录；tool.check 能在询问用户之前回答权限问题。

验证通过，只说明 Claude Code 能读懂这些调用，不代表这些调用值得信任。

如果发现 tool.check，作者建议进一步找出返回 allow 的位置。它批准的是插件自己的工具、只读操作，还是更宽泛的调用，差别很大。

891 个样本说明了什么，又没说明什么

作者先通过 GitHub 代码搜索和仓库搜索找到 1,781 个仓库。筛选条件是不属于 fork、未归档、10 月 7 日之后有推送、至少 5 stars，剩下 311 个，成功克隆 303 个。

他们把 hooks/hooks.json 的 modules 指向代码文件、且该文件导出 register 的对象认定为 mod，共找到 915 个。相同文件只保留星数最多的副本，得到 902 个。

批量检查使用 Claude Code 2.1.314，采用 JSON 输出：

claude plugin validate --json

这里保留的是原文给出的命令形式，实际批量传入目录的脚本没有展示。要注意 --json 参数；作者还使用空的 home 目录，避免自己的设置、hooks 和插件一同加载。他们没有安装 mod，也没有执行 mod 代码。

剔除 Anthropic 的 4 个示例和验证器无法读取的 7 个 mod 后，最终样本是来自 283 个仓库的 891 个社区 mod。原文称，那 7 个也会被 Claude Code 拒绝加载。

其中，只有 156 个被归为仅绘制界面、保留自身笔记，不到五分之一。但其余 mod 权限更广，不等于它们在滥用权限。

作者给出的例子能解释这种区别。手机接续会话的 mod 要跟踪轮次、连接中继服务，并把手机输入作为用户提示词提交，因此同时出现 $.http.fetch 和 $.prompt.submit 很合理。远程控制 mod 监听全部工具调用、提示词和存储记录，也与其功能相符。

涉及凭据路径的命中项，经作者人工阅读，都是读取自身 token。例如，一个 Telegram bot 反应组件从自身目录的 .env 读取 bot token 并保存在内存。不过，$.fs.read 本身并没有被限制为只能读取这个文件，它可以读取当前用户有权读取的其他文件。

他们还人工阅读了全部 11 个返回 allow 的 mod：5 个只批准自身工具或所属插件的调用，2 个批准只读操作，另外各有 1 个批准固定搜索命令、批准持有文件锁时的编辑、调用外部命令确认资源占用，以及让模型评分后批准低于风险阈值的操作。

最后一种范围最宽，但这 11 个都没有直接批准任意 shell 命令。这是对特定样本的代码检查结果，不能扩大成对整个生态的保证。

目录数据能互相印证，星数不能替代审查

原文还对比了 awesome-claude-code-mods 目录。它每天扫描 GitHub，11 月 1 日快照包含 8,532 个 mod，同样使用验证器，但给每个 mod 一个能力等级；作者则分别统计每种调用和 hook，一个 mod 可以进入多个类别。

作者在 11 月 6 日克隆样本，重点覆盖最近 30 天活跃、至少 5 stars 的仓库。双方重叠的 521 个 mod，网络访问标记全部一致。

整体比例也接近：目录与作者样本的网络访问占比分别为 9% 和 11%，启动程序为 38% 和 39%，写文件为 18% 和 23%，提交提示词为 11% 和 13%。不过，作者的 283 个仓库里，有 161 个没有出现在目录快照中，且它们都在快照之前创建。原文没有解释这些缺失的具体原因。

这组对比支持「两种统计对常见能力的识别大体一致」，不能证明样本覆盖全面，更不能证明安全。

静态检查还有另一层边界：列出来的调用可能位于需要点击才触发的分支，并不代表每次运行都会发生。反方向上，原文称 Claude Code 会拒绝加载调用无法被静态识别的 mod。这个保证依赖其验证与加载机制，作者没有提供独立的绕过测试。

统计保存在 mods-review-2026-11.json，但隐去了仓库和 mod 名称。原文末尾还推广了收录 5,101 个 Claude Code skills 的 AgentCraft 目录，作者披露自己参与运营 AgentCraft。这个利益关系应该与技术发现一起阅读。

我的判断

我认可这篇最实用的做法：把「功能听起来有用」转成「这些能力是否必要」的具体检查。尤其是 tool.check，它涉及谁来批准操作，值得比普通界面能力多花时间审查。

但不要把 156 个低权限 mod 之外的所有样本都看成可疑对象。远程控制、数据库审批面板、读取任务队列的看板，功能越深入工作流，越可能需要更广的能力。

与只看星数、作者声誉相比，静态验证提供了可以逐项核对的证据；与隔离运行相比，它又不能限制实际执行的权限。两者解决的问题不同。作者没有给出恶意样本检出率、验证器漏报率或运行时对照数据，因此「安装前这样查更稳妥」是有依据的操作建议，不能升级成经过验证的安全保证。

能拿来做什么

• 给日常 Claude Code 工作流增加一个安装前步骤：先克隆 mod，运行 claude plugin validate ./some-mod，把 calls:、hooks: 与功能说明逐项对应。
• 为前端或 Node 项目选择状态栏、计数器等简单扩展时，优先解释清楚它为什么需要联网、启动程序或读取环境变量，再决定是否接受这些能力。
• 遇到 tool.check 时，继续定位返回 allow 的条件；如果条件交给外部命令或模型评分，连同这部分判断依据一起检查。
• 升级 mod 时重新验证。原文统计只是 2026 年 11 月 6 日的快照，既有版本的检查结果不能直接覆盖新增的事件和调用。