MCP Inspector v0.16.8+ sends 'Bearer' without access token after OAuth?
After completing OAuth in MCP Inspector v0.16.8 or v0.16.9 (Node v22, macOS, MCP SDK 1.18.1), the server receives an Authorization header containing only 'Bearer' with no access token, so authenticated requests return 401 despite the OAuth flow completing. Was this fixed, and what can I do if I still see it?
Originally asked on GitHub: https://github.com/modelcontextprotocol/inspector/issues/826
6 answers
Status: the issue was closed as completed, and a maintainer reported that v0.17.0 seems to work fine.
Steps that came out of the thread:
- Upgrade MCP Inspector to v0.17.0.
- Before retrying OAuth, open your browser devtools and clear the local and session storage for the localhost:6474 host, as a maintainer asked the reporter to do.
- If you still see the problem, check the custom headers UI introduced in v0.16.8. A maintainer suspected the same issue as #829: a placeholder Authorization header may have been added automatically. Remove or disable that placeholder header.
- Verify the header name is exactly 'Authorization'. The maintainer pointed out that 'HTTP_AUTHORIZATION' is not a valid HTTP header; it is a server-side variable name that PHP/Apache uses after converting the incoming header.
- If you cannot upgrade or the problem remains, pin MCP Inspector to v0.16.7, which the reporter said resolves the issue completely.
Note that one user still got 'Failed to start OAuth flow: duplicate redirect URI' on v0.17.0; a maintainer said that was a separate issue fixed in another PR (#825). Another user on v0.17.0 saw the server receive only the token without 'Bearer', which the maintainer explained as an invalid 'HTTP_AUTHORIZATION' header name rather than the expected 'Authorization' header.
General advice: clearing browser storage will remove saved OAuth state, so you will need to authenticate again.
Did this work for you?What a GitHub user tried on GitHub (Worked)
Reporter downgraded MCP Inspector from v0.16.8/v0.16.9 to v0.16.7 (package version '0.16.7') and said this resolves the malformed Authorization header completely.
Source: https://github.com/modelcontextprotocol/inspector/issues/826 (opens external site)
Did this work for you?What @cliffhall tried on GitHub (Partly worked)
A maintainer asked the reporter to try v0.17.0 and first clear local and session storage for localhost:6474 in browser devtools; the maintainer reported that 0.17.0 seemed to work fine in their test.
Did this work for you?What @olaservo tried on GitHub (Outcome unclear)
A maintainer suggested the bug may be the same as issue #829: a placeholder header added automatically by the custom headers UI in v0.16.8, with the workaround being to disable or remove that placeholder header. This was not explicitly confirmed in the thread.
Did this work for you?What @symdeb tried on GitHub (Partly worked)
A user changed Inspector settings in the sidebar and then saw 'Bearer' appear in the header; a maintainer said that if the header is turned on in the sidebar, it will be sent.
Did this work for you?What @symdeb tried on GitHub (Didn't work)
A user on v0.17.0 saw the server receive 'HTTP_AUTHORIZATION=' without the Bearer prefix, so the request still did not have a valid Authorization header.
Did this work for you?
Related questions
- MCP Inspector 0.10.2 sends null for unset optional params (error -32602)?
- Why does npx @modelcontextprotocol/inspector fail with 'mcp-inspector: command not found' after 0.10.0?
- How do I increase MCP Inspector's 10-second request timeout?
- MCP Inspector crashes with 'Controller is already closed' on fastmcp Streamable HTTP
- Why does the MCP Inspector Docker container refuse connections on localhost:6274, and how do I fix it?