Fix a missing Authorization header after MCP OAuth

Check the negotiated MCP revision before tracing requests

Use the protocol revision negotiated during initialization as the boundary for the trace. In the 2026-07-28 Streamable HTTP revision, each client message is a POST and a streaming result is an SSE response to that POST; the standalone GET stream and protocol-level session deletion used by 2025-11-25 were removed. A current server may therefore answer legacy GET or DELETE traffic with 405 even when OAuth is healthy.

The authorization rule is independent of whether the response is JSON or an SSE stream: an OAuth access token belongs in the Authorization header of every HTTP request from client to MCP server. Do not diagnose a missing bearer token by assuming every client uses the same GET, POST, or DELETE sequence.

Use the wire contract as the expected result

A completed browser consent screen proves only that the authorization portion progressed. It does not prove that the retried MCP request carried the resulting token. Current MCP guidance shows the client exchanging the code for an access token and then sending Authorization: Bearer followed by that token. The current Inspector documentation likewise describes persisting the tokens and automatically retrying the original refused request.

RFC 6750 defines Bearer credentials as the scheme, at least one space, and a non-empty token. A header containing only Bearer, a comma-joined pair of bearer values, or an old static credential is not equivalent to the required result. Keep tokens out of URLs and use TLS; capture only the header's presence, scheme, shape, and redacted length.

Separate OAuth from a configured static header

No Authorization header

Trace the retried MCP request after the callbackConfirm that the code exchange finished, then inspect the first MCP POST retried by the client. If the client records a token but sends no header, the failure is in request construction or an intermediary, not in browser consent.

Authorization: Bearer with no token

Test whether a blank placeholder is overriding OAuthA historical Inspector issue reported this exact shape in versions 0.16.8 and 0.16.9 after OAuth appeared to complete. A maintainer suggested disabling or removing the automatically added placeholder header and later asked the reporter to try 0.17.0 after clearing browser state. The reporter instead encountered a separate duplicate redirect-URI failure, so the issue does not confirm that either suggestion resolved the missing-token symptom.

A stale static value wins

Do not configure two owners for the same headerAn open TypeScript SDK report describes requestInit Authorization values overriding OAuth-derived values. Its linked July 2026 pull request proposes reversing merge precedence, but the pull request remained open when checked; verify the release you actually run instead of assuming the patch shipped.

Two bearer values are comma-joined

Remove duplicate injection pathsAn open SDK issue reproduces this with both requestInit.headers and a custom SSE fetch wrapper. For the affected pattern, use one injection point or merge with a case-insensitive Headers object and set(), then confirm exactly one redacted bearer value reaches the server.

Consent finished in a different surface

Check that the process making the request can read the tokenAn open GitHub Copilot CLI report describes a third-party OAuth MCP server showing a connected badge in the desktop app while sessions spawned by that app logged no cached tokens and marked the server needs-auth. The reporter attributes it to the app not handing its stored token to session clients on app 1.0.20 with bundled CLI 1.0.70. Treat it as one unresolved account for one client and server pair, and verify which process owns the credential before blaming header construction.

Reproduce the failure without exposing the credential

Open the client's network or HTTP debug view before reconnecting. Record the endpoint origin and path, negotiated MCP revision, request method, response status, whether WWW-Authenticate is present, and whether the failed request occurs before or after the OAuth callback. For Authorization, record only absent, Bearer-only, one redacted bearer value, duplicate values, or a static-header placeholder. Never copy the access token, refresh token, authorization code, PKCE verifier, cookie, or full header into an issue.

Repeat one harmless operation such as initialization or tools/list. Compare the initial unauthenticated request with the first retry after consent and, if used by that negotiated revision, the request that opens or resumes a stream. If the first retry has the correct header but a later request loses it, the fault is request-path specific. If every request carries one well-formed redacted bearer value but the server still returns 401, investigate expiry, revocation, issuer, resource, and audience rather than header absence.

Read the response before choosing a fix

401 after a missing or malformed header

Repair client-side bearer attachmentReconnect through the client's supported OAuth path after removing blank, stale, or duplicate header configuration. Do not paste a token into a URL or hard-code a captured token as a permanent fix.

401 with one well-formed bearer value

Treat token validity as a separate branchThe MCP authorization specification uses 401 for authorization required or an invalid token. Check the challenge and obtain a fresh token for the correct resource; header presence alone does not establish validity.

403 insufficient_scope

Do not debug it as a missing headerCurrent MCP guidance assigns 403 to insufficient permission and supports a new authorization flow for the required scope set. Preserve the working bearer path and request only the additional scopes.

OAuth command offered for static header auth

Confirm which mechanism owns AuthorizationA recent open Kilo CLI pull request reports that inferring OAuth for every remote server misdirected users when a missing environment variable produced a bad static header. This is one project's pending change, not evidence that all MCP clients share the behavior.

Choose the next guide from the observed boundary

Return to the troubleshooting directory when the trace shows a transport or connection failure before OAuth. Use the insufficient-scope guide when a correctly formed bearer request receives 403. Use the session-not-found guide only when the negotiated protocol revision actually uses MCP sessions; do not interpret a current revision's 405 on legacy DELETE as a missing bearer header.

Evidence boundary

The normative bearer and request-tracing guidance comes from the 2026-07-28 MCP authorization and transport specifications plus RFC 6750. Reproducible failure shapes come from public issue and pull-request records and remain qualified: some are open proposals, the historical Inspector report was closed without reporter-confirmed resolution of its missing-token symptom, the recent Kilo change is still open, and the token hand-off account is a single open report about one client pair. They demonstrate plausible client-side failure modes, not prevalence, compatibility across clients, or a guaranteed fix for an unnamed installation. No authenticated production request or secret was used.