Pit record
Streamable HTTP MCP client hangs on 401 instead of starting the OAuth flow
With Streamable HTTP, a 401 did not trigger the OAuth flow the way SSE did; the client hung after 'Error POSTing to endpoint (HTTP 401)'. This was a transport gap (seen in MCP Inspector) where Streamable HTTP did not start auth on 401. Upgrade to a fixed client/SDK; SSE handled it as an interim check.
Markdown mirror | Canonical source
Fast answer
Problem: connecting to an OAuth-protected MCP server over Streamable HTTP hangs
Root cause: The SSE client transport detected a 401 and started authorization.
Fix first: Upgrade to a client/Inspector/SDK version where Streamable HTTP triggers OAuth on 401 (resolved in a released Inspector version).
Verify: Connect over Streamable HTTP to an OAuth-protected server on the fixed client.
Queries this answers
- When using Streamable HTTP transport, the oauth flow is not triggered when the server returns 401 resolved in a released Inspector version
- When using Streamable HTTP transport, the oauth flow is not triggered when the server returns 401 (resolved in a released Inspector version) fix
- When using Streamable HTTP transport, the oauth flow is not triggered when the server returns 401 (resolved in a released Inspector version) root cause
- Streamable HTTP MCP client hangs on 401 instead of starting the OAuth flow
- Streamable HTTP MCP client hangs on 401 instead of starting the OAuth flow fix
- Streamable HTTP MCP client hangs on 401 instead of starting the OAuth flow root cause
- how to fix Streamable HTTP MCP client hangs on 401 instead of starting the OAuth flow
- mcp-inspector client hangs 401 instead starting oauth flow
Record metadata
| Status | verified |
|---|---|
| Confidence | medium |
| Created | 2026-06-21 |
| Updated | 2026-06-21 |
| Last verified | 2026-06-21 |
| Affected tools | mcp-inspector, mcp-server |
| Tags | mcp, streamable-http, oauth, 401, inspector, authorization, transport |
Common search queries
- mcp-streamable-http-client-no-oauth-on-401
- mcp streamable http client no oauth on 401
- Streamable HTTP MCP client hangs on 401 instead of starting the OAuth flow
- Streamable HTTP MCP client hangs on 401 instead of starting the OAuth flow fix
- Streamable HTTP MCP client hangs on 401 instead of starting the OAuth flow root cause
- streamable-http
- oauth
- inspector
- authorization
- transport
- mcp-inspector
- mcp-server
Symptoms
- connecting to an OAuth-protected MCP server over Streamable HTTP hangs
- log shows Error from MCP server: Error: Error POSTing to endpoint (HTTP 401) then no further progress
- the same server triggers the browser OAuth flow correctly via the SSE transport
Environment
| constraints | Streamable HTTP transport, OAuth-protected MCP server returning 401 |
|---|
Root cause
- The SSE client transport detected a 401 and started authorization.
- The Streamable HTTP client transport did not handle the 401 as an auth challenge, so no OAuth flow started and the connection stalled.
- It is a client/transport bug, not a server misconfiguration.
Fix
Upgrade to a client/Inspector/SDK version where Streamable HTTP triggers OAuth on 401 (resolved in a released Inspector version).
As an interim check, confirm it is transport-specific by trying the SSE transport, which handled 401-driven auth.
Verify the server returns a spec-compliant 401 with the expected authorization metadata.
Verification
Connect over Streamable HTTP to an OAuth-protected server on the fixed client.
Expected: A 401 triggers the authorization flow instead of hanging.
Workarounds
- Use the SSE transport temporarily if it handles the OAuth challenge while you upgrade.
Anti-patterns
- Concluding the OAuth server is broken when the client transport did not act on the 401.
- Staying on an old client version that lacks Streamable HTTP auth handling.
Sources
No matching fix?
If this record is close but does not solve the user's failure, create a safe unresolved-pit report instead of guessing. Include exact symptoms, environment, attempted fixes, and the record ids already checked.