A user discovered a security concern where ChatGPT makes follow-up tool calls through a different connector than the one that initiated the interaction, without notifying the user of the switch.
The issue occurs when a conversation has two connectors enabled that point to the same MCP server. According to the report, one connector is a custom connector in developer mode, while the other is a published app from the app directory. Each has its own OAuth client, meaning the server treats them as separate applications with different user consent grants.
In the observed scenario, a user initiated an action requiring confirmation through Connector A, which displayed a confirmation widget. After the user confirmed the action, the widget generated a one-time confirmation code sent to the conversation. However, when the model made the follow-up call using that code, it routed the request through Connector B instead—without informing the user of the switch.
The server rejected the call because the confirmation code was bound to Connector A’s OAuth client, while the follow-up attempt came from Connector B. This caused the operation to fail repeatedly throughout the conversation.
The core problem is that data generated within one connector’s widget (Connector A) was silently passed to a different connector (Connector B) without user awareness or explicit consent. Since connectors represent separate applications with independent OAuth grants, this behavior effectively transfers data between two distinct authorized apps without the user’s knowledge.
The reporter notes this becomes more severe with third-party connectors. When multiple connectors share the same MCP server URL, the silent routing could pass data between applications from different providers if the underlying server URL is identical.
According to the report, the issue stems from how ChatGPT matches tool calls to connectors. Currently, the system appears to route calls based on the MCP server URL rather than the specific OAuth client associated with each connector. Since a single server URL can support multiple OAuth clients representing different tenants, partners, or environments, this approach fails to respect the security boundary created by individual OAuth grants.
The expected behavior, according to the report, is that tool calls should be matched to connectors based on their OAuth client credentials. Follow-up calls should route through the same connector and OAuth client that initiated the original flow, ensuring data passed between steps remains within the user’s intended authorization scope.
Key facts
- ChatGPT routed a tool call through Connector B despite the user initiating the flow through Connector A
- A one-time confirmation code from Connector A’s widget was passed to Connector B without user notification
- Each connector has its own OAuth client, representing separate authorized applications
- The server rejected the call because the code was bound to Connector A’s OAuth client, not Connector B’s
- Silent routing between connectors with different OAuth clients violates user consent boundaries
- Sharing an MCP server URL does not make connectors equivalent from a security perspective