ChatGPT App Submission's Domain verification step does not support subpath-hosted MCP servers

ChatGPT Apps SDK
, , ,
1

Hi all — sharing a finding that may help others building MCP apps where the server is hosted on a subpath rather than the domain root.

The issue:

When submitting an app with an MCP server URL that includes a subpath (e.g., https://example.com/api/mcp), the domain verification step sends the challenge request to:

GET https://example.com/.well-known/openai-apps-challenge

…rather than the expected:

GET https://example.com/api/mcp/.well-known/openai-apps-challenge

The verifier always strips the path and checks the root domain, regardless of the MCP URL or challenge base URL configured in the submission form.

Additional observations:

  • Setting the challenge base URL to include a subpath (e.g., https://example.com/api/mcp) returns: “Domain verification URL hostname must be the MCP hostname or a parent hostname” or sometimes “Token mismatch / Did not return a 200 OK” — even though the hostnames match. The path component is not a hostname, so this error seems inconsistent with the stated rule.
  • Inspecting the API request sent to OpenAI on the webform when clicking “Verify Domain” confirms the full subpath is included in the payload in the token_url attribute sent to “https://api.openai.com/v1/dashapi/versions/xxxx/domain/verify”. The path appears to be stripped server-side.
  • Setting the challenge base URL to just the root domain (https://example.com) and hosting the token at /.well-known/openai-apps-challenge does work.

Why this matters:

This affects any MCP server hosted on a subpath — which is common for platforms that serve multiple services on the same domain. Requiring the verification token at the root /.well-known/ path may not be feasible when the root domain is shared across different services, features or people.

Reproduction steps:

  1. Create a new app in the Developer Dashboard
  2. Set MCP server URL to a subpath (e.g., https://example.com/api/mcp)
  3. Host the verification token at https://example.com/api/mcp/.well-known/openai-apps-challenge
  4. Attempt domain verification
  5. Observe the challenge request goes to the root /.well-known/ path instead

Workaround: Host the verification token at the root domain path (/.well-known/openai-apps-challenge). This may not be practical for all deployments.

Would be great if the verification step could respect the MCP URL subpath when constructing the challenge request.

Happy to provide more details privately if helpful — will email support@openai.com with a reference to this post.

2 Likes
2

Hey there, thanks for sharing this knowledge with us! Your finding is correct–we don’t support non-root .well-known locations when performing domain verification. This is not something we plan on supporting, given that doing so would run against RFC-8615, which means it also breaks OAuth 2.0 metadata standards.

If you do run into issues with getting domain verification to work, please do share and we’d be happy to help troubleshoot.

1 Like