Postman 悄悄给 Codex 装插件,还试图静默批准钩子

导读：用户报告 Postman 更新后自动向 Codex 和 Claude Code 安装插件。Codex 原本要求用户审核插件钩子，Postman 安装器却主动代用户批准自身钩子；不能把这套机制直接套用到 Claude Code。不同环境下能否批准成功，不否定已存在的流程，也不等于已经发生数据外传。

硬核老摩王4537 字 · 约 12 分钟

你打开一个 API 工具，却发现另一个编程助手的配置变了。

后者不只是多了一个可选功能。新装进去的启动指令，还会引导它在处理 API 工作时，优先使用前者提供的技能。

如果这是用户主动选择的集成，它可以很有价值。如果它随着一次普通更新发生，性质就不同了。

这正是 Postman 最近这场争议值得注意的地方。

打开的是 Postman，改变的却是 Codex 和 Claude Code

10 月 25 日，一名用户在 Postman 官方支持仓库提交了 问题报告^[1] 。他称，打开 Mac 版 Postman 后，发现 Codex 出现 MCP 授权提示，并开始反复把 API 工作引向 Postman 技能。

他提供的日志中，安装来源标为“auto-existing-upgrade”，结果包含 Claude Code 和 Codex 插件安装成功。报告涉及 Postman 12.33.4。

这里需要先划清证据边界：这是用户提交的日志与配置记录，不是我们在干净环境中完成的独立复现。它足以要求厂商解释，却不能直接推导成“所有用户更新后都会遇到同样的情况”。

但这件事也不只是一个无法核实的网络传闻。关于安装器如何处理 Codex 的信任设置，Postman 自己提供了更直接的材料。

Claude Code 也在安装记录里，但不能混成同一套机制

这次报告涉及的不只有 Codex。报告者还列出了 Claude Code 的本地配置证据：settings.json 中启用了 postman@claude-plugins-official，installed_plugins.json 则记录了用户级安装的 Postman 插件，版本为 2.0.1。安装时间与最后更新时间相同，均为 2026 年 10 月 24 日 09:34:02 UTC。

这些是 原始问题报告^[1] 中公开的记录。它们与前面的安装日志相互对应，说明报告者发现的跨软件安装，同时涉及 Claude Code 和 Codex，并非只向一个助手加入插件。

但两者不能被混写：Claude Code 的安装和启用记录，不等于它使用了与 Codex 相同的钩子信任机制。 下文关于查询钩子、写入 trusted_hash、代用户批准的分析，依据的是 Codex 路径的官方文档与源码，不能直接套用到 Claude Code 上。

就 Claude Code 而言，当前可以明确讨论的是报告中的自动安装、用户级插件启用，以及这是否经过用户明确同意。至于具体启动行为和权限流程，不能仅凭另一种 Agent 的实现替它下结论。

Codex 原本要用户批准，Postman 却尝试替自己批准

先看 Codex 原本怎么处理这件事。

OpenAI 的官方插件文档^[2] 明确说明：安装或启用插件，不会自动信任插件附带的钩子。这类钩子属于非托管钩子，Codex 会跳过执行，直到用户审核并信任当前的钩子定义。

这里不是说所有钩子每次运行都要弹窗确认，而是说，安装插件与批准它的钩子，是两个不同的决定。

所谓会话启动钩子，可以理解为会话启动时执行的一项扩展机制。在这个插件中，它用于向 Codex 提供额外的工作指引。

Postman 自己的 按 Agent 安装文档^[3] 也证实了这条边界：从 Codex 应用或命令行安装时，钩子初始不受信任，下一次启动会显示“Hooks need review”，让用户审核；如果更新改变了钩子，还需要重新审核。文档同时说明，通过 ChatGPT 直达链接安装的已发布插件不带这个钩子，因此没有相应提示。

但换成 Postman 的 自动检测 Agent 安装器^[4] ，处理方式就变了：它会替用户批准 Codex 的会话启动钩子；如果无法完成，才会告诉用户去 Codex 中审核。之后钩子有变化，也可以重新运行安装器完成批准。

对应的 固定版本源码^[5] 中，确实存在这套执行流程：通过 Codex app-server 查询钩子，再尝试写入包含 trusted_hash 的信任状态，并检查结果。

这不是“将来可能添加”的功能，而是已经写进安装器、由安装流程主动执行的代为批准机制。 不同环境下，这一步能否成功可能不同；执行失败，不会把主动代用户批准这件事变成不存在。另一方面，不能单凭这段代码断定每个用户的安装都批准成功，也不能断定某条已有信任记录一定由它生成。

最值得批评的差别就在这里：Codex 原本把对当前钩子的审核留给用户，Postman 的安装器却尝试替用户完成它自己所提供钩子的信任批准。

