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.