# ChatGPT reportedly switched connectors after the user said yes

**Summary:** A developer reports ChatGPT sent a confirmation code through a different connector and the server rejected it. I want approvals tied to the chosen connection throughout an action.

- Canonical: https://markhuang.ai/news/chatgpt-confirmation-connector-switch
- Language: en
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-11-06
- Section: News
- Tags: ChatGPT, MCP, OAuth, App Connectors, AI Security, User Consent
- Source: [OpenAI Developer Community](https://community.openai.com/t/security-follow-up-tool-call-silently-routed-to-a-different-connector/1413053)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![A blue confirmation token tethered to one lock cannot fit a second lock, which remains closed with a red indicator](https://cdn.markhuang.ai/news/chatgpt-confirmation-connector-switch/hero.webp)

*Conceptual illustration: a confirmation belongs to a particular connection. In the developer's report, the server refused to accept it through another connector.*

A developer reports that ChatGPT carried a user's confirmation code from one app connector into a follow-up call through another. The server rejected the call. That refusal is reassuring. The question is why the confirmation went through a different connection in the first place.

In the [November 5, 2026 OpenAI Developer Community post](https://community.openai.com/t/security-follow-up-tool-call-silently-routed-to-a-different-connector/1413053), AldiPower describes two connectors enabled in one conversation, both pointing to the same server but using separate OAuth clients. I want an approval to stay attached to the connection that requested it. People connecting apps to ChatGPT need to know which app receives their confirmation and which permissions it uses to finish the action.

A connector gives ChatGPT access to an app's tools. Here those tools use MCP, the Model Context Protocol, to communicate with the server. OAuth governs the permission granted to a connected app. The distinction matters because two connections can reach the same address while carrying different grants of permission.

## The same server, two separate connections

According to AldiPower, connector A was a custom connector added in developer mode. Connector B was the provider's published app in the app directory. Both belonged to the same provider, and the server recognized separate OAuth clients for the same user.

The user began an action through A. Its embedded widget displayed the proposed change and asked for confirmation. After the user agreed, the widget sent a one-time confirmation code into the conversation. ChatGPT then submitted that code through B, without telling the user about the switch, the developer says.

The one-time code recorded approval of an application action; it was separate from the OAuth credentials used to make the request. The server had bound the code to A's OAuth client, so redemption through B failed. The author says every attempt in that conversation failed and describes one attempt logged in detail.

The reported sequence is:

```mermaid
flowchart TD
  A["Connector A requests confirmation"] --> B["User confirms in A's widget"]
  B --> C["Widget sends one-time code into conversation"]
  C --> D["Follow-up call uses connector B"]
  D --> E["Server detects different OAuth client"]
  E --> F["Server rejects the confirmation code"]
```

I would keep the server's refusal intact while investigating the routing. Accepting A's code through B would remove the check that caught the mismatch.

## A blocked action leaves a routing question

The server's protection worked, according to the report. Both connectors reached the same provider, and the operation failed. This account does not demonstrate disclosure to an unrelated company or a completed unauthorized action.

AldiPower raises a broader concern that a shared server address can serve different parties depending on the OAuth client. That is a plausible reason to preserve connection identity, but the proposed third-party disclosure remains hypothetical. The reported setup alone cannot establish that outcome.

The cause remains unclear. The thread describes what the author says their logs showed; it does not include the underlying trace or an independently reproduced test. None of the three posts reviewed for this article is an OpenAI staff response. We cannot tell from this thread why ChatGPT selected B, how widely the behavior occurs, or whether OpenAI has confirmed a defect.

A user who approves a change in A has a reasonable expectation that A will finish it. The server's successful rejection does not explain why the assistant used B. The server should refuse the wrong authorization. The assistant also needs to preserve the chosen connection.

## Approval needs a destination

[Simon Willison's April 2025 analysis of MCP security](https://simonwillison.net/2025/Apr/9/mcp-prompt-injection/) warns about dangerous combinations of private data and tools that can send it elsewhere, and argues for interfaces that make tool calls understandable. That critique helps explain why the destination of a call matters. It does not establish prompt injection as the cause of this incident.

OpenAI's [authentication documentation](https://developers.openai.com/plugins/build/auth#implementing-token-verification) places token verification and server-specific policy checks on the server receiving each request. Its [security guidance](https://developers.openai.com/apps-sdk/guides/security-privacy/) also calls for explicit consent and validation of inputs on the server. Those responsibilities remain necessary even when the assistant has already shown a confirmation widget.

For an action that takes several steps, my preference is simple: keep the originating connection and its authorization context attached through completion. If the assistant needs to use another connection, it should explain the change and request approval for that connection. The confirmation should cover the intended action as well as who is authorized to carry it out.

For builders with custom and published connectors pointing to the same service, this report suggests a focused check: start a confirmation through one connection and verify that the other cannot redeem it. Record enough connection information to diagnose a mismatch without logging the confirmation secret. I have not run that check myself.

I made a related argument in [the Postman installer analysis](/news/postman-installer-self-approves-ai-hook): the system's permissions should reflect a choice the user actually made. Here the server reportedly enforced that distinction. I want the assistant's choice of connection to preserve it too.