Postman 文档还明确说，技能和 MCP 功能没有这个钩子也能工作。因此，代为批准不是让插件具备基本功能的必要条件。

提供扩展的一方，不应因为技术上能够写入信任记录，就把自己变成替用户批准这个扩展的一方。

它改变的不只是配置，还有助手的工作倾向

这些启动指令究竟做什么？

在 对应版本的指令文件^[6] 中，Postman 要求 Codex 在处理非简单的 API 工程任务前，先加载它的 api-engineer 技能。覆盖范围包括设计、实现、模拟、测试、监控、文档和部署。

文件也保留了例外：纯问答、微小修改不在此列；用户的明确要求和项目指令优先。

因此，把它描述成“Postman 已经完全控制 Codex”，并不准确。更准确的说法是：这组指令试图改变 Codex 处理一大类任务时的默认路径。

这已经足够重要。

我们选择一个编程助手，不只是选择它能调用哪些工具，也在选择它如何理解任务、优先使用什么方法。当一个外部软件把自己的工作流放进这条路径，用户理应明确知道，并决定是否接受。

“以后可以关掉”不能替代安装之前的选择。尤其当变化发生在另一个软件里，用户甚至未必知道该去哪里找。

平台可以扩张，用户的授权不能跟着默认扩大

很多人对 Postman 的印象，仍然是那个发请求、看响应、调试 API 的工具。把它称为“简单网关”并不准确，它也早已发展出协作、测试和企业管理等平台能力。

早在 2021 年的 D 轮融资公告^[7] 中，Postman 就宣布融资 2.25 亿美元，估值达到 56 亿美元。这个数字是当时的融资估值，不是今天的市值。

这样的背景有助于理解它为什么会进入开发者工作流的更多环节。2026 年 9 月发布的 Codex 插件介绍^[8] ，也清楚展示了它把 API 能力带入编程助手的产品方向。

扩展业务本身没有问题。用户主动把 Postman 接入 Codex，也完全合理。

但融资规模、平台战略和产品便利，都不能回答最重要的那个问题：用户究竟同意了什么？

同意更新 Postman，不应被默认解释为同意它修改其他 Agent 的配置。即使用户同意安装插件，也不应含糊地把它扩大成“插件提供者可以替我批准启动指令”。

在操作系统权限允许的情况下，一个程序可能有能力改写另一个程序的配置文件。技术上做得到，不代表产品上就应该这样做。

批评要准确，不需要靠“已经泄密”加码

这件事最容易被混在一起的，是四个不同阶段：插件安装、钩子获得信任、远程服务授权，以及数据实际传输。

前面发生了，不代表后面必然发生。

原始报告明确表示，它没有证明数据外传。后续不同版本的用户反馈，也没有呈现完全一致的结果：有人报告插件仍被自动安装，但没有看到相同的钩子信任记录。

这些差异需要继续核实。安装范围、默认开关、受影响版本以及修复情况，都不能靠一条帖子补齐。

我们也不必为了批评 Postman，把尚未证实的推测写成结论。将事件直接称为“窃取密钥”，既超出了现有证据，也容易让真正需要回答的问题被争吵淹没。

Postman 应当说明：哪些情况下会触发跨 Agent 安装，用户在哪里明确同意了这些变化，为什么安装器要代为批准钩子，以及如何完整撤销这些修改。

用户需要的是具体解释和可验证的修正，而不只是“集成能提高效率”。

我安装 Postman，是让它帮助我处理 API。是否让它进入 Codex 或 Claude Code、在什么时候进入、获得什么权限，应当由我决定。

一个工具越想成为平台，就越应该尊重其他工具和用户授权之间的边界。

参考链接

1. 问题报告 ｜ 链接：https://github.com/postmanlabs/postman-app-support/issues/14370

2. OpenAI 的官方插件文档 ｜ 链接：https://developers.openai.com/plugins/build/plugins

3. 按 Agent 安装文档 ｜ 链接：https://learning.postman.com/docs/postman-plugin/install/per-agent

4. 自动检测 Agent 安装器 ｜ 链接：https://learning.postman.com/docs/postman-plugin/install/detected-agents

5. 固定版本源码 ｜ 链接：https://github.com/postmanlabs/postman-plugin/blob/6c8e452e0f4237f4bcc0901cb1ac442dec707e49/installer/src/hosts/codex-hooks.ts

6. 对应版本的指令文件 ｜ 链接：https://github.com/postmanlabs/postman-plugin/blob/6c8e452e0f4237f4bcc0901cb1ac442dec707e49/hooks/session-start-context.md

7. 2021 年的 D 轮融资公告 ｜ 链接：https://blog.postman.com/postman-announces-series-d/

8. Codex 插件介绍 ｜ 链接：https://blog.postman.com/postman-plugin-for-openai-codex/