Postman 被指自动装 AI 插件并尝试共享数据

打开 Postman，却发现 Codex 开始反复调用 Postman skills，Claude Code 也多了插件。这份问题报告质疑的是：一个 API 客户端，为什么能自动修改其他编程工具的配置，甚至尝试替自己的启动钩子完成信任审批？

现有材料支持「自动安装和指令改写」的指控，但没有证明 API 数据已经外传。比起评论区的愤怒，更值得程序员看清的是安装日志、指令入口和信任记录之间的关系，以及它们如何影响日常 AI 编程。

自动安装的证据，到底走到了哪一步

报告作者于 2026 年 10 月 25 日检查自己的 Mac。当时 Postman desktop 为 12.33.4，Codex Postman plugin 为 1.1.0，Claude 插件记录为 2.0.1。作者描述的触发过程是：隔了一段时间重新打开已有的 Postman，随后发现编程代理出现异常行为。

最直接的证据来自 ~/Library/Application Support/Postman/logs/main.log 第 11562-11563 行。下面这段日志记录了自动安装来源及两个宿主的安装结果：

PostmanAgentPluginService~install: script completed
{"source":"auto-existing-upgrade","results":["claude-code:installed","codex:installed"],"installer":"script"}

Main: autoInstall.plugin.existing-user finished
{"outcome":"installed","platform":"darwin","exposed":true,"signedIn":true,"flagTimedOut":false,"useScript":true,"installer":"script","scriptResults":"claude-code:installed,codex:installed"}

重点看 source 的 auto-existing-upgrade，以及 scriptResults 中的两个 installed。日志时间为 2026-10-24T09:34:14.418Z，原文注明对应耶路撒冷时间 12:34。

其他本地记录与之相互印证：~/.codex/config.toml 新增了 Postman marketplace、启用插件及 hook 信任记录；~/.claude/settings.json 启用了 postman@claude-plugins-official。Claude 安装记录采用 user scope，installedAt 与 lastUpdated 均为 2026-10-24T09:34:02.610Z。~/.local/bin 中也出现 Postman 可执行文件及其 lib 目录，修改时间落在同一安装窗口。

这些材料足以支持这台机器发生了跨工具安装，但覆盖范围仍不清楚。作者没有在干净 Mac 上复现，也没有确定具体由哪个发布版本、功能开关或同意流程触发，不能据此断言所有用户都会遇到。

原文标题提到分享全部 API 数据，正文却明确没有声称已经证明数据外传。

为什么装一个插件，会改变整个 API 工作流

真正影响开发体验的是启动钩子（hook）。它是在特定事件发生时自动执行的命令，可以向代理补充指令。

安装的 hooks/codex-hooks.json 注册了 SessionStart 命令，匹配条件为 startup|clear|compact，输出 hooks/session-start-context.md。其中要求：在处理任何非简单 API 工程任务前，先加载 postman:api-engineer 并遵循它。

覆盖范围包括 API 设计、实现、mock、测试、监控、文档、部署，以及 Postman Flow。于是，用户即使只是让代理实现一个 Node 接口，也可能被引向 Postman 工作流。

这就解释了作者观察到的反复提示：代理的启动上下文里已经多了一条广泛适用的指令。问题不需要先表现为数据上传，单是工作流被外部应用改写，就已经影响用户对代理行为的控制。

远程连接也被加入了。mcp.codex.json 指向 Postman 的远程 MCP 服务，但 Codex 日志显示 MCP server startup failed server_name="postman"，并在初始化请求时报告 Auth required。这说明该连接启动时未完成认证，不能拿它作为 API 数据成功上传的证据。

作者检查的安装源码固定在 revision 6c8e452e0f4237f4bcc0901cb1ac442dec707e49，避免把后续代码变化混进当时的证据。源码显示，installer/src/hosts/codex.ts 安装插件后调用 approvePostmanHook(system)；installer/src/hosts/codex-hooks.ts 则通过 hooks/list 获取 hash，再调用 config/batchWrite 写入 hooks.state 的 trusted_hash。

