# Postman 的安装器，想替用户批准自己的 AI 指令 **Summary:** Postman 12.33.4 装好 Codex 插件后，会试着把自家启动 hook 的哈希写进 Codex 的可信记录，全程不问用户。这个 hook 会改变智能体处理 API 任务的方式。现场证据只有一台 Mac，这套现象也没在干净系统上复现过，但安装器代码公开可查。我认为，装集成和批准长期生效的指令应当是两次分开的决定。 - Canonical: https://markhuang.ai/zh/news/postman-installer-self-approves-ai-hook - Language: zh-CN - Author: [Mark Huang](https://markhuang.ai/about) - Published: 2026-11-03 - Section: News - Tags: Postman, Codex, Claude Code, AI 插件授权, Hook 信任配置 - Source: [GitHub / Postman App Support](https://github.com/postmanlabs/postman-app-support/issues/14370) - License: https://creativecommons.org/licenses/by-nc/4.0/ --- ![一只橙色的软件包裹，用绑在自己箱子上的机械臂，在随附的许可单上盖下对勾](https://cdn.markhuang.ai/news/postman-installer-self-approves-ai-hook/hero.webp) *示意图：Postman 的安装器一边装插件，一边试着批准插件带来的启动 hook。* 10 月 25 日，[一份针对 Postman 12.33.4 的报告](https://github.com/postmanlabs/postman-app-support/issues/14370)里，有开发者说自己只是打开应用，Codex 和 Claude Code 就都出现了意料之外的改动。Postman 是一个 API 客户端，用来测试软件服务之间怎么通信。按这位开发者的说法，它往两个编程智能体里都装了集成；之后 Codex 弹出认证警告，还反复加载 Postman 的 API 技能。 我最在意的一点，反倒不用看日志：翻一眼它附上的安装器代码就能确认——装完 Codex 插件后，Postman 会试着把自己那个启动 hook 标成已信任。在我看来，装一个集成，和批准它长期生效的指令，本该是两次分开做出的选择。两件事都交给安装器代办之后，一个“已信任”的 hook 就说明不了用户是否选过这些指令。 启动 hook 会在智能体会话开始时运行，也会在某些配置好的会话事件里触发。它负责告诉智能体该用哪些技能。这些指令会影响到 Postman 窗口之外的工作，所以值得先单独过一遍再批准。 ## 日志只有一台 Mac，代码谁都能查 报告作者 indicava 贴出了桌面端日志片段，里面有 `auto-existing-upgrade` 字样，还有结果显示 Claude Code 和 Codex 都已被安装。他还提到用户级的配置改动、一个远程 Postman 连接，以及单独装上的 Postman CLI。报告自己也说，这套现象还没在干净的 Mac 上复现过。 现场证据只涉及一台机器。不过公开源码能回答另一个问题：安装器被设计成会做什么。在报告者指出的那个提交里，[Codex 的安装流程](https://github.com/postmanlabs/postman-plugin/blob/6c8e452e0f4237f4bcc0901cb1ac442dec707e49/installer/src/hosts/codex.ts)加完插件后会调用 `approvePostmanHook`。[这个批准函数](https://github.com/postmanlabs/postman-plugin/blob/6c8e452e0f4237f4bcc0901cb1ac442dec707e49/installer/src/hosts/codex-hooks.ts)先取 hook 当前的哈希，再试着把这份哈希写进 Codex 已信任 hook 的记录里。 这能确认代码里确实有一次批准动作。但确认不了这几件事：报告者那台 Mac 上的信任记录是谁写下的，是不是每个 Postman 用户都经历过同样的安装，别处有没有出现过同意提示。这条界线报告者自己划得很清楚，报告里也写明，它并不构成数据外泄的证据。 ## 启动指令能影响的范围，远不止一次 Postman 请求 这个固定提交里的[启动文本](https://github.com/postmanlabs/postman-plugin/blob/6c8e452e0f4237f4bcc0901cb1ac442dec707e49/hooks/session-start-context.md)要求智能体：接到任何不算简单的 API 工程任务时，先加载 Postman 的 API 工程技能，再动手回应。它划定的范围包括 API 的设计、实现、测试和文档。纯提问和改一行代码这种小事不算在内，文本也写明用户自己的指令优先。 也就是说，用户直接说出口的要求还是管用。可对一整类工作，它先把默认选项定好了，哪怕用户从没提要使用 Postman。提供一个集成，和让这个集成成为智能体做通用 API 任务的默认起点，差别不小。 这个集成本身有它的用处。[Postman 的 README](https://github.com/postmanlabs/postman-plugin/blob/6c8e452e0f4237f4bcc0901cb1ac442dec707e49/README.md) 讲的是把 API 规范、集合和相关文件跟应用代码放在一起，方便智能体直接读写。真打算按这套方式干活的团队，大概也不介意技能被自动选中。我只希望这个选择里多算一条：先知道这个集成往智能体里加了哪些指令。 ## 哈希对得上，不等于用户点了同意 这段批准代码里加了几道检查：只认 Postman 自己的 hook，会确认指令文件里确实有内容，写入前再核一遍哈希没变。这些检查能避免在操作过程中批准到别的内容。但代码就这么一路走到底，从头到尾没问用户一句：你信不信任它。 README 在这件事上坦白得少见：没有单独的 hook 确认弹窗，也不会把指令内容整个摊开给人看。它还说明，hook 的 API 不可用时，安装照样继续。也就是说，批准这一步在文档里本来就是明说的。 在同一个提交里，这条路径长这样： ```mermaid flowchart TD A["安装 Codex 插件"] --> B["检查 Postman 的启动 hook"] B --> C{"hook 符合条件且检查通过？"} C -->|"是"| D["尝试写入 trusted_hash"] D --> E["确认批准有没有生效"] C -->|"否"| F["跳过批准，或输出一条说明"] ``` 我反对把批准这一步塞进安装器。哈希只能说明这是哪一份内容，说明不了用这个智能体的人有没有选择接受它。如果这个集成会改变智能体的默认工作方式，我就希望批准发生在受影响的那个智能体里，而且指令当场就能读到。 ## 指令的问题和连接的问题，分开查 [Hacker News 上的讨论](https://news.ycombinator.com/item?id=50354960)里，不少人在抱怨 Postman 越做越杂，也有人顺手推荐替代品。能看出来的只是对产品方向的不满——关于这次安装本身，讨论里既没有独立复现，也没有数据被窃的证据。 [同一份 README 还讲了数据发布](https://github.com/postmanlabs/postman-plugin/blob/6c8e452e0f4237f4bcc0901cb1ac442dec707e49/README.md#how-postman-builds-context)：Postman 文件夹连上 workspace 之后，测试结果、请求活动这类由命令行产生的记录会发布到那个 workspace。它还提到一个托管的 MCP server，智能体可以借这个连接调用 Postman 的工具。这两条通道文档里都写着，但该按各自的性质单独评估。不过，建了一个远程连接、或者出现过一次认证失败，都不能证明所有 API 数据都被传走了。 如果有人在智能体里撞见 Postman 的意外行为，我会先清点三样东西：插件本身、它带来的启动指令、当前的信任状态；看完这些，再去查远程连接和那个单独安装的 CLI。想直接卸载了事之前，还得问：卸载会清掉这些改动吗？下次打开桌面端，会不会又给你装回来？报告里要求的是彻底回滚，我还没测过。 [OWASP 对“过度代理”的建议](https://genai.owasp.org/llmrisk/llm062025-excessive-agency/)是限制扩展和权限，并把授权检查放进真正执行动作的系统里。我在[之前分析智能体联网](/news/claude-no-internet-live-network)时也是这个立场：边界得由系统强制执行。放到 Postman 这个集成上，我希望运行智能体的那个程序先把启动指令摆出来，让用户接受或拒绝，然后才让这些指令去影响一次会话。