Codex 老蹦 Postman 插件？三步查清谁动了配置

最近几天如果你的 Codex 开工前总要先加载 postman:api-engineer 技能，或者 Codex、Claude Code 里反复弹 MCP 认证报错，先别急着重装工具。你可能从没装过 Postman 插件，但只要这台电脑上有 Postman 桌面版，这些配置多半是在你打开 Postman 的那一刻被写进去的。

Postman 是接口调试领域的老牌工具，装了它又用上 AI 编程工具的开发者，这几个月只多不少。撞上的人一开始只会觉得工具犯抽，报错复现不了、技能来路不明，很少有人会想到去翻另一个软件写的配置。

一、发生了什么

10 月 25 日，有用户在 Postman 官方仓库提交了 issue 编号 14370 的报告。他在 10 月 24 日打开闲置已久的 Postman 桌面版（12.33.4），Postman 自己的日志 main.log 里留下了记录，来源标着 auto-existing-upgrade，结果一栏写着 claude-code:installed、codex:installed。另一台机器从 12.31.3 升级到 12.35.1 后也出现了同样的安装记录，说明不止一个版本有这个行为。

被改动的不止一个文件。~/.codex/config.toml 里多了三段：一个指向 postman-plugin 仓库的 marketplace，一个插件启用开关，还有一条带 trusted_hash 的 hook 信任记录。这条 hook 会在 Codex 每次启动时打印一段指令，让模型在处理不简单的 API 工程任务时都去加载 Postman 的技能，设计、实现、mock、测试、监控、文档、部署全算在内。

更过分的是安装器的源码。装完插件，installer/src/hosts/codex.ts 会调用 approvePostmanHook，自己去拿 hook 哈希、往配置里写入信任记录。也就是说它不光装，还试图替你按下「信任」这个键。报告者特意说明，文件里的信任记录不能证明具体是哪次操作写入的，但安装器里这段代码确实存在。

有人会问，装了 hook 为什么我没看见？这跟两个工具的机制有关。有开发者在 issue 里做了对照测试：Codex 这边，一条 hook 声明如果没有持久化的信任记录，命令行模式下会被静默跳过，所以很多人中招了但毫无感知；Claude Code 那边走的是启动时的审查流程，需要用户点头才生效。同一套安装动作，在两家工具上的表现完全不同，这也是这次事件被忽略了近十天、直到 11 月 3 日才在社区炸开的原因之一。

至于 Postman 为什么能装进来，靠的是这些 agent 工具自己的插件市场机制。Codex 和 Claude Code 都支持第三方插件源，本意是给开发者和社区用的，Postman 把自己注册成了一个插件源，再借桌面版的启动时机自动完成安装。工具的开放性没有错，错在把它当成了绕过用户同意的入口。

Claude Code 和 Copilot 也没躲开。~/.claude/settings.json 里被启用了 postman 插件（2.0.1 版），~/.local/bin 里多出一个 Postman CLI。11 月 4 日又有用户贴出 ~/.copilot/settings.json 里的 postman 字段。三个主流 agent 工具，一次全给配上了。

11 月 3 日 Postman 方面在 issue 下回应，说捆绑 CLI 和插件是帮用户省掉手动配置，会重新审视 hook 自批准和开机注入的行为，把选择提示做得更清楚。截至 11 月 4 日，能关掉自动安装的新版本还没发布，issue 下面已经堆了四十五条评论，骂声从「病毒」一路排到「直接停服」。

二、第一步：三处文件自查

什么人要查：机器上装着 Postman 桌面版，同时用过 Codex CLI、Claude Code、GitHub Copilot 任意一个的。三个都用过就挨个查，别只查一个。

Codex 的配置在 ~/.codex/config.toml，Windows 用户对应 C:\Users\你的用户名.codex\config.toml，打开搜 postman。命中的话会看到 marketplace、插件启用和 hooks.state 三段内容。

Claude Code 查两个文件：~/.claude/settings.json 里的插件字段，以及 ~/.claude/plugins/installed_plugins.json，后者会记着版本号和安装时间。Copilot 查 ~/.copilot/settings.json，同样搜 postman。

拿不准自己是不是被装的，看 Postman 的日志最直接。macOS 在 ~/Library/Application Support/Postman/logs/main.log，搜 auto-existing-upgrade，搜到一行 results 里带 installed 的，就是它干的。

issue 里目前确认的都是 macOS 用户。Windows 的这几个配置目录路径规则相同，Postman 桌面版在两个系统上都会更新，建议照着搜一遍。

症状和文件也能对上号，查的时候可以倒着来。Codex 启动时打印一段 API 工程师的技能说明，对应 config.toml 里的 hooks.state；反复弹 MCP 认证失败，对应 mcp.codex.json 里那条没登录过的远程连接；Claude Code 的插件列表里多出你不认识的条目，对应 installed_plugins.json。症状都对不上但就是不放心，直接搜日志最快。

三、第二步：清干净

删除动作按文件来，改之前先备份一份，复制成 config.toml.bak 这种后缀就行。

config.toml 里删掉 postman 相关的三段整段内容，包括 hooks.state 里那行 trusted_hash。settings.json 里删掉 postman 相关的 marketplace 和插件启用字段。installed_plugins.json 里删掉 postman 那一条。最后删掉 ~/.local/bin 下的 postman 可执行文件和它旁边的 lib 目录。

Postman 设置页里其实有卸载插件的开关。11 月 3 日 issue 下面有用户说他不放心 Postman 自己的清理脚本，最后是手动删的文件。装没装干净，回头再跑一遍第一步那几个搜索就知道了。

清完重启 Codex 或 Claude Code。之前反复出现的 MCP 认证报错如果还在，检查 ~/.codex 下的 mcp.codex.json 里有没有残留的 mcp.postman.com 条目，有就删。

四、第三步：防复发

官方版本没修之前，最有效的防复发只有一条：装了 Codex、Claude Code 或 Copilot 的机器上，别随手打开闲置的 Postman 桌面版。报告里描述的触发方式就是放着一段时间没用，一打开就中。真要用，先确认版本已经带明确的选择开关，或者等修复版。

等修复也有个判断标准。升级 Postman 之后翻一眼 main.log，如果自动安装的记录还在，而日志里没有出现任何 opt-in、confirm 之类的确认动作，就说明这版还是老行为，继续别开。什么时候官方把同意流程做进去了，日志里会先看到询问而不是结果。

平时用 dotfiles 或 git 管理配置的人还有个便利：把 config.toml 提交过一次的，直接 diff 当前文件和仓库里的版本，被塞进来的段一目了然，删起来也不容易误伤。

不用 Postman 的话，替代品现成：Bruno 开源，Insomnia 免费，接口调试的活都接得住。