Summary
Since upgrading to 1.0.79 , connecting to the Atlassian remote MCP server ( https://mcp.atlassian.com/v1/mcp ) fails during OAuth discovery with:
MCPOAuthError: Incompatible authorization server: authorization server advertised
an issuer that does not match the URL its metadata was discovered from
(RFC 8414 §3.3); refusing to connect
The same server, same account, same on-disk state works on 1.0.71 . This appears to be a strict-issuer-validation regression, or at minimum a newly-enforced check that has no override for known-broken upstream metadata.
Environment
• OS: macOS (Darwin)
• Copilot CLI: 1.0.79 (broken) / 1.0.71 (working)
• MCP server: Jira/Atlassian → https://mcp.atlassian.com/v1/mcp
Reproduction
- Start a fresh copilot session on 1.0.79 with the Atlassian MCP server configured.
- Attempt /mcp auth Jira/Atlassian (or let it auto-init).
- See the error above; server status stays at connecting .
/mcp reload does not help. Wiping ~/.copilot/mcp-oauth-config/ does not help.
Root cause (Atlassian side)
Atlassian's metadata document violates RFC 8414 §3.3 — the advertised issuer doesn't match the discovery URL host:
$ curl -s https://mcp.atlassian.com/.well-known/oauth-authorization-server | jq .issuer
"https://cf.mcp.atlassian.com"
Discovery host is mcp.atlassian.com ; advertised issuer is cf.mcp.atlassian.com . Per §3.3, "the issuer value returned MUST be identical to the authorization server's issuer identifier value into which the well-known URI string was inserted to create the URL used to retrieve the metadata."
So Atlassian owns the underlying bug, but…
Why this is still a CLI issue
• 1.0.71 tolerates this and OAuth completes successfully (confirmed in an active session that re-authed today at 2026-08-13T16:35:35Z with a completely empty ~/.copilot/mcp-oauth-config/ ).
• 1.0.79 hard-fails with no override.
This is a regression that silently breaks every new session for a very widely used remote MCP server, with no user-facing way to opt into looser validation while Atlassian fixes their metadata.
Requested fix
Any one of:
- Relax the check to a warning until Atlassian corrects their document.
- Add an opt-in config flag per server (e.g. oauth: { allow_issuer_mismatch: true } or oauth: { trusted_issuers: [...] } ).
- A global --allow-oauth-issuer-mismatch / env var escape hatch.
Option 2 is safest — scoped per server, users still get the benefit of §3.3 everywhere else.
Evidence
Working session log (1.0.71) — cold OAuth, empty cache, success:
2026-08-13T16:35:34.741Z Server Jira/Atlassian requires authentication, initiating OAuth flow
2026-08-13T16:35:35.025Z OAuth authentication required for Jira/Atlassian
2026-08-13T16:35:35.064Z Successfully authenticated with Jira/Atlassian
2026-08-13T16:35:35.364Z MCP client for Jira/Atlassian connected, took 297ms
Failing session log (1.0.79) — same server, same host, same wiped cache:
MCPOAuthError: Incompatible authorization server: authorization server advertised
an issuer that does not match the URL its metadata was discovered from
(RFC 8414 §3.3); refusing to connect
Related
Also worth reporting to Atlassian so the underlying metadata gets fixed — happy to file that separately, but the CLI-side escape hatch is what unblocks users today
Summary
Since upgrading to 1.0.79 , connecting to the Atlassian remote MCP server ( https://mcp.atlassian.com/v1/mcp ) fails during OAuth discovery with:
MCPOAuthError: Incompatible authorization server: authorization server advertised
an issuer that does not match the URL its metadata was discovered from
(RFC 8414 §3.3); refusing to connect
The same server, same account, same on-disk state works on 1.0.71 . This appears to be a strict-issuer-validation regression, or at minimum a newly-enforced check that has no override for known-broken upstream metadata.
Environment
• OS: macOS (Darwin)
• Copilot CLI: 1.0.79 (broken) / 1.0.71 (working)
• MCP server: Jira/Atlassian → https://mcp.atlassian.com/v1/mcp
Reproduction
/mcp reload does not help. Wiping ~/.copilot/mcp-oauth-config/ does not help.
Root cause (Atlassian side)
Atlassian's metadata document violates RFC 8414 §3.3 — the advertised issuer doesn't match the discovery URL host:
$ curl -s https://mcp.atlassian.com/.well-known/oauth-authorization-server | jq .issuer
"https://cf.mcp.atlassian.com"
Discovery host is mcp.atlassian.com ; advertised issuer is cf.mcp.atlassian.com . Per §3.3, "the issuer value returned MUST be identical to the authorization server's issuer identifier value into which the well-known URI string was inserted to create the URL used to retrieve the metadata."
So Atlassian owns the underlying bug, but…
Why this is still a CLI issue
• 1.0.71 tolerates this and OAuth completes successfully (confirmed in an active session that re-authed today at 2026-08-13T16:35:35Z with a completely empty ~/.copilot/mcp-oauth-config/ ).
• 1.0.79 hard-fails with no override.
This is a regression that silently breaks every new session for a very widely used remote MCP server, with no user-facing way to opt into looser validation while Atlassian fixes their metadata.
Requested fix
Any one of:
Option 2 is safest — scoped per server, users still get the benefit of §3.3 everywhere else.
Evidence
Working session log (1.0.71) — cold OAuth, empty cache, success:
2026-08-13T16:35:34.741Z Server Jira/Atlassian requires authentication, initiating OAuth flow
2026-08-13T16:35:35.025Z OAuth authentication required for Jira/Atlassian
2026-08-13T16:35:35.064Z Successfully authenticated with Jira/Atlassian
2026-08-13T16:35:35.364Z MCP client for Jira/Atlassian connected, took 297ms
Failing session log (1.0.79) — same server, same host, same wiped cache:
MCPOAuthError: Incompatible authorization server: authorization server advertised
an issuer that does not match the URL its metadata was discovered from
(RFC 8414 §3.3); refusing to connect
Related
Also worth reporting to Atlassian so the underlying metadata gets fixed — happy to file that separately, but the CLI-side escape hatch is what unblocks users today