A developer posting as AldiPower says ChatGPT switched connectors between requesting confirmation and submitting the approved action. A one-time confirmation code went through the second connector. The server rejected the action because the code belonged to the first connector’s client identity.
The November 5 report concerns two connectors enabled in one conversation. Both pointed to the same MCP server, a service exposing tools to an AI client. One connector was custom and developer-mode; the other was the provider’s published app.
Evidence status: a developer’s reported reproduction, without independent confirmation or a vendor fix notice in the reviewed material. The described authorization check worked. The report does not establish a successful unauthorized change or demonstrated disclosure to an unrelated provider.
The same server address can serve different app identities
Each connector used a separate OAuth client, the identity of an authorized application. The developer says the first connector displayed a confirmation widget and returned a one-time code after approval. ChatGPT then submitted that code through the second connector without telling the user.
The server bound the code to the originating OAuth client. According to AldiPower, every attempt in that conversation failed; one was logged in detail. Both connectors belonged to the same provider.
AldiPower argues that shared-server arrangements can represent different tenants, partners or environments. They hypothesize that equivalent routing across providers could disclose a value to the wrong party. That broader consequence remains unverified in this report. The available account also leaves the routing fault’s cause unresolved.
Approval must be checked where the action runs
For tool builders, a confirmation message should authorize one operation under one authenticated identity. Carrying a code through model text is not enough to preserve that relationship.
The reported server-side client check supplies a concrete example: a code issued under one app identity could not be redeemed under another. Builders can extend that approach by binding short-lived, single-use approvals to the intended user, tenant, operation and arguments. Validate those bindings against authenticated server context, not identity fields supplied by the model.
Where the app identity changes, stop and obtain fresh approval. Preserve diagnostic records of the routing and authorization decision without logging the confirmation secret itself. These are design recommendations, not a claim that OpenAI has shipped a repair.
For users, avoid enabling duplicate custom and published connectors unnecessarily while investigating this behavior. That reduces ambiguity in the reported setup; it is not a verified fix for ChatGPT routing.
What the thread adds
The Hacker News discussion separates expectations about the model from guarantees supplied by the server.
kristjansson writes: “When you hand control back to the model you hand control back to the model.”
That objection supports treating each subsequent call as a fresh authorization decision. It does not negate the binding that rejected the reported call.
simonw checks the separate dispute over disclosure requirements against Bugcrowd’s documentation. Its identity-verification policy requires an approved identity document and face photo before submissions to covered Managed Bug Bounty programs. The page names Jumio as its third-party identity-check provider and excludes on-demand programs.
AldiPower says they declined that process. The documentation supports the existence of an upfront requirement for covered programs; it does not establish that every route to reporting a vulnerability requires identification. Bugcrowd attributes the policy to reducing low-quality submissions, rather than the sanctions explanation initially suggested in the thread.
From a 35-comment thread, in HN’s own order.
Caveat: This is an unconfirmed routing report whose server-side defense held; the wider data-leak scenario and any general product impact remain unproven.