BLOG
热点跟踪 035｜Postman 被指对存量用户静默自动安装 AI 编码插件，还试图自批钩子信任：issue 十天零官方回应
发生了什么
作者的本机调查完成于 10 月 24 日至 25 日两天，证据全部来自本机文件与开源的安装器源码，每一条路径都可自行复核对证。机制逐条拆开：
一、Postman 自己的日志记录了自动安装。~/Library/Application Support/Postman/logs/main.log 里，2026-10-24T09:34Z 有一条分类为「auto-existing-upgrade」的记录，scriptResults 字段写着 claude-code:installed 与 codex:installed，installer 字段为 script。
二、Codex 的全局配置被改写。~/.codex/config.toml 里出现了 marketplace postman（git 源指向 postmanlabs/postman-plugin.git），plugin 条目 enabled=true。
三、钩子指令范围过宽。hooks/codex-hooks.json 注册了 SessionStart 钩子（matcher 覆盖 startup、clear、compact），向模型打印一份 session-start-context.md，内容是：在响应任何非平凡的 API 工程任务（设计、实现、mock、测试、监控、文档、部署 API 或 Postman Flow）之前，加载 postman:api-engineer skill 并遵循。这远比「用户显式点名要用 Postman」的范围宽。
四、安装器源码试图自批钩子信任。hooks.state 里被写入 trusted_hash 与 trusted_content_hash（sha256 双哈希）；安装器源码 installer/src/hosts/codex.ts 在安装完成后调用 approvePostmanHook()，codex-hooks.ts 用 hooks/list 取哈希、经 config/batchWrite 写入信任记录，源码注释原文是「Approves only Postman’s current hook after installation」。作者在这里的口径克制：源码能证明「尝试」，信任记录本身由谁创建，文件证明不了。
五、远程 MCP 被启用但认证不通。mcp.codex.json 指向 https://mcp.postman.com/mcp，Codex 日志记录 MCP server startup failed / Auth required。远端服务没接上，配置却已经写进去了：启用动作发生在用户知情之前。
六、Claude Code 同被波及，还多装了一个 CLI。/.claude/settings.json 启用了 postman@claude-plugins-official，installed_plugins.json 记录版本 2.0.1、安装时间 2026-10-24T09:34:02.610Z；/.local/bin 出现 Postman 可执行文件，mtime 落在安装窗口内。
版本钉子：Postman desktop 12.33.4、Codex plugin 1.1.0、Claude plugin 2.0.1。源码部分钉在具体 revision 6c8e452，可复核。
作者不只是发了牢骚，他给出了六项明确诉求：按严重的产品同意与安全边界事件处理，而不是当文档问题；在显式 opt-in 之前，停止对存量桌面用户自动安装 agent 插件与 CLI；移除安装器侧的钩子自批逻辑，钩子信任必须由用户在 agent 宿主里自己决定；披露 auto-existing-upgrade 背后的版本、feature flag 与同意流程，说清楚还能改动哪些 agent 和哪些文件；提供完整的回滚路径，覆盖 agent 配置、钩子信任、marketplace、缓存、MCP 连接与 CLI，并且尊重删除、不再重装；把启动指令收窄到用户显式点名 Postman 的请求。截至发稿，这六项没有一项得到回应。
静默安装是产品决策，不是 bug
这件事的批评面主线，是一条完整的归因链：源码里有 approvePostmanHook() 这样的专门函数，日志里有 auto-existing-upgrade 这样的专门分类，hooks.state 的双哈希实际写入成功。三处证据互相咬合，指向同一种可能：这不是某个依赖包失控，而是发布流程里设计好的管线，目标人群正是「已经在用 Postman 桌面端」的存量用户。管线背后的 release/feature flag 与同意流程只有官方知道，作者六项诉求里的第四项就是要求披露它，以及这套机制还能改哪些 agent、哪些文件。从 10 月 25 日提交到 11 月 4 日核验，issue 一直挂在 open 状态，reaction 累积到 200 个，官方标签一个没有。对一个由官方组织账号维护的仓库来说，十天的沉默本身就是姿态。
作者的六项诉求值得完整列出：其一，按严重的产品同意与安全边界事件处理，而不是当文档问题；其二，在显式 opt-in 之前，停止对存量桌面用户自动安装 agent 插件与 CLI；其三，移除安装器侧的钩子自批，信任必须由用户在 agent host 里亲手决定；其四，披露 auto-existing-upgrade 背后的 release/feature flag 与同意流程，以及影响范围；其五，给出完整回滚路径（agent 配置、钩子信任、marketplace、缓存、MCP 连接、CLI 全覆盖），删除后不再重装；其六，把启动指令收窄到显式的 Postman 请求。
还有一层结构性问题：自批信任之所以能得手，是因为 agent 宿主的信任层本身太薄。一边是能写用户家目录任意配置的桌面软件，一边是信任记录可以被离线伪造的宿主，两者相遇，用户拿到手的只是一个「已安装」的结果。agent 生态的同意层是纸糊的，Postman 只是第一个被抓到的，宿主侧的漏洞细节见下文评论区一节。
官方口径对不上
先看营销页与桌面端行为的落差。Postman 官网下载页的插件区话术是「手动把插件加进你的编码代理」，示范的是两步命令（claude plugin marketplace add 与 install）。有网友对比网页存档后指认 Postman 修改了下载页表述；可以确认的部分是：2026-10-26 的存档页与 11-04 的当前页，两版都只有手动安装的营销区，均无任何自动安装披露。官网口径与桌面端实际行为脱节，这是可核验的事实。
再看 issue 本身的结构数据：26 条评论的 author_association 全部为 NONE，零 MEMBER、零 OWNER、零 COLLABORATOR 发声；零 label、无 assignee、无 milestone。截至发稿，Postman 未在该 issue 下正面回应。有网友转述，有人去 Discord 当面质问，得到的感觉是「他们似乎没当回事」（转述口径，无法独立确认）。作者自己也没有干等：他自述已在 r/postman_api、r/codex、r/ClaudeAI 三个 subreddit 发过帖，都没什么水花，直到 11 月 3 日被提交上 HN 才炸开。
传播变形也要单独对照：HN 的提交标题写的是「Postman attempts to share all API data」，但 issue 作者在正文里明确划界：本报告确立的是未经想要的集成与指令更改，不主张确立了数据外传。标题是提交者的措辞，比作者原话锋利得多。转发这件事的人，应该把两者分开。
评论区怎么说
HN 讨论近 300 条，把高赞立场转述成五路：
一、迁移潮是主线。有人说自己多年前就换了 Insomnia，一直在等听说 Insomnia 也出问题的那天；有人指出 Insomnia 8+ 强制云账号，官方给的理由是便于向你投广告；于是有人再迁 Yaak；迁 Bruno 的有好几个，其中一位自述是被 Postman 销售团队缠上之后离开的；讨论串里甚至有人现场自建了一个叫 librepost 的替代品。还有人建议团队干脆回退 curl 加 shell 脚本。
二、enshittification 论。有高赞评论给出这样的逻辑：一个工具能赚钱而又不牺牲产品、不剥削用户的时间越长，劣化就越慢；但病态贪婪一旦介入，终将要求榨干用户基础。静默自动安装正好被当成这条曲线的注脚。
三、钩子信任机制比想象中薄。评论区用户 foma-agent 对两家宿主做了本地验证（Codex CLI 0.162.1、Claude Code 2.1.302，一次性配置目录）：Codex 的 trusted_hash 配方是开源的，即钩子身份 sorted-key JSON 的 sha256，他用 Python 离线算出哈希、拿文本编辑器手写 hooks.state 记录，下次运行钩子直接触发，全程无人参与；Codex 还有一个 —dangerously-bypass-hook-trust 旗标；信任记录只钉钩子声明（命令串、事件、超时），不钉脚本内容，铸完记录再改脚本字节照跑；现行源码给 plugin hooks 加了 bundle 内容哈希，也就是第二个哈希，但用户自己声明的钩子脚本文件仍在所有哈希之外。Claude Code 连记录机制都没有：settings 文件里的钩子写入即生效，在一个从未信任过的目录里用 claude -p 跑 SessionStart 与 PreToolUse 钩子，直接触发（交互式会话有 folder-trust 对话框，-p 模式没有）。这段验证的含义是：Postman 的自批信任不是什么高难度操作，任何能写配置文件的脚本都做得到。
四、动机推测与改页指认。评论区用户 NuclEnergy 声称 Postman 事后修改了网页内容以推卸责任；按复核口径，能确认的是存档页与当前页都没提自动安装，插件区一直只写手动安装，具体改了什么无法完全确认。他还推测 Postman 的意图是监控 AI 发起的网络调用，试图把自己加进 allowlist 但失败了，Codex 和 Claude Code 都触发过告警，脚本写得很糙，差一点就完成静默安装（推测口径，不当定论）。他也发过带按钮的卸载钩子截图，自称不信任 Postman 的清理脚本，让 GPT 帮着清。
五、情绪面。有人直接说 Postman 是个病毒，有人问这么做合法吗，有人说企业环境里这种风险不可接受；有人把它比作 uTorrent：大家都装过，靠惯性留着；有人说它几年间从顺手的工具变成近乎病毒的东西，crazy 的是还有人用；有人算账：它卖的整套软件不过是一次 prompt 的价钱；还有人化用美国邮政格言讽刺：neither rain，nor sleet，nor consent。被引用最多的技术总结是：又一个「如何不该做开发者工具」的案例，关键词只有两个，透明、请求许可。
普通用户能做三件事
-
自查配置。 终端里 cat ~/.codex/config.toml，找 [marketplaces.postman]、[plugins.”postman@postman”] 和 hooks.state 条目；cat ~/.claude/settings.json 与 ~/.claude/plugins/installed_plugins.json，找 postman 相关记录；顺手看一眼 ~/.local/bin 里有没有多出来的 Postman 可执行文件。
-
查到就清理，清完要验证。 删除对应配置段与文件。评论区有人不信任官方卸载脚本，选择手动清理或让 AI 辅助清理；改完重启 agent 跑一次，确认钩子不再触发，才算清完。
-
把边界习惯立起来。 给编码代理装任何插件前，先读一遍它的 SessionStart 钩子内容；管团队的，把「桌面软件会改你 agent 配置」列进供应商风险评估。这次的主角是 Postman，机制层的漏洞对任何能写你家目录的软件都成立。
结语
分寸声明：本文不脑补、不定罪。指控核心是披露方自述，但日志路径、源码 revision 与 issue 结构数据都可复核；动机推测与改页指认全部来自网友，本文按原口径呈现，不升级为事实。确定能站住的只有三件：issue 十天零 label、零官方评论；两版下载页均无自动安装披露；HN 标题比 issue 作者的原话更锋利。对整个生态而言，无论官方最终怎么回应，这份 issue 已经把「桌面软件对 agent 配置的信任决定权归谁」这个问题钉在了台面上。
接下来盯两个节点：其一，Postman 官方回应，issue 的 label、评论、博客任一出现，本栏目即升级 v2；其二，Codex 与 Claude Code 是否收紧 -p 模式的钩子信任，foma-agent 验证出的是宿主侧漏洞，Postman 只是第一个被抓到的用户。48 小时窗口在 11 月 5 日 17:22Z 前后关闭，窗口内任一节点有动静，更新 v2。
参考来源
- GitHub issue postmanlabs/postman-app-support#14370（2026-10-25 由 indicava 提交；指控内容为作者自述口径，源码部分钉在 revision 6c8e452 可复核；state=open、26 条评论、200 个 reaction、零 label、无 assignee，为 11-04 API 核验快照口径）。
- Hacker News story 50354960（2026-11-03T17:22Z 上榜；核验口径超 900▲、近 300💬，数字仍在涨，正文不用精确值）。
- Postman 官网下载页对比（Wayback 2026-10-26 存档 vs 11-04 当前页，两版均只有手动安装营销区、无自动安装披露；网友「改页」指认按转述口径呈现，不定罪）。
- 评论区用户 foma-agent 对 Codex CLI 0.162.1 与 Claude Code 2.1.302 钩子信任机制的本地验证（评论区实测转述，本文未独立复跑）。
- issue 26 条评论 author_association 分布（11-04 API 核验：全部 NONE）。
署名：永亮