打开Postman后,两个AI编程工具的配置变了:一份报告引发追问

打开一个 API 工具后， Codex 和 Claude Code 的配置也发生变化——这是开发者在 Postman 官方支持仓库提交的问题报告中描述的经历。

报告者称，他在一台 Mac 上打开 Postman Desktop 后，发现编程助手反复加载 Postman 的 Skill ，并出现 MCP 身份验证提示。检查日志和配置后，他报告看到了插件、会话启动指令、远程 MCP 连接以及单独安装的命令行工具。[S1]

这份 10 月 25 日提交的问题单，讨论的核心不是 AI 是否会写 API ，而是：一个应用能否在用户没有明确要求时，改变另一个工具的工作方式？需要先说清范围：这是报告者对特定机器与版本的记录，不是对所有 Postman 安装的调查，也没有证明数据被窃取。

发现了什么

报告列出的环境是 macOS 上的 Postman Desktop 12.33.4 。作者贴出应用日志，称一次现有用户升级流程记录了 Claude Code 和 Codex 插件安装；他还列出 Codex 用户级配置中的插件和 hook 信任记录。[S1]

Hook 可以理解为特定时机自动触发的一段程序。这里的会话启动 hook 会提供一段上下文，要求助手在处理非简单 API 工程任务前加载 Postman 的相关 Skill 。报告链接到对应版本的公开插件文件，文件确实包含这类指令。[S1][S2]

这能解释为什么工具可能在用户没有直接点名 Postman 时提到它，但不能仅凭文本断言每次任务都会实际执行某项操作。插件是否被加载，还取决于具体环境、配置和产品行为。

最值得追问的是授权边界

报告还分析了安装器源码，称其中存在为自身启动 hook 写入信任信息的尝试。报告作者自己也特别区分：源码可以支持“尝试批准”的分析，但配置里的信任记录本身，不能单独证明某个具体的用户交互过程。[S1]

这一区分很重要。启动指令改变的是 Agent 会看到什么、倾向使用什么工具；它不自动等于凭据泄露，也不自动证明任何一次网络传输成功。原报告明确表示没有声称证明数据外传。

Postman 官方文档介绍了在不同编码助手中安装插件的方法。[S3]不过，文档描述的是安装能力，并不能单独证明报告者的机器上出现过哪种同意界面。本篇没有在本机复现，也未将评论当作实测。

使用者现在可以检查什么

如果你同时使用 Postman 和编码助手，可以先查看助手的插件列表、 MCP 连接与启动 hook ，确认每项是否由自己或组织授权。发现不认识的集成，先记录名称和来源，再参考产品文档或组织管理员提供的方式处理；检查后重启会话，确认状态是否符合预期。

不要只因为看到了一个插件就推断所有文件或账号都受影响。版本、系统和安装路径都可能不同；企业设备应遵循变更流程。

这份报告把一个容易忽略的问题摆到了台面：当软件可以向 AI 工具添加技能、连接和启动指令时，用户需要看得见这些变化，也需要能决定是否启用。是否存在更广泛影响，仍要等待更多可核查证据。

来源

[S1] GitHub 问题单， 2026-10-25 ： https://github.com/postmanlabs/postman-app-support/issues/14370 [S2] Postman 插件指定版本文件，发布日期未知： https://github.com/postmanlabs/postman-plugin/blob/6c8e452e0f4237f4bcc0901cb1ac442dec707e49/hooks/session-start-context.md [S3] Postman 官方文档，发布日期未知： https://learning.postman.com/latest-v-12/docs/postman-plugin/install/overview