一句话看懂：一名开发者在同一对话启用两个指向同一 MCP 服务器的连接器后，发现 ChatGPT 会把连接器 A 生成的确认码不经提示地交给连接器 B 使用；服务器因 OAuth 客户端不匹配拒掉了这次调用，但事件暴露的授权边界问题值得关注。
事件核心：发生了什么
据 OpenAI 开发者社区 2026 年 11 月 6 日发布的帖子，测试者为同一账号配置了两个连接器，且都指向同一个 MCP 服务器：连接器 A 为开发者模式下自建，连接器 B 来自应用目录的已发布应用。两者使用不同的 OAuth 客户端，服务器端识别为同一用户的两种独立授权。
用户在连接器 A 的 MCP Apps 组件中确认操作后，该组件通过 ui/message 向对话发送一次性确认码。模型随后发起后续工具调用时，却在未告知用户的情况下改走连接器 B，并把 A 生成的确认码一并带过去。由于确认码绑定 A 的 OAuth 客户端，服务器拒绝了这次调用，该对话中的相关尝试全部失败。发帖者指出，工具调用应按 OAuth 客户端而非 MCP 服务器 URL 匹配连接器。
为什么重要
连接器本质上是拥有独立 OAuth 授权的应用。A 中产生的数据被静默送入 B，等于在两个应用之间转移了数据，却未经用户同意。发帖者提醒，若同一对话接入第三方连接器，且服务器 URL 相同，这类切换可能把一家应用的数据带到另一家提供方。共享 URL 并不能证明两个连接器属于同一主体，同一地址背后也可能对应不同租户或合作伙伴，真正的边界是连接器及其 OAuth 客户端。官方回复承认“工具选择”与“授权连续性”是两个不同问题，并建议将待确认操作绑定到发起连接器、禁止确认或执行期间自动切换连接器。
对用户/开发者/创作者的影响
目前公开信息显示服务器端绑定阻止了误用，但客户端编排层是否保留连接器身份仍不明确。对开发者而言，构建多步骤 MCP 工作流时，应在服务端校验确认码与预期操作、客户端身份及授权上下文；对普通用户和企业采购方，启用多个连接器时难以感知数据被路由到哪个应用，这会影响对数据边界的信任。
AI 工具推荐
想把多个 AI 模型放在一个入口？
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型，适合写作、绘图、视频和日常 AI 工作流。
推广链接：通过此链接购买，我可能获得佣金，不影响你的价格。
值得关注的后续
一是 OpenAI 是否公开说明连接器路由逻辑，并修复静默切换问题；二是官方漏洞披露流程是否调整身份验证要求；三是 MCP 生态是否形成约定，要求客户端记录连接器路由决策，并在切换时请求用户明确授权。
