{"version":"2.1.323","anchor":"mcp-oauth-issuer-mismatch-in-authorization-response-tolerat","canonical_anchor":"mcp-oauth-issuer-mismatch-in-authorization-response-tolerat","heading":"MCP sign-in can continue past an issuer mismatch with the v1 MCP client","tier":"notice","area":"MCP","scope":"individual","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.323\/e\/mcp-oauth-issuer-mismatch-in-authorization-response-tolerat","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.323","markdown":"### MCP sign-in can continue past an issuer mismatch with the v1 MCP client\n\nWith the v1 MCP client selected, an MCP sign-in no longer fails when the reply names an unexpected issuer and continues with the expected one\n\n**Unclear.** It is not clear how the v1 MCP client gets selected or whether it is selected by default.\n\n**What**\n\nSome MCP servers (outside tools connected through the Model Context Protocol) need you to sign in through OAuth, a standard login flow that ends with the server sending back an authorization reply. That reply names its issuer, the service that handled the sign-in. Before, a reply whose issuer did not match the one expected stopped the sign-in with an error.\n\nNow, when the v1 MCP client is selected, the issuer check is turned off. Claude Code logs \"Issuer mismatch in authorization response\" and continues the sign-in using the issuer it expected.\n\n**Why**\n\nThis lets sign-in work with servers that report their issuer inconsistently, but it relaxes a security check, so it is worth knowing when the v1 MCP client is in use.\n\n- Area: MCP\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 1\/5\n- Scope: individual\n- Heads-up: no"}