A rejected credential-helper token is now reported as its own MCP failure with clearer advice.
What's wrong with this entry?
A 401 or 403 from an MCP server whose Authorization header came from a configured headersHelper command is now reported as its own failure, severity "bad", rather than being lumped in with a static auth header rejection. The message tells you OAuth fallback is disabled when the helper supplies Authorization.
- Reported and telemetered as
mcp_connect_headers_helper_auth_rejected, alongside the existing static-header, CLI-bearer and first-party rejection codes. - Message text: "Server rejected the Authorization header minted by the configured headersHelper".
mcp_connect_headers_helper_auth_rejected, Server rejected the Authorization header minted by the configured 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