Repository navigation
CORS errors when using the "Quick OAuth Flow" auth troubleshooter #817
Description
Inspector Version
0.16.7
Describe the bug
I'm trying to troubleshoot a new remote MCP server, and see this error message:
When I look at the browser logs, I see the following, indicating the web requests aren't actually failing - it's just being blocked by my browser's CORS policy:
Access to fetch at 'https://<redacted>/.well-known/oauth-protected-resource' from origin 'http://localhost:6274' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource.
To Reproduce
Steps to reproduce the behavior:
- Add remote server, click 'Connect'
- Click on 'Auth'
- Scroll down to 'Quick OAuth Flow'
- See error
Expected behavior
- The app is able to make requests regardless of CORS policy, or instructions are provided on how to run it in a way to bypass.
- The error message is more descriptive of the problem, rather than indicating a generic problem has occurred.
Screenshots
See above
Environment (please complete the following information):
- OS: macOS (Tahoe 26.0)
- Browser: Edge
Additional context
N/A
Reacted by mt-ib and Collin Sauve
Activity
Xueyao-Huang commentedon Sep 25, 2025
same in 0.16.8
cliffhall commentedon Oct 4, 2025
@anthony-c-martin when you say "the app" do you mean a browser-based app or an app running as a service? The latter will not have any CORS-related issues, because that is a browser concern.
Any browser-based app will have a CORS issue connecting to any server that does not allow its origin to connect. It's not up to the Inspector or any browser-based app to set the CORS policy, that's the server's prerogative.
Have a look at the Everything reference server implementation and how it opens the CORS origin and headers it allows the browser to read.
cliffhall commentedon Oct 11, 2025
Closing this one. It seems as if your
.well-known/oauth-protected-resourceendpoint needs CORS config to allow all origins. It is a public metadata discovery mechanism.anthony-c-martin commentedon Oct 12, 2025
Thanks for the guidance! I'll try out enabling the CORS config for the
.well-known/oauth-protected-resourceendpoint.ov-developer commentedon Oct 17, 2025
@cliffhall Hi, I'm running into the same problem. CORS policy is blocking the metadata and oauth requests. Would it make sense to use the MCP proxy also for those? From my understanding the whole point of having a proxy is to "circumvent" the CORS policy for development as it is only relevant in browser environment.
cliffhall commentedon Oct 18, 2025
The original point of the proxy was simply to support STDIO servers. You can't talk to them from a browser, you have to have a proxy.
I agree that it might be helpful to go through the proxy, and we may look into doing it, but, it would not be a simple change.
sambhav commentedon Nov 14, 2025
Happy to implement this change, facing the same issue.
anthony-c-martin commentedon Nov 15, 2025
Thanks for re-opening! It would definitely be a valuable feature to have.
sdehors-ibm commentedon Feb 4, 2026
The browser manages to get the
.well-known/oauth-protected-resourceas it is allowed through a preflight request but then fails on the token endpoint with a CORS error. Should this token endpoint also allow all origins ? This is also described here : #995I can see that it fetches the token fine, but the browser (FF) displays
Response body is not available to scripts (Reason: CORS Missing Allow Origin)cliffhall commentedon Aug 1, 2026
Closing: v1 is deprecated.
Thank you for reporting this, and apologies for the long wait for a response.
v1 will receive security fixes only — this issue describes a functionality, compatibility, or usability problem rather than a vulnerability, so it is being closed against v1. This is not a judgment on whether the problem is real — it's a consequence of the v1 line being frozen. This is happening as part of #1872.
If this still happens in v2, we'd genuinely like to know. v2 is a complete rewrite — three clients over a shared core — so many v1 behaviours no longer exist in the same form. Please open a fresh issue against v2 with steps to reproduce, and we'll look at it. Note that we accept external contributions as issues rather than pull requests; maintainers handle design and implementation through a prompt-driven workflow. See
CONTRIBUTING.md.Thanks for taking the time to report it.