[BUG] headersHelper on http transport still falls into "Incompatible auth server: does not support dynamic client registration" on 2.1.211 (regression from #53267 persists)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

This is a fresh reproduction of #53267 on a current version (2.1.211), confirming the regression it describes is still present, not resolved by the fix mentioned in the docs for v2.1.193.

Config (.mcp.json):

"azure-devops": {
"type": "http",
"url": "https://mcp.dev.azure.com/abacai",
"headers": {
"X-MCP-Toolsets": "repos,pipelines,wiki,work,testplan",
"X-MCP-Readonly": "true"
},
"headersHelper": "python .claude/mcp-servers/ado_headers.py || python3 .claude/mcp-servers/ado_headers.py"
}
ado_headers.py shells out to az account get-access-token --resource https://mcp.dev.azure.com and returns {"Authorization": "Bearer <token>"}. Azure AD access tokens for this resource expire in roughly 60–90 minutes.

Tool calls succeed for the first ~hour of a session. After the underlying AAD token expires, every subsequent tool call to this server fails immediately with:

Incompatible auth server: does not support dynamic client registration
There is no self-heal — the session stays stuck for the rest of the session. The only workaround is /mcp → reconnect/clear authentication on the server, which tears down the transport and re-invokes headersHelper.

This matches the second failure variant described in a comment on #53267 (by @TanmayVartak), which traced the regression to v2.1.118: on a 401, Claude Code attempts OAuth discovery instead of re-running headersHelper directly, and when the server's auth endpoint doesn't support Dynamic Client Registration, that discovery attempt fails hard with no fallback.

Separately, the docs at https://code.claude.com/docs/en/mcp state: "As of v2.1.193, if a tool call returns 401 Unauthorized or 403 Forbidden, Claude Code automatically re-runs the helper, reconnects with the fresh headers, and retries the call once." That does not match observed behavior on 2.1.211.

What Should Happen?

When a headersHelper-configured server returns 401/403 and OAuth discovery either fails or finds no OAuth server at all, Claude Code should fall back to tearing down and rebuilding the transport (re-invoking headersHelper) rather than treating it as fatal.

Error Messages/Logs

Incompatible auth server: does not support dynamic client registration

Steps to Reproduce

1. Configure an http MCP server with headersHelper returning a ~1hr-TTL bearer token, pointed at a server whose OAuth discovery endpoint doesn't support DCR.
2. Call a tool — works.
3. Wait for token TTL to elapse with no calls to this server.
4. Call a tool again.

Expected: helper re-runs, request succeeds. Actual: Incompatible auth server..., no recovery without manual /mcp reconnection.

Claude Model

Sonnet (default)

Is this a regression?

Not verified firsthand — I've only run this config on 2.1.211. But per the comment on #53267, yes, this is a known regression, traced to v2.1.118 (previously worked on 2.1.117).

Last Working Version

_No response_

Claude Code Version

2.1.211

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Other

Additional Information

Related
#53267 (closed by stale-bot, not fixed — this is the requested fresh reproduction)