[BUG] Slack remote MCP (mcp.slack.com) unauthenticatable: no DCR + CIMD gated on unadvertised flag; 2.1.195 update orphaned the previously-working stored credential

Preflight Checklist

• [x] I have searched existing issues — closest are #18009 (Slack plugin, v2.1.6, same error string), #26675 / #67258 (pre-configured client-id paths). None contain the binary/metadata forensics below.
• [x] This is a single bug report
• [x] Reproduced on the latest version (2.1.197)

What's Wrong?

A direct (user-scoped) HTTP MCP server pointing at Slack's official remote MCP, https://mcp.slack.com/mcp, had worked zero-config for months. Immediately after the auto-update to 2.1.195 (2026-07-07), it stopped, and every authentication attempt since (including /mcp → Authenticate on 2.1.197) fails with:

SDK auth failed: Incompatible auth server: does not support dynamic client registration

claude mcp logout slack + clean-slate re-auth does not help. Headless (-p) sessions report the server "needs authentication, unavailable in this non-interactive session" — automation is fully blocked. Users in orgs that don't allow creating their own Slack app have no workaround, since the --client-id escape hatch (#26675) requires exactly that.

Forensics (binary string analysis + live/archived metadata)

I compared the shipped binaries for 2.1.193 (last-working generation), 2.1.195 and 2.1.197, and fetched Slack's AS metadata live and from the Wayback Machine. Corrections to my own initial regression theory included:

1. The throwing code is the embedded MCP SDK registerClient — if (!metadata.registration_endpoint) throw Error("Incompatible auth server: does not support dynamic client registration").
2. The auth decision logic is byte-identical in 2.1.193, 2.1.195 and 2.1.197: when no stored client info exists, CIMD is used only if the AS advertises it —

``js
let y = c?.client_id_metadata_document_supported === true, S = e.clientMetadataUrl;
if (y && S) m = { client_id: S } // CIMD: client_id = https://claude.ai/oauth/claude-code-client-metadata
else { /* falls through to DCR → the error */ }
``
So this specific function did not regress at 2.1.195.

1. Slack's AS metadata (https://mcp.slack.com/.well-known/oauth-authorization-server) contains neither registration_endpoint nor client_id_metadata_document_supported — verified live (2026-07-09) and in the only Wayback snapshot (2026-04-29, identical keys). The server didn't change either.

Conclusion

Fresh zero-config OAuth against mcp.slack.com cannot succeed on any recent build (at least 2.1.193→2.1.197, and per the April snapshot, likely much longer): no stored client → CIMD skipped (flag not advertised) → DCR attempted → hard fail. My previously-working setup was running on a stored keychain credential (Claude Code-credentials blob) obtained under some earlier mechanism. What the 2.1.195 update actually did was invalidate/orphan that stored credential (working at ~09:00, dead immediately after the 10:06 auto-update) — exposing the latent fresh-auth impossibility.

So there appear to be two bugs:

• (a) Credential loss on update: the 2.1.195 upgrade orphaned a valid stored OAuth credential for a remote MCP server.
• (b) Latent: no viable auth path for mcp.slack.com without a user-supplied client id. Suggested fixes: attempt CIMD (client_id = clientMetadataUrl) even when the AS doesn't advertise client_id_metadata_document_supported (try-then-fallback, some servers accept it unadvertised), and/or ship a registered client for the first-party Slack MCP, and/or coordinate with Slack to advertise CIMD if their server accepts it.

Environment

• Claude Code: stored credential worked ≤2.1.194, orphaned by the 2.1.195 auto-update (2026-07-07); fresh auth broken on 2.1.195 and 2.1.197 (re-verified 2026-07-09)
• Install: Homebrew cask, macOS (Darwin 25.5.0)
• Server config: user-scoped slack HTTP server → https://mcp.slack.com/mcp, no client credentials configured