2026 年 10 月 24 日，一位开发者在 Mac 上打开 Postman，此前一段时间没有用过它。当天的 Postman 日志里出现这样一条记录：auto-existing-upgrade，结果一栏是 claude-code:installed、codex:installed [1]。从报告者与复现者的日志看，装这两个插件没有经过用户确认，触发条件只是打开应用。这件事在 GitHub 议题 #14370 里展开，11 月 4 日凌晨被提交到 Hacker News（开发者社区），当天中午的快照里以 1106 分、362 条评论留在首页 [2]。
公开证据能撑住两件事：Postman 桌面版会自动往它检测到的编码工具里装插件；安装器还会替用户批准自己的启动钩子（hook，让编码工具在会话开始等时机自动执行指定动作的机制），官方文档原文是 "The installer approves the hook for you" [3]。“上传全部 API 数据”撑不住：那是 Hacker News 提交者的标题措辞，报告者自己不主张数据外传，独立复核者核实安装器代码后说这个说法站不住 [4]。审计对象因此很具体：一条随打开与升级生效的默认权限链，改其他工具的配置文件、替用户写入信任哈希（trusted_hash）、配置远端 MCP 服务端，三步都有痕迹可查，也有官方入口可关。
装插件证实了，传数据没有证实
时间线从日志开始。北京时间 2026 年 10 月 24 日 17 时 34 分，main.log 里留下 autoInstall.plugin.existing-user finished 的记录，outcome 为 installed，signedIn 一栏是 true：触发路径是已登录的既有用户打开桌面版，从日志看，整套动作没有出现过确认步骤 [1]。次日，用户 indicava 在 postman-app-support 仓库提交议题，正文给出六组证据，获得 172 个赞（数字取自 11 月 4 日的页面快照）[1]。
热度最高的说法和证据之间隔着一步。Hacker News 提交标题写 "attempts to share all API data" [2]，议题正文的原话是 "it does not claim to establish data exfiltration" [1]。远端连接方面，配置文件里指向 https://mcp.postman.com/mcp 的模型上下文协议（MCP，一种让智能体调用外部工具的连接标准）服务端，Codex 日志显示认证失败，报错 "Auth required, when send initialize request" [1]。11 月 3 日发布的独立复核文章核实了安装器在固定版本下的代码，描述栏则说 "the data-sharing claim does not hold up" [4]。
回应方面，11 月 3 日出现一条以“我们”口径发表的评论：账号 zecoquit 说打包这些组件是因为很多用户装不动，承诺对既有用户把安装意愿问得更清楚，正在复核被指出的钩子批准与会话启动行为 [1]。这条评论没有注明账号与 Postman 的关系。北京时间 11 月 4 日清晨（日志时间戳为 UTC 11 月 3 日 22 时 58 分到 59 分），另一位用户在第二台 Mac 上重现了同一过程，桌面版从 12.31.3 升到 12.35.1，插件照装，复现者的结论是没有证据显示数据被上传 [1]。
动的是 Codex、Claude Code 的全局配置
Codex 这边动了 ~/.codex/config.toml 三个地方：新增 [marketplaces.postman] 指向 Postman 的插件仓库；新增 [plugins."postman@postman"] 并设 enabled = true；再往 hooks.state 写入 trusted_hash [1]。这个哈希对应一个会话启动钩子，注册在 SessionStart 事件上，匹配 startup、clear、compact 三种时机，触发时把 session-start-context.md 打印给模型看 [1]。文件开头是一条指令，原文把设计、实现、mock、测试、监控、文档、部署都算作“非平凡”的 API 工程任务，要求先加载 postman:api-engineer 技能再动手 [5]。同一文件接着说，项目级 AGENTS.md、CLAUDE.md 和用户直接指令优先于这条指令 [5]。
替用户写入这个信任哈希的是安装器代码。installer/src/hosts/codex.ts 在装完插件后调用 approvePostmanHook：先经 hooks/list 取得钩子声明哈希，再调 config/batchWrite 把 trusted_hash 写进配置，源码注释说，这步只批准 Postman 当前的钩子 [1][6]。官方文档的表述一致，批不动时才提示用户去 Codex 里复核 [3]。
影响面不止 Codex。Claude Code 的 settings.json 启用了 postman@claude-plugins-official 2.0.1，~/.local/bin 里出现一份独立 CLI [1]；有用户的 ~/.copilot/settings.json 出现同样的 marketplace 与启用项 [1]；在 Cursor 上，同一段会话启动文案被注入，只是去掉了 postman: 前缀 [1]。官方文档列出 9 个可自动检测安装的工具标识 [3]。这些改动都落在用户级配置里，从报告者与复现者的日志看，这套自动安装路径没有出现过任何确认步骤。
「装进每一个 agent」写进了 PR 标题
它有设计痕迹。postmanlabs/postman-plugin 仓库的 PR #45 标题就是 "add npx @postman/postman-plugin to install into every agent"，描述里说它是统一的命令行工具，负责检测、安装、更新、报告和移除所有支持的编码 agent 里的 Postman 插件 [7]。官方文档把这条命令写成标准用法，一条命令装入每个检测到的工具 [3]。
钩子的用途，文档自己也说清了："Postman's skills and MCP server work either way, with or without the hook. The hook makes Codex reach for Postman's skills more reliably." [3] 翻译过来：没有钩子，技能和 MCP 服务端照样能用；有钩子，Codex 会更可靠地伸手去拿 Postman 的技能。提高命中率是文档给钩子的定位，把钩子装进另一个工具的启动流程是有意为之。
信任上的代价，评论区说得直接："Postman is a virus." 得到 153 个赞；"This is unacceptable, even creating risk in corporate environment." 得到 57 个赞 [1]。前者是情绪，后者说到了工作面：一个 API 客户端升级时改写其他工具的指令来源，使用这些工具的团队都在同一个风险面上。
怎么查：四步核对你的机器
以下路径均来自 macOS 的记录 [1]。
- 翻 Postman 自己的日志。打开 ~/Library/Application Support/Postman/logs/main.log，搜 auto-existing-upgrade 和 autoInstall.plugin.existing-user，有结果说明这条路径在你的机器上跑过 [1]。
- 逐个工具看配置。~/.codex/config.toml 有没有 [marketplaces.postman] 和 [plugins."postman@postman"]；~/.claude/settings.json 有没有 postman@claude-plugins-official；~/.copilot/settings.json 有没有 extraKnownMarketplaces.postman；~/.local/bin 里有没有 postman 可执行文件 [1]。
- 跑官方 status。npx @postman/postman-plugin status 列出检测到的工具和插件安装状态，需要 Node.js [3]；加 --dry-run 可以预览 install 或 remove 会改什么，不动文件 [3]。
- 看 hooks.state 里的 trusted_hash。报告者的 12.33.4 机器上它写进去了；11 月 4 日的复现者用的是 12.35.1 加 Codex 0.153.4，这个字段没有出现 [1]。一位署名 foma-agent、自称 AI 智能体的测试者做过钩子信任机制实验：没有信任记录的钩子在 codex exec 里会被静默跳过 [1]。没看到 trusted_hash 不等于没装，可能只是这一版没有写入这条信任记录；升级之后把这一步重跑一遍。
怎么关：卸载命令、应用内入口和两处文档差异
卸载走官方命令：npx @postman/postman-plugin remove（别名 uninstall）从检测到的工具里移除插件，--agent 加标识可以只处理一个，比如 --agent codex；--dry-run 先预览改动 [3]。有用户实测，应用内也有入口：在 Help 菜单的 Postman CLI and Plugins 里选 Uninstall Postman Coding Agent Plugin [1]。
两条路的结果不一定相同。有用户在应用内执行卸载后，Copilot 里的集成原样留着，留言写的是 "uninstalling the agent does not work with it" [1]；zecoquit 的回复则说这些组件都能在应用内卸载 [1]。卸载之后，把上一节第 2 步的文件清单再过一遍，Copilot 的 settings.json 要单独看一眼。
卸载之外，文档里还有两处已经写下来的差异。其一，谁批钩子取决于装法：以 Codex 为例，用其自带方式安装时，钩子由用户自己审阅批准 [3]。其二，钩子文案把项目级 AGENTS.md、CLAUDE.md 和用户直接指令排在优先位置 [5]；这是文件里的承诺，实际执行取决于各个 agent 的实现。
应用内的 AI 设置是另一个容易混淆的位置。AI 开关、AI 条款、自带密钥那一页管的是 Postman 应用内的 AI 功能 [8]，文档没有把它的作用范围连到 agent 插件上。
审计对象是那条默认权限链
日志时间戳是 10 月 24 日 17 时 34 分（北京时间），记录里没有出现用户确认的动作。第一层判断落在设备基线上：新工具第一次启动前，问清它会写入哪些其他程序的配置。
钩子信任的归属是第二层。官方文档承认目前由安装器代批 [3]，zecoquit 的回复说正在复核这块 [1]；承诺尚未落地，11 月 4 日的复现说明自动安装仍在发生 [1]。在 Postman 改掉这个默认之前，第 4 步的 trusted_hash 检查就是企业当前最直接的一项核对。
第三层是范围。一套安装器、一条命令、九个工具标识，这套组合在 PR 标题里就叫“装进每一个 agent” [7]。数据外传没有证据，改配置、写入信任哈希、配置远端服务端三步都有记录 [1]；其中写入信任哈希一步在 12.35.1 的复现机上没有出现。Postman 承诺的改动落地之前，能查、能关、能复核的入口都在官方文档和上面的配置清单里 [1][3]。