An MCP headersHelper that mints an Authorization header now suppresses the OAuth flow.
What's wrong with this entry?
If an MCP server's headersHelper command mints an Authorization header, Claude Code no longer layers an OAuth flow or first-party auto-auth on top of it, matching what it already did for a statically configured Authorization header.
- Resolved headers are now computed once up-front for
sse,httpandwsservers, before any transport is built, and checked for an Authorization key. - Driven entirely by the
headersHelperconfig key, which the sse, http and ws server schemas accept. No feature flag.
headersHelper
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.238
Zip-archive plugin entries can carry their own fetch credentials
Both mention header helper
-
v2.1.238
MCP header-minting commands run through the shared trusted-command runner
Both mention header helper
-
v2.1.238
Marketplace validation flags unsafe archive credential setups
Both mention header helper