[BUG] Desktop: BYO OAuth MCP connect fails with malformed "Issuer mismatch (RFC 8414 §3.3)" error — same version-negotiation probe as #87713

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version

Related prior art in the same subsystem: #87713 (version-negotiation probe
misclassifying client-side OAuth errors), #90970, #88370. None reproduce this
exact symptom.

What's Wrong?

This is a regression: this exact Snowflake MCP connector worked in Claude
Desktop a few days ago and started failing with no changes to our config
(exact prior-working date/build not captured). It now fails every time.

Connecting a Claude Desktop HTTP MCP connector configured with a BYO OAuth
client (oauth.mode: "byo", explicit clientId/clientSecret/
authorizationServer) against a Snowflake-hosted MCP server fails
consistently with:

Version negotiation probe failed: Issuer mismatch in authorization server metadata (RFC 8414 §3.3): expected "https://<account>.snowflakecomputing.com/oauth%22, received "https://<account>.snowflakecomputing.com/oauth%22

Two things indicate this is a client-side bug rather than a real metadata
mismatch:

1. The error is byte-identical across materially different configs. We

tested: (a) the account hostname in the case documented by our internal
setup guide, (b) the same lowercase, (c) a from-scratch, manually-typed
(no paste) minimal config with only one authorizationServer field. All
three produced the exact same error text, including the %22 artifact —
config content has no effect on the reported "expected"/"received" values.

1. The message template itself is malformed. Both expected and

received open with a literal " but close with the literal characters
%22 instead of an actual " — on both sides, identically. That's
consistent with a broken string-interpolation in the probe's error
formatter (e.g. a hardcoded %22 where a real quote character or a
encodeURIComponent-style escape was intended), not a genuine RFC 8414
issuer comparison failure.

We independently confirmed Claude Code CLI (claude mcp add-json, same
server URL, same account hostname, same OAuth client ID/secret) connects and
authenticates successfully against the identical MCP server. This isolates
the bug to Claude Desktop's MCP connect path.

This also reproduces cross-platform: the reporter is on Windows, and a
colleague independently reproduced the identical error on macOS against the
same server — ruling out an OS-specific cause.

Given the identical "Version negotiation probe failed: ..." prefix and the
same BYO-OAuth-client scenario called out as broken in #87713 ("A
pre-registered OAuth client does not work around it ... the error is still
classified transport"), this looks like a sibling bug in the same
version-negotiation probe's error classifier/formatter — a different code
path than #87713 (which covers the no-cached-tokens, first-connect case)
but the same root feature.

What Should Happen?

The client should either:

• Correctly compare the issuer values (if there is a genuine mismatch) and

render the error with real values/quoting so users can tell what actually
differs, or

• Recognize this is a client-side probe/formatting bug and complete the OAuth

flow — as it does via Claude Code CLI against the identical server/config.

Steps to Reproduce

1. Claude Desktop, Developer mode enabled → Developer → Configure

Third-Party Inference → Connectors & extensions → + Add → Blank.

1. Configure an HTTP connector against a Snowflake-hosted MCP server that

requires OAuth via a Snowflake External OAuth / Security Integration,
e.g.:
``json
{
"transport": "http",
"name": "snowflake_test",
"url": "https://<account>.snowflakecomputing.com/api/v2/databases/<db>/schemas/<schema>/mcp-servers/<server>",
"oauth": {
"mode": "byo",
"clientId": "<client_id>",
"clientSecret": "<client_secret>",
"authorizationServer": ["https://<account>.snowflakecomputing.com/oauth"],
"callbackHost": "localhost",
"callbackPort": 8080
}
}
``

1. Click Sign in & test / Apply Changes.
2. Observe the error above. No browser OAuth window opens.
3. (Isolation) Configure the identical URL + OAuth client via Claude Code

CLI's claude mcp add-json and authenticate via /mcp — this succeeds,
confirming the server/account/credentials are correct.

Error Messages/Logs

Version negotiation probe failed: Issuer mismatch in authorization server metadata (RFC 8414 §3.3): expected "https://<account>.snowflakecomputing.com/oauth%22, received "https://<account>.snowflakecomputing.com/oauth%22

Failed request
HTTP https://<account>.snowflakecomputing.com/api/v2/databases/<db>/schemas/<schema>/mcp-servers/<server> → initialize

Is this a regression?

Yes. This exact Snowflake MCP connector worked a few days ago and started
failing with no config changes on our side (exact prior-working date/build
not captured, unfortunately). This matches the regression pattern already
established in #87713 (1.25927.0 → 1.32352.x broke first-time OAuth connect
for the same "version negotiation probe" subsystem) — suggesting an
auto-updated Desktop build is the trigger, not anything server- or
account-side.

Platform

Snowflake-hosted MCP server (External OAuth / Security Integration, BYO
OAuth client, confidential client with client secret)

Operating System

Windows (reporter). Independently reproduced on macOS by a colleague against
the same server/config — cross-platform, not OS-specific.

Claude Code Version

Claude Desktop 1.49585.0 (41ad1d) — notably later than the 1.32352.x build
cited in #87713, so this is not fixed by that later release.

---

*(Account hostname, database/schema/server names, and client ID redacted as
<account>/<db>/<schema>/<server>/<client_id> — real values are
internal infra and shouldn't go in a public issue.)*