Custom MCP connector: OAuth token never forwarded, 401s don't trigger re-auth, and the tool list is frozen per-publish

API Bugs
1

Our custom MCP connector (OAuth via Auth0) ran fine for months — thousands of successful tool calls, customers connecting once and using it daily. It broke this week with no change on our side. Three distinct problems:

1. Connections failed before reaching our server. Users got “We couldn’t connect this account.” Our OAuth completed every time — valid token issued, correct audience, 24h lifetime, refresh token included. Then zero requests reached our MCP server. Not a rejection, nothing. This one resolved on its own after a few days, unexplained. Auth0 confirmed it had other customers report it and was on the OpenAI side.

2. Expired tokens get replayed, and a 401 doesn’t trigger re-auth. Still happening. We return a spec-compliant challenge:

HTTP/2 401
www-authenticate: Bearer error="invalid_token",
                  resource_metadata="https://<our-server>/.well-known/oauth-protected-resource"

The MCP auth spec says a client should refresh or re-authorize on that. ChatGPT does neither — it surfaces Mcp error: -32603: Internal error, which tells the user nothing and gets reported to us as an outage. Clicking Reconnect fixes it instantly, so the refresh path works; it just isn’t triggered by the 401. It should be, at any point in a session.

3. The tool list is frozen at publish. From the admin UI: “ChatGPT will freeze the tool list when you publish… You can choose to manually ‘refresh’ the tool list.” This breaks any MCP server where tool availability is per user. Ours filters advertised tools by the authenticated user’s subscription — different account types get entirely different toolsets. With a frozen snapshot, whoever authorized at publish time decides what everyone sees. Manual refresh can’t fix it, because the right answer differs per user, not per publish.

Possibly related: the recent topic titled “ChatGPT safety layer blocks valid MCP tool calls” (topic 1400691) — different mechanism, but same week and the same core symptom: the call is dropped client-side and nothing appears in the MCP server’s logs, so there’s nothing for the developer to debug.

2

Welcome to the Community, @marc-headset, and thanks for sharing the detailed report.

For OAuth-based MCP apps, ChatGPT relies on the OAuth provider being configured to issue refresh tokens in order to maintain connectivity after the original authorization expires. MCP app tool definitions are also stored as a frozen snapshot after approval and may need to be refreshed by an admin when changes are made.

For more details, please refer to Developer mode and MCP apps in ChatGPT.

Since the behavior you’re seeing, particularly the connection working again after manually selecting Reconnect, may require a closer look at the connection flow, please contact us at support@openai.com so our Support team can investigate further.

When reaching out, please include:

  • Your MCP server URL
  • A screenshot of the error or connector setup screen
  • Whether the same MCP server and OAuth configuration work in another MCP client, such as MCP Inspector
  • A sanitized HAR file captured from opening the connector setup or connection flow through the point where the failure occurs
  • The full 401 response received when the authentication failure occurs
  • A copy of the response from /.well-known/oauth-protected-resource

Please make sure the HAR file, 401 response, and /.well-known/oauth-protected-resource response are sanitized to remove any access tokens, refresh tokens, credentials, secrets, or other sensitive information before sharing them.

These details will help our team narrow down where the authentication and connection flow is failing and investigate the behavior more effectively.

Thanks again for taking the time to share the detailed findings.

-AJ