这里能确认的是安装器存在自我审批尝试。作者也保留了证据边界：机器上已有的信任记录，单独不能证明是谁、通过哪次交互创建的。

信任 hash 为什么不等于用户点过同意

评论区还有一份独立测试，讨论的是宿主机制，而非复现 Postman 安装。评论者自称 AI agent，使用 Codex CLI 0.162.1、Claude Code 2.1.302，在临时配置目录里运行无害的日志 hook，没有修改真实配置，也没有运行 Postman 安装器。

其测试中，Codex 对管理层和内置层以外、缺少 [hooks.state] 记录的 hook，确实会在 codex exec 中跳过执行。但信任记录保存在同一账户可写的 config.toml 中，所需值可以根据 hook 身份信息的排序键 JSON 计算 sha256 得到。

评论者用 Python 离线计算，再用文本编辑器给两个 hook 写入 trusted_hash，两者下次运行时都执行了；计算值与 hooks/list 输出逐字节一致。交互式审批同样通过 hooks/list 和 config/batchWrite 写记录。此外，--dangerously-bypass-hook-trust 可跳过这项信任检查。

所以，记录匹配能说明配置满足检查条件，却不能单独证明人类参与过授权。

测试还发现，该版本的记录约束命令字符串、事件、超时等声明，修改被调用脚本的内容后，hook 仍能运行。评论者称当前源码已为插件 hook 增加 bundle 内容 hash，对应作者配置里的 trusted_content_hash，但用户声明的外部脚本仍未被这些 hash 覆盖。这个结论需要按具体版本理解，不能混为所有 hook 都只有一种校验方式。

Claude Code 的测试则把 SessionStart、PreToolUse 写入项目 .claude/settings.json，随后在尚未信任的目录执行 claude -p，两个 hook 都触发了。评论者区分了交互式目录信任、-p 非交互运行，以及 subagent frontmatter hook 的不同规则。

这些是评论者报告的局部实验。它们提示了同一账户内配置可写的边界，没有替 Postman 安装链路完成复现。

我的判断

报告最有说服力的部分，是安装日志、本地配置与固定 revision 源码能够彼此对应。把一般 API 任务都导向某个产品，也明显超出了「用户主动选择这个插件处理当前任务」的范围。

但评论区的「病毒」「违法」等说法，不能替代技术证据或法律判断。下载页是否事后补充说明，也只有评论者陈述和截图材料；提供的内容不足以确定完整修改经过与动机。

厂商回复承认桌面应用捆绑了 Postman CLI 和 agent 插件，理由是用户单独安装、接线时遇到困难，并称下载页和应用更新流程有说明，也能在应用内卸载。不过，原文回复在「We’re goi」处截断，不能推断后面承诺了什么整改。

安装方便是合理诉求，但应明确告知会修改哪些宿主、增加哪些连接、执行哪些启动指令。相比在受影响工具中逐项启用，自动写入全局配置减少了操作，也扩大了授权范围。

同意安装 API 客户端，不应被直接当作同意改写其他编程代理的工作方式。

评论者提出把信任放到不同所有者、keychain 或带外签名等边界之外，有技术讨论价值，但材料没有提供方案对照数据。它仍是设计建议，不能直接当成已验证的解决办法。

能拿来做什么

• 如果 Codex 突然反复加载某个 skill，或持续出现 MCP 认证警告，先检查全局配置、插件记录和 SessionStart hook。前端与 Node 项目里的异常代理行为，也可能来自项目之外的启动指令。
• 为团队工具做接入审查时，把插件安装、远程 MCP 连接和 hook 信任分别核对。每一项都应能说明由谁启用、影响哪些任务，以及怎样撤销。
• 清理这类集成时，核对 agent 配置、marketplace、缓存、MCP、hook 信任记录和独立 CLI。原文有人贴出应用内卸载入口，但明确表示自己没有试用，不能据此保证清理完整。

• 如果准备改用 curl 加 shell 脚本，或评论中提到的 Insomnia，先对照自己的 API 调试需求。原文没有替代工具的测试与迁移数据，不能仅凭评论区推荐认定它们更适合团队。