大家好我是程序员老李。
今天的主角是大名鼎鼎的 Postman，Postman 最近有一个骚操作真的惹怒了全球开发者。
事情是这样的，一位开发者在 GitHub 上曝光，自己只是打开了一次 Postman，结果发现电脑上的 Codex 和 Claude Code 配置竟然被悄悄修改了。
Postman 不仅自动给这两款 AI 编程工具安装了自己的插件，还添加了 MCP 服务配置，甚至尝试绕过 Codex 原本需要用户确认的启动钩子信任机制。
消息曝光后，迅速引爆海外开发者社区。
11 月 3 日，相关讨论登上 Hacker News 首页，获得超过 1100 点支持，近 400 条评论。不少开发者表示无法接受这种行为，还有人直接卸载了 Postman。
而更让人意外的是，这并不是某个恶意插件偷偷干的事情，相关安装逻辑就写在 Postman 自己的代码里。
一、事情是怎么被发现的？
事情最早可以追溯到 10 月 24 日。一位名叫 indicava 的开发者，在自己的 Mac 上打开了已经安装的 Postman 12.33.4。
随后，他发现 Codex 开始出现一些奇怪的现象。
首先是日志里不断出现 Postman MCP 服务的身份验证失败信息。
其次，Codex 在执行 API 相关任务时，会主动加载 Postman 的技能，即使他并没有授权使用 Postman。
这行为让他感觉很奇怪，于是，他开始检查本地配置和 Postman 的运行日志，结果发现了一条非常关键的记录：
{"source":"auto-existing-upgrade","results":["claude-code:installed","codex:installed"]}
这条日志的意思很明确，Postman 在已有用户的升级流程中，自动完成了 Claude Code 和 Codex 插件的安装。
进一步检查后，他发现自己的 ~/.codex/config.toml 被添加了 Postman 插件市场地址，并将插件设置为启用状态。
与此同时，~/.claude/settings.json 也启用了 postman@claude-plugins-official 插件。
甚至连 Postman 的命令行工具，也被安装到了本地目录。而这些操作，都不是他主动发起的。
10 月 25 日，他将整个调查过程、日志和源代码证据发布到 Postman 官方 GitHub 仓库，创建了 Issue #14370[1]。
二、真正惹怒开发者的，是它竟然自己给自己授权
如果只是自动安装插件，这件事可能还停留在软件捆绑安装的争议上。但接下来发现的配置信息，让问题变得更加严重了。
Postman 竟然给 Codex 安装的插件包含了一个名为 SessionStart 的启动钩子。简单理解，就是每次启动 Codex 会话时，自动执行一段预设逻辑。
正常情况下，Codex 对第三方启动钩子设置了信任确认机制的，用户需要手动审批之后才能允许它执行。
但 Postman 的安装器里，竟然专门写了一个叫 approvePostmanHook 的函数。
这个函数会调用 Codex 的 hooks/list 接口获取钩子信息，再通过 config/batchWrite 将自己的 trusted_hash 写入配置。
也就是说，Postman 的安装器尝试替用户完成了原本应该由用户决定的信任确认。这相当于一个软件安装完插件后，又顺手帮自己点了一个“我已信任”，这简直就是病毒木马的操作啊。
更有意思的是，Postman 的官方安装文档也明确描述了这种行为：使用自动检测智能体的安装方式时，安装器会代替用户批准 Codex 的启动钩子。
这可不是开发者凭空猜测，而是源代码和官方文档都能对应上的设计。
三、它还试图修改 Codex 的默认工作方式
事情到这里还没有结束，开发者继续检查启动钩子的内容，发现里面有这样一条指令：
<EXTREMELY_IMPORTANT>
紧接着，插件要求 Codex 在处理非简单的 API 工程任务之前，优先加载 postman:api-engineer 技能。涉及的任务包括 API 设计、开发、模拟、测试、监控、文档和部署等。
注意，这里的触发条件并没有要求用户必须明确提到要使用 Postman 时才执行。是只要 Codex 判断当前任务属于 API 工程范畴，就可能按照这条启动指令，优先使用 Postman 提供的工作流程。用户可能压根不知道自己的智能体已经被加入了这样一段额外指令。
对于现在越来越依赖 AI Agent开发软件的工程师来说，这就很值得警惕了。因为过去的软件插件，更多是在用户主动调用时才执行某项功能。
现在的智能体插件，却可能通过启动钩子直接影响 AI 的任务判断和工具选择。一个本来只负责接口调试的软件，开始试图改变整个 AI 编程工具的工作流程。而这些变化用户甚至可能毫不知情。
另外，插件还配置了 Postman 的远程 MCP 服务：
原始报告中的连接因为缺少身份验证而失败，才导致用户发现 AI Agent 在未得到用户授权的情况下私自连接到了 Postman 的 MCP 服务。
很多开发者真正担心的是，如果第三方软件能够自动增加远程连接，并修改智能体的执行规则，那么以后谁来控制这些工具可以访问哪些数据？
如果它通过指令要求 AI Agent 安装某些恶意软件又该怎么办？甚至上传用户私有密钥或本地账户信息呢？
之前老李就写过一篇文章，有人恶意伪造 AGENTS.md 文件，让 Codex 执行恶意指令 ： 离了个大谱！一个 13KB 的 Markdown 文档，竟让 Codex 主动安装了恶意软件！ ，现在竟然有用户量这么大的软件私自更改用户 AI 的配置。
四、事情曝光后，社区彻底炸了
10 月 25 日提交的 Issue，到了 11 月 2 日、3 日开始引发大量讨论，有人直接在评论区把 Postman 称为病毒。
也有人表示，这种行为放到企业开发环境中，可能带来严重的安全风险。
还有开发者指出，自己已经不再信任 Postman，准备转向 Bruno 等更轻量的接口调试工具。
11 月 3 日，另一位开发者又提供了一份新的安装记录。
这次涉及的是 Postman 12.35.1。
他原本使用的是 12.31.3，在打开 Postman 后，应用自动升级到 12.35.1，随后再次触发了自动安装流程。
日志显示，Postman CLI、Claude Code 和 Codex 插件都被安装了。
11 月 4 日，又有开发者在 Issue 中报告，自己的 GitHub Copilot CLI 配置也出现了 Postman 插件条目，并反映通过 Postman 菜单执行卸载没有成功清除相关配置。
这进一步引出了另一个问题：Postman 到底会修改多少种开发工具？卸载时又能不能彻底恢复原来的状态？
五、Postman 官方终于回应了
随着争议不断扩大，Postman 方面在 11 月 3 日给出了回应。
根据媒体 RuntimeWire 的报道，Postman 产品负责人 Sarabmeet Kallar 通过公关渠道解释了这次插件安装行为。
Postman 的理由是，过去很多用户在单独安装和配置命令行工具、智能体插件时遇到了困难，因此团队决定把这些组件与桌面客户端一起提供，以简化安装流程。
Postman 方面还表示，下载页面和应用更新流程中已经提及这些功能，用户也可以在应用内卸载相关组件。
但显然，开发者们并不接受这种解释。
因为软件更新时展示过说明，和用户明确同意修改另一个软件的配置，完全不是一回事。
Postman 随后表示，将重点改进两个方面：
第一，让用户授权安装的过程更加清晰，尤其是已经安装 Postman 的老用户。
第二，重新审查启动钩子的自动批准机制，以及会话启动时注入指令的行为。
Postman 支持仓库的 Issue 评论区，也出现了相同内容的回应。
但截至 11 月 4 日，官方还没有公布完整整改版本、上线时间或对应的修复提交，Issue #14370 仍处于开放状态。
六、Postman 接下来应该怎么改？
从目前的回应来看，Postman 已经意识到开发者对这种行为的不满，但真正需要解决的并不是把授权弹窗做得更明显。
我认为至少涉及三个改动。
首先，插件安装必须由用户主动选择。
无论是新用户还是老用户，打开 Postman、更新 Postman，都不应该自动成为安装 Codex、Claude Code 等第三方插件的理由。
其次，启动钩子的信任必须交还给 Codex。
Postman 可以提供插件和安装说明，但是否信任它的启动钩子，应该由用户在 Codex 中完成审核，而不是由插件的安装器替用户批准。
最后，卸载必须能够完整恢复环境。
如果 Postman 修改了插件市场、启动钩子、信任记录和 MCP 配置，那么卸载时就应该能够准确撤销自己创建的内容，而不是留下配置文件让用户手动处理。
这些也是原始 Issue 作者提出的核心整改要求。
目前 Postman 承诺的是改善授权流程、审查启动钩子行为。上述完整方案是否会被采纳，还需要看后续发布的代码和版本更新。
对于开发者来说，如果电脑上同时安装了 Postman、Codex 或 Claude Code，可以先检查：
~/.codex/config.toml
~/.claude/settings.json
~/.claude/plugins/installed_plugins.json
看看是否存在自己没有主动安装的 Postman 插件、启动钩子和远程 MCP 配置。
实际上，这次 Postman 最让开发者反感的，并不是它给 AI 编程工具开发了插件。
在 AI Agent 越来越普及的今天，API 调试工具与智能体打通，本来是一件很正常的事情。
真正的问题是，Postman 把原本属于用户的选择权，变成了软件升级时自动执行的操作。
以前我们安装一个软件，担心的是它偷偷捆绑其他软件。
现在情况更复杂了。
一个软件不仅可以安装插件，还能够修改另一个 AI 工具的配置，甚至影响它以后如何理解任务、选择工具和执行工作。
而当越来越多的软件都开始接入 AI Agent，这种跨应用修改配置和信任状态的行为，显然不会只发生在 Postman 身上。
参考资料
[1] Issue #14370: https://github.com/postmanlabs/postman-app-support/issues/14370
[2] GitHub 原始 Issue #14370: https://github.com/postmanlabs/postman-app-support/issues/14370
[3] Postman 启动钩子安装器源码: https://github.com/postmanlabs/postman-plugin/blob/6c8e452e0f4237f4bcc0901cb1ac442dec707e49/installer/src/hosts/codex-hooks.ts
[4] Postman 会话启动指令源码: https://github.com/postmanlabs/postman-plugin/blob/6c8e452e0f4237f4bcc0901cb1ac442dec707e49/hooks/session-start-context.md
[5] Postman 官方插件安装文档: https://learning.postman.com/docs/postman-plugin/install/detected-agents/
[6] Postman 产品负责人回应报道: https://runtimewire.com/article/postmans-head-of-product-says-it-will-make-ai-agent-plugin-o-7933b7
[7] Hacker News 热门讨论: https://news.ycombinator.com/item?id=50354960