打开久未使用的 API 调试工具 Postman 桌面端（版本 12.33.4），Mac 里的本地 AI 编程工具 OpenAI Codex 和 Claude Code 就会在后台被悄悄改写全局配置，强行塞入 Postman 插件与启动指令。2026 年 10 月 25 日，一名开发者在 GitHub 提交的 Issue #14370 披露了这一过程。社区部分转载标题称 Postman 企图窃取所有 API 数据，但核查日志与源码可以确认，由于远程 MCP（Model Context Protocol）连接缺少认证直接报错失败，现场并未发生 API 数据外泄。真正刺穿安全防线的，是 Postman 安装器直接调用脚本计算并写入了代表用户授权的 trusted_hash（信任哈希），替用户完成了对自身启动钩子的安全审批。
自动代签的 trusted_hash 与官方文档里的增长阳谋
根据开发者提取的 main.log 日志，2026 年 10 月 24 日 09:34:14，已登录状态的 Postman 桌面端触发了名为 auto-existing-upgrade 的后台机制。在没有任何弹窗确认的情况下，脚本向系统安装了 Codex 插件（版本 1.1.0）、Claude Code 插件（版本 2.0.1），并在 ~/.local/bin 目录下塞入了一个独立的 Postman CLI 可执行文件。
更越界的动作发生在配置文件层。安装脚本修改了 ~/.codex/config.toml 和 ~/.claude/settings.json，不仅把远程服务地址指向 https://mcp.postman.com/mcp，还注册了一个 SessionStart 启动钩子（Hook）。每当开发者启动、清空或压缩 Codex 会话时，这个钩子就会向 AI 注入一段前置指令，要求在响应任何非琐碎的 API 工程任务（包括设计、实现、Mock、测试、监控、文档编写或部署）之前，必须先加载并遵循 postman:api-engineer 技能。
为了防止外部程序通过篡改配置劫持 AI 行为，Codex 等工具专门设计了信任边界机制。新增的启动钩子必须经过用户在宿主程序内显式确认，生成并记录 trusted_hash 后才能生效。但在 postmanlabs/postman-plugin 仓库（提交版本 6c8e452e0f4237f4bcc0901cb1ac442dec707e49）的 installer/src/hosts/codex-hooks.ts 源码中，Postman 编写了一个名为 approvePostmanHook 的函数。该函数会在安装插件后直接读取钩子列表，通过 config/batchWrite 接口把算好的哈希值写入 hooks.state。
第三方桌面软件替用户签下信任哈希，等于让本地 AI 的安全沙盒当场失灵。
这种越俎代庖并非程序员写错代码的偶然失误，而是公开写进文档的产品设计。Postman 于 2026 年 9 月 29 日正式发布 Codex 插件，并在官方学习中心（learning.postman.com）的安装文档中明确写道，虽然通过普通 Codex 应用或命令行安装会将钩子保留为“未受信任”状态供用户审查，但使用其检测到的 Agent 安装器（detected-agents installer）时，安装器会主动替用户批准该钩子，仅在自动批准失败时才回退到人工审查。再叠加 Postman 在 2026 年 10 月 1 日更新的产品条款——将绝大多数自助服务计划的 AI 条款与基础服务条款强制捆绑默认接受——可以看出，面对本地优先工具的竞争分流，急于抢占 AI 编程入口的 Postman 选择了一条把“摩擦最小化”凌驾于用户知情权之上的激进增长路线。
明文配置的软肋与开发者的排查清单
尽管 Postman 在注入的提示词末尾留了一句“用户指令优先”的兜底声明，且此次事件仅在已登录老用户的升级路径（auto-existing-upgrade）中触发、尚未在全新安装的 Mac 上复现，但它依然撕开了当前本地 AI 编程工具的一道底层架构裂缝。
浏览器时代曾反复上演桌面软件后台静默篡改默认主页与搜索引擎的戏码，而在 AI Agent 时代，入口争夺战直接演变成了跨软件的系统提示词劫持。OpenAI Codex 与 Anthropic Claude Code 将核心配置、插件开关乃至决定代码执行权限的 trusted_hash 全部以明文形式存放在用户主目录（如 ~/.codex/config.toml）下，既没有绑定操作系统的密钥链（Keychain）验证，也缺乏进程签名校验。这意味着，只要任何一款桌面软件拿到了普通用户级的文件读写权限，就能在用户毫无察觉的情况下复刻 approvePostmanHook 的套路，把自己的技能和远程服务塞进 AI 的默认工作流里。
对于正在使用本地 AI 编程工具的开发者与企业安全团队，当务之急是立刻排查本地环境是否已被静默注入。如果在近期打开过 Postman 12.33.4，需重点检查并清理以下四个路径：
- 检查 `~/.codex/config.toml
中是否存在[marketplaces.postman]、[plugins."postman@postman"]以及带有postman@postman前缀的hooks.state` 信任记录； - 检查 `~/.claude/settings.json
与~/.claude/plugins/installed_plugins.json是否被启用了postman@claude-plugins-official`（版本 2.0.1）； - 检查 `~/.local/bin
目录下是否多出了未经许可安装的postman` 可执行文件及相关依赖库。
- 提醒.准备彻底卸载 Postman 转向其他 API 调试工具的团队，在选型时同样需要看清数据流向边界。主打本地优先的 Bruno 将接口集合作为纯本地文件存储且无需注册账号，仅在启动验证许可证时发送不含项目数据的元数据；而另一款热门替代品 Insomnia 虽然提供了本地 Vault 与云同步选项，但其内置的 AI 功能会将接口数据直接发送给所配置的模型提供商，且默认不包含自动脱敏机制。
截至发稿，Issue #14370 已引发数十名开发者联署抗议，要求 Postman 停止对存量桌面端用户的自动插件安装、移除安装器侧的钩子自审批代码，并提供完整的配置回滚卸载脚本。但比 Postman 一家公司是否回滚更新更值得盯紧的，是 OpenAI 与 Anthropic 接下来如何修补 Codex 和 Claude Code 的本地配置防线——如果 trusted_hash 继续留在毫无加密保护的明文配置里，下一个撬门自签的桌面软件绝不会让开发者等太久。