I’m seeing a reproducible failure when creating a new custom MCP app in ChatGPT Developer Mode.
Reproduced: October 2, 2026
The create request fails with:
HTTP 500
{"detail":"Request timeout"}
What makes this interesting is that I can reproduce the failure using two completely different MCP connection paths, and in both cases the request appears to fail before ChatGPT sends any traffic to the MCP server.
Case 1 — Secure MCP Tunnel
I have:
- an existing Secure MCP Tunnel connection that already works correctly in ChatGPT
- a second isolated Secure MCP Tunnel for a new review/test MCP server
The new tunnel is:
- running
- healthy
- polling
- connected to its MCP upstream
- serving an isolated read-only MCP profile
However, attempting to create a new ChatGPT app using this tunnel fails with:
HTTP 500
{"detail":"Request timeout"}
During the failed Create attempt:
- no MCP session is initialized
- no discovery request is forwarded
- no command is forwarded
- no request reaches the review MCP server
The existing older MCP app using the original Secure MCP Tunnel continues to work normally at the same time.
I verified this by successfully calling tools through the existing connector immediately after reproducing the 500 error.
Case 2 — public HTTPS MCP endpoint
To rule out a Secure MCP Tunnel-specific problem, I also tested a separate public HTTPS path.
The endpoint has:
- public DNS resolving correctly
- TCP 443 reachable externally
- valid TLS
- OpenAI mTLS enforcement on
/mcp - OAuth protected-resource metadata
- Auth0 OAuth authorization server
- Authorization Code flow
- PKCE S256
- a custom OAuth client configured in ChatGPT
External connectivity to TCP 443 is confirmed.
The public MCP edge logs requests, and the relay behind it is healthy.
Nevertheless, creating the app again produces:
HTTP 500
{"detail":"Request timeout"}
During that failed attempt there are zero requests in the public MCP edge logs and zero requests in the relay logs.
So the timeout occurs before the request reaches the MCP infrastructure.
OAuth diagnostics
Initially ChatGPT also reported:
MCP server does not implement OAuth
even though ChatGPT successfully fetched:
/.well-known/oauth-protected-resource
/.well-known/oauth-protected-resource/mcp
The protected-resource metadata points to Auth0, and Auth0 advertises:
authorization_endpoint
token_endpoint
registration_endpoint
authorization_code
refresh_token
PKCE S256
Dynamic Client Registration and Resource Parameter Compatibility are enabled in Auth0.
The API allows the required user-delegated scope.
ChatGPT’s Advanced OAuth UI nevertheless showed DCR and CIMD as unavailable, so I also tested with a manually configured OAuth client.
That removed the earlier OAuth configuration error, but app creation then failed with the same:
HTTP 500
{"detail":"Request timeout"}
Again, no request reached the MCP endpoint.
Existing MCP still works
This does not appear to be a general MCP outage in my environment.
Immediately after the failure I tested my existing MCP app and successfully executed:
mcp_health
list_projects
The existing Secure MCP Tunnel reported forwarded commands and zero command failures.
What I would expect
According to the current Developer Mode documentation, private/on-prem MCP servers can be connected through Secure MCP Tunnel.
I would therefore expect either:
- the Create operation to contact the selected tunnel/server, or
- a specific validation/configuration error to be returned.
Instead, the backend returns a generic HTTP 500 timeout without ever contacting either tested MCP transport.
Question for OpenAI
Is there a known issue/regression in the current custom MCP app creation / connector control plane that can cause:
POST /backend-api/aip/connectors/mcp
HTTP 500
{"detail":"Request timeout"}
before the MCP transport is contacted?
This appears particularly likely because:
- an existing MCP connector continues to work
- a newly created Secure MCP Tunnel cannot be used to create an app
- an independent public HTTPS MCP endpoint produces the same create-timeout
- neither endpoint receives traffic during the failing Create operation
I can provide timestamps, request IDs, tunnel status, and sanitized logs if useful.
“The existing older MCP app continues to work normally at the same time, while creation of a new app fails before either tested transport receives any traffic.”
