两分钟筛掉可疑 Codex 插件与 MCP server：一份可照做的检查清单

插件和 MCP server 装起来太容易，但它们会在你机器上跑代码。作者给出一套约两分钟的安装前检查流程：看项目是否还活跃、实际执行什么命令、要哪些权限、谁做的、有没有 license、manifest 是否干净。

为什么装之前要先看一眼

• 插件可以同时打包 hooks 和 MCP server，两者都会在本机执行代码，社区插件基本没人逐个审计。
• 作者运营一个 ChatGPT/Codex 插件目录站，这套清单不依赖插件来源，在哪找到的都能用。
• 目标不是做完整安全审计，而是用两分钟把明显可疑的筛掉。

第一步：项目还活着吗

• 看最后一次 commit 时间、open issues 的状态、仓库是否已 archived。
• 长期没更新的插件可能还能用，但宿主应用一改接口，出问题只能自己扛。

第二步：它到底跑什么

• 安装前先打开 .mcp.json 和 hooks.json，这两处才是真正执行的部分。
• MCP server 会启动一个进程，常见形式是 npx、uvx 或直接跑二进制文件，agent 通过它通信。
• hooks 会在工具调用、会话开始等事件上触发命令。
• 看不懂某条命令在干什么，就先查清楚再让它跑。

第三步：它要什么权限，数据去哪

• 列出它申请的 token、文件系统访问和网络访问，再对照它宣称的功能是否匹配。
• 一个 Markdown 格式化工具却要 GitHub token，就值得多看一眼。
• 把权限压缩成三个问题：能读什么、能写或发送什么、我的数据流向哪里。
• README 一屏之内答不上来这三个问题，作者通常直接跳过。

第四步：作者、license 与 manifest

• 知名公司或有持续项目记录的维护者，比刚注册、只有一个仓库的新账号更可信，但这只是信号不是保证。
• 没有 license 意味着严格来说你不能复用代码，也侧面反映发布时的用心程度。
• 检查 plugin.json 里有没有绝对路径、硬编码密钥、指向意外位置的字段，这些都是红旗。
• 官方内置目录由 OpenAI 筛选过，是真实信号，但涉及邮件、文件、部署的插件仍要自己看清连了什么。

评论区补充的两个盲点

• 版本锁定：用 @latest 的 npx/uvx 启动器会在你审查之后悄悄变化，固定到 @x.y.z 只有插件升级时才变。
• 看工具定义本身：声明 shell 或文件写权限的 server，风险等级和只读的完全不同。
• 每次更新后 diff 一遍 manifest，能抓住两分钟初筛窗口漏掉的“先养后变”式改动。
• 会操作屏幕或浏览器的插件，还要确认它是否内置了购买、删除、发送前的确认规则，manifest 里看不出来。