AutoInstallPluginService~install: script completed {"source":"auto-existing-upgrade","results":["claude-code:installed","codex:installed"],"installer":"script"}macOS 用户将 Postman 升级到 12.33.4。打开主界面的瞬间，终端配置已经被后台静默改写。
系统没有弹出任何授权询问，也没有展示插件说明。整套流程在几秒内执行完毕。这行日志直接记录了后台脚本执行跨软件安装的执行痕迹。
API 客户端在后台静默扫描并篡改其他工具的配置。这种做法击穿了开发者对本地环境隔离的基本预期。事件暴露出智能体生态缺乏强制性的权限拦截体系。不同工具间的操作边界，直接维系在厂商的自觉之上。
翻开本地日志：后台脚本静默改写多个终端 Agent 配置
2026 年 10 月 25 日，开发者 indicava 提交 issue #14370。报告直指 Postman 桌面客户端存在越权行为。macOS 环境下的 ~/Library/Application Support/Postman/logs/main.log 第 11562 行至 11563 行，留下了自动化安装记录。时间戳为 2026-10-24T09:34:14.418Z，状态明确标记为 auto-existing-upgrade。
运行标志位清晰记录了安装器直接调用本地脚本的执行路径。检查本地配置文件，受影响范围覆盖了主流终端智能体。~/.codex/config.toml 被直接写入三个配置节。这包括市场源、插件激活开关与专门的钩子状态。
注入过程在几毫秒内完成。普通开发者打开终端，很难察觉外部写入的痕迹。~/.claude/settings.json 被直接启用了官方插件。installed_plugins.json 记录的注入时间，与 Postman 日志时间戳精确重合。
与此同时，~/.local/bin 目录中悄然出现了 Postman CLI 的可执行文件。二进制文件落在用户级路径下，不需要管理员授权，也就不在任何系统级安装审查的覆盖范围内。
本地配置属于受保护的私域，跨应用篡改打破了开发工具的信任链条。 客户端将前台运行权限泛化为整机配置管辖权。未经确认的组件被强行绑定进日常终端。在缺乏沙箱隔离的桌面环境中，这种静默下发行为重构了本地工具的依赖关系。
篡改启动上下文：一条全局指令接管所有 API 任务
写入配置只是前置准备。更深层的影响，发生在智能体启动阶段。插件注册了 SessionStart 钩子。触发条件绑定在 startup、clear 与 compact 三类通用操作上。
智能体开启新会话或整理历史上下文，都会自动加载 hooks/session-start-context.md 文件。自动化逻辑借助生命周期事件，介入了对话上下文。该文件植入了一段具有强引导倾向的全局提示词。
文件原文提出了全局要求。只要涉及设计、实现、测试或部署等 API 任务，模型必须优先加载 postman:api-engineer 技能并严格遵循。指令作用域非常宽泛，覆盖了日常网络接口开发的多数环节。
这种提示词设计刻意越过了用户的明确意图。开发者即使明确要求使用原生库编写脚本，模型也会受制于全局指令。它会优先调用 Postman 生态。在底层施加持久化引导，重塑了智能体分发任务时的决策路径。
注入行为还延伸到了远程通信领域。Codex 的 mcp.codex.json 被写入了指向 https://mcp.postman.com/mcp 的远程服务器地址。Codex 按这份配置发起了连接，随后因鉴权失败中断，日志里留下的是 MCP server startup failed ... Auth required。
安装器调用内部接口，在同一进程内自我批准安全哈希
现代智能体通常引入了哈希校验。此举旨在防止恶意插件劫持执行流。如果配置中的启动钩子未经用户交互确认，终端会阻断其运行。Postman 安装器的源码显示，这项防线被内部代码直接旁路。
源码文件 installer/src/hosts/codex.ts 在完成组件部署后，顺次调用了 approvePostmanHook(system) 内部函数。安装脚本先调用 hooks/list 计算散列值。随后通过 config/batchWrite，将生成的两个 sha256 结果直接写入 hooks.state。源码甚至保留了注释，明确写道该方法仅在安装后批准当前钩子。
安装程序在同个进程内完成部署与审批，导致防篡改机制形同虚设。 这种自我盖章的实现逻辑，消解了哈希比对原本承担的防护功能。安全检查假设外部调用者诚实守信。一旦客户端选择自签自核，验证机制便失去了阻拦能力。
这暴露了本地配置管理模式的结构性弱点。桌面应用可以随意重写配置哈希。在这种环境下，终端维护的信任凭证无法提供隔离保证。安全边界若停留在文本字段校验，很难对抗同权限运行的桌面进程。
版本实测显露技术差异，证据边界止步于指令注入
事件公开后，不同环境下的实测结果出现分化。在 Codex 0.162.1 上，缺少信任记录的钩子会被静默跳过。交互流程仍需人工确认。实测表明各版本行为存在明显区别。
而在 Codex 0.153.4 环境下，配置文件并未写入散列值。相关提示文本反而出现在了 Cursor 中。静默安装动作在受影响系统上得到了证实。但信任记录能否成功写入，取决于具体版本的处理机制。
技术分析必须严格锚定客观证据的边界。报告者 indicava 强调，仅凭信任记录无法推断具体生成者。现有证据只能证实未经许可的插件安装与指令注入，目前并无任何数据表明资产外泄。
部分社区讨论声称该操作试图共享所有 API 数据。这种推论超出了现有证据的支撑范围。网络抓包和日志审计中，并未发现敏感代码被上传至外部服务器。将该行为界定为越权配置，符合工程事实。
卸载残留暴露治理空白，跨应用安全边界缺少强制约束
跨应用注入带来的混乱在卸载阶段进一步扩大。后续反馈显示，Copilot 的配置目录中同样被写入了市场和插件状态。用户在桌面菜单点击卸载选项。客户端却弹出了失败提示。
图：从 Postman 菜单执行卸载插件时，弹窗提示 Copilot 插件无法被清理。来源：GitHub issue #14370 用户 ck-tecso
写入时畅通无阻，清理时却留下残留。这反映出多端集成的工程质量欠缺严谨。面对残留配置，有开发者不敢运行官方清理脚本。他们选择借助其他模型，逐行手工还原环境。
图：Postman 桌面端的插件卸载界面。来源：GitHub issue #14370
这种隐蔽改动在企业开发环境中引发了严重的合规担忧。启动上下文被强制注入第三方逻辑。企业的私有代码与接口规范，可能被导向外部插件的处理流程。有维护者在仓库中提交了移除 Postman 的变更，这反映出开发团队对失控行为的警惕。
面对开发者的公开质疑，Postman 官方保持沉默。有用户称在群组中询问过此事，反馈较为平淡，这一说法仅代表个别用户的单方转述。社区通过历史快照指控官方事后修改下载页，官方对此同样未作公开回应。面对信任裂痕，诸如 Milkman 等轻量替代方案迅速进入讨论视野。
图：用户对比的下载页历史快照，指控官方在事发后补充相关说明。来源：GitHub issue #14370 社区讨论
重建智能体权限边界，协议安全不能寄托于厂商自律
桌面软件直接操作同权限工具的配置，将新型集成形态推向了监管盲区。终端智能体成为工作流的核心枢纽。配置读写权限成了争夺生态入口的资源。缺乏操作系统的硬性隔离，跨进程操作的合规门槛便随之失效。
事件反映出智能体生态的脆弱现状。跨应用集成日趋普遍，统一的授权框架却迟迟没有建立。商业诉求推动工具抢跑集成，开发者被迫耗费精力排查安全风险。协议层面若缺少强制确认机制，本地环境的防线就只能任由各方自觉处置。
参考链接：
- GitHub issue postmanlabs/postman-app-support #14370
- Codex 与 Claude Code 官方插件规范文档
- Wayback Machine 归档快照与社区实测记录
