MCP OAuth now checks a server's echoed issuer, but only records mismatches rather than blocking.
tengu_mcp_issuer_strict_echo Not enough to sayNothing here resolved what this flag was doing on this version, so nothing here should be read as on or off.
This account: no value returned · anonymous baseline: no value returned · compiled default in v2.1.224: on
These values were read against a different version of Claude Code, so treat them as the nearest reading available instead of one taken on this release.
Read once, for one account on one subscription tier, against v2.1.224. It isn't a statement about your account. What a flag value here can and cannot tell you
What's wrong with this entry?
During MCP OAuth discovery Claude Code now validates itself that the issuer a server echoes back matches the URL that was asked for, at three points: the RFC 9728 chain, the legacy path fallback and refresh rediscovery. Controlled by tengu_mcp_issuer_strict_echo, whose in-source fallback is "observe": mismatches are recorded and the connection proceeds. Only a remote config value switches it to enforce, where a cross-origin echo fails the connection.
- The SDK's own checks are turned off (
skipIssuerMetadataValidation,skipIssuerValidation) in favour of the in-house comparison, on SSE and HTTP transports. - Mismatches emit
tengu_mcp_oauth_issuer_echo_mismatchwith site, mode, outcome, an origin relation ofsame_origin,cross_originorunparseable, the differing parts (scheme, host, port, path, query, fragment, userinfo, normalization_only) and hashed issuers. - In enforce mode the failure raises
IssuerEchoCrossOriginError, surfaces as a newissuer_echo_deniedoutcome for token refresh and revoke, and is excluded from retry.
tengu_mcp_issuer_strict_echo, Issuer echo cross-origin mismatch (RFC 8414 \xA73.3): expected
Strings lifted out of the shipped bundle, so the claim above can be checked against them.