Claude Code 插件在你打字之前会运行什么：我们读了 2,688 个公开插件
我们读了 1,961 个活跃公开仓库里 2,688 个 Claude Code 插件的钩子、MCP 服务器和 monitor：30% 的仓库带着会话一开始就运行点什么的插件，用 npx 启动的 MCP 服务器有 65% 不写版本。
概述
装一个 Claude Code 插件之前，打开它文件夹里的三样东西：hooks/hooks.json、.mcp.json 和 bin/。找找 SessionStart 钩子，以及用 npx 或 uvx 启动、却没写版本号的 MCP 服务器。
原因很简单。插件可以在你打任何字之前就运行代码。文档说得很直接：A Claude Code plugin you install can execute arbitrary code on your machine with your user privileges。插件里有四样东西会自己启动：
- SessionStart 钩子在会话开始时运行 shell 命令，它的纯文本输出会加进 Claude 的上下文，Claude can see and act on。
- MCP 服务器只要写了启动命令，就是插件启用后 Claude Code 在你机器上启动的进程。
- monitor 是整个会话期间都在后台跑的 shell 命令，输出会发给 Claude。
bin/会被加进 Claude 运行命令的那个 shell 的PATH。
这些都由 Claude Code 在沙箱外运行，而且装上插件就等于启用了它。
那么公开的插件里有多少这样做？我们把 1,961 个活跃公开仓库里的插件全读了一遍。
推荐
下面是我们现在装插件之前会做的检查：
- 读
hooks/hooks.json，先看SessionStart和Setup。 它们在会话开始时运行，输出会成为 Claude 的上下文。要读它们调用的脚本，别只看命令行，因为大多数都是运行插件文件夹里的一个文件。 - 读
.mcp.json。 写了command的服务器就是你机器上的一个进程。如果它跑的是npx some-package或uvx some-package、没写版本，包管理器会在启动时自己决定用哪个版本；新版本发布后，你审过的插件一个字没改，也可能换了一套代码在跑。钉死版本就是在包名后面写上版本：npx 写@1.4.2，即npx -y some-package再接@1.4.2；uvx 写==1.4.2，如some-package==1.4.2。 - 装之前先列出全部内容。 把仓库 clone 下来，跑
claude --plugin-dir <插件文件夹> plugin details <插件名>。它不开会话，只读插件的文件，列出钩子和各自的事件、MCP 和 LSP 服务器、skill 和 agent。 - 想好要不要自动更新。 文档提醒，市场开了自动更新时，the files you reviewed can change on disk。对你不掌控的市场把它关掉，或者优先用把每个插件钉到某个 commit 的市场，Anthropic 的社区市场几乎每个条目都是这样。
如果插件带了 mod，该查什么见我们的 891 个公开 mod 审查，这里不再重复。
怎么测的
- 找插件。 GitHub 代码搜索能找到 34,157 个插件 manifest（
filename:plugin.json path:.claude-plugin）。每次搜索最多返回 1,000 条，所以我们按文件大小切成 40 段，交错着跑，限时 30 分钟，跑完 23 段，各个大小区间都覆盖到了。去重后得到 17,965 个 manifest，约占总数的 53%，来自 17,928 个仓库。 - 筛仓库。 至少 5 星、10 月 7 日以后有推送、不是分叉、没有归档，剩 1,964 个，读到 1,961 个。
- 读这些仓库里的全部插件。 每个插件都读同一个 commit 下的这些文件：manifest，
hooks/hooks.json和hooks字段，.mcp.json和mcpServers字段，.lsp.json，monitors/monitors.json，bin/，以及这些命令点名的脚本。一共 2,688 个插件，只当文本读，没有安装或运行任何东西。 - 按仓库算。 大多数仓库只有一个插件，最多的有 117 个。主口径是有至少一个这类插件的仓库占多少；另外给每个仓库最多取 10 个插件的比例，以及全部插件的比例，三者很接近。
测试结果
| 插件做了什么 | 仓库（共 1,961） | 插件，每仓最多 10 个 | 全部插件 |
|---|---|---|---|
| 会话开始时运行点什么（SessionStart 或 Setup 钩子、本地 MCP 服务器或 monitor） | 30.4% | 27.4% | 24.5% |
| SessionStart 或 Setup 的 shell 钩子 | 16.0% | 14.3% | 12.8% |
| 其中脚本会写文件 | 6.0% | 5.1% | 4.6% |
| 其中脚本会联网 | 1.5% | 1.2% | 1.1% |
| 有任意 shell 钩子 | 22.2% | 20.1% | 18.5% |
| UserPromptSubmit 钩子（看到每条提示词，输出交给 Claude） | 8.1% | 7.0% | 6.3% |
| PreToolUse 钩子 | 11.8% | 10.5% | 9.5% |
| 声明了 MCP 服务器 | 26.3% | 24.1% | 21.3% |
| 本地 MCP 服务器（你机器上的进程） | 18.4% | 16.4% | 14.6% |
| 远程 MCP 服务器（一个网址） | 8.6% | 8.2% | 7.2% |
| 用 npx 或 bunx 启动的 MCP 服务器 | 5.9% | 5.5% | 4.9% |
| 其中没写版本 | 3.9% | 3.5% | 3.2% |
| 用 uvx 启动且没写版本的 MCP 服务器 | 1.4% | 1.2% | 1.0% |
| 任一包管理器启动、没写版本的 MCP 服务器 | 5.3% | 4.7% | 4.2% |
| 把名字像密钥的环境变量传给 MCP 服务器 | 2.4% | 2.1% | 1.9% |
bin/ 文件夹进了 Claude 的 PATH | 9.5% | 8.0% | 7.1% |
| 带 mod（见 mods 审查） | 5.3% | 4.9% | 4.3% |
| monitor | 0.4% | 0.3% | 0.3% |
设了 defaultEnabled: false | 0.1% | 0.0% | 0.0% |
大家猜猜看，这些插件用 npx 或 bunx 启动的 MCP 服务器里，有多少写了版本？大约三个里有一个。171 个这样的服务器里，112 个（65%）没写，用的是 @latest、裸包名或 GitHub 引用；149 个（87%）带了 -y，跳过 npm 的安装确认。全部 945 个 MCP 服务器里，最多的是远程网址（445 个）、插件里的本地脚本（176 个）和 npx（164 个）。
举几个例子，都不点名：
- 会话开始。 大多数 SessionStart 钩子是用
node、bash或python3运行插件文件夹里的脚本，文件名多是session-start、resume-hint、context-inject这一类。会话开始时脚本会联网的 29 个仓库里，26 个是在 GitHub 或 npm 上查更新，有几个连的是本机localhost上它自己的服务；大约十个提到了 telemetry 或 analytics，具体上报什么我们没有核实。 - 你的 API key。 有个按规则检查回复的钩子，会用你的
ANTHROPIC_API_KEY调 Anthropic 的接口，把一段对话发过去做判断，代码注释里写明了。它花的是你的额度，发的是你的对话，装之前你可能想知道这一点。 - 凭据路径。 写着
~/.ssh或.env的钩子，大多是列出这些路径用来拦截的守卫。
被我们规则筛出来的插件，人工读过以后，没有一个像是恶意的。
该忽略什么
组件的数量。一个带二十个钩子的插件，可能是很谨慎的守卫；一个只有一个 SessionStart 脚本、外加一个没写版本的 npx 服务器的插件，才是要细读的那个。要看的是什么会自己启动、它又会去拉什么。
局限
- 是抽样。 约 53% 的 manifest，来自 5 星以上的活跃仓库，截至 2026 年 11 月 6 日。这反映的是公开插件仓库里有什么，不是大家实际装了什么。
- 只看静态文本。 我们没有运行钩子，所以不知道它们给上下文加了什么，也不知道联网的脚本发了什么。
- 没写版本是风险，不是已发生的危害。 新版本会不会到你机器上，取决于包管理器的缓存。没写版本时，插件本身一点不改，也可能跑起另一套代码。
- mod 只计数，不分析。 那部分见 mods 审查。
自己复现
上面三种口径的数字都在 plugin-startup-2026-11.json 里，仓库名和插件名都去掉了。想自己检查一个插件，跑 claude --plugin-dir <插件文件夹> plugin details <插件名>，再读它列出的那些文件。
想自己挑 skill 来装的话，AgentCraft skills 目录收录了 5,101 个 Claude Code skill，每个社区 skill 收录前都经过审核。
所有检查都汇总在一页：Claude Code 安全检查清单。