Atlassian MCP needs authorization on every invocation of the copilot cli

[rdondeti-crestron]

Describe the bug

Install Atlassian mcp authenticated now close copilot cli and reopen authorization requests pops up again

Affected version

 v1.0.18

Steps to reproduce the behavior

No response

Expected behavior

once authorized system should remember

Additional context

No response

[darosado-halostudios]

Still reproduces on CLI v1.0.48 (Windows 11, PowerShell 7). Adding evidence in case it helps narrow this down.

Symptom: Every CLI launch opens a browser to re-authorize Atlassian, even on sessions started minutes apart.
Config:

{
"mcpServers": {
"atlassian": {
"type": "http",
"url": "https://mcp.atlassian.com/v1/mcp",
"headers": {},
"tools": ["*"]
}
}
}

Relevant log excerpt from ~/.copilot/logs/:
[ERROR] Starting remote MCP client for atlassian with url: https://mcp.atlassian.com/v1/mcp
[ERROR] Connecting MCP client for atlassian...
[ERROR] MCP transport for atlassian closed
[ERROR] Server atlassian requires authentication, initiating OAuth flow
[ERROR] Registering with atlassian...
[ERROR] Opening browser for atlassian authentication...
[ERROR] Waiting for authorization in browser...
[ERROR] Completing authentication...
[ERROR] Successfully authenticated with atlassian

Note the Registering with atlassian... line. A fresh dynamic client registration is happening on each launch, not a token refresh.

State accumulating on disk: ~/.copilot/mcp-oauth-config/ has three distinct registrations, each with a different clientId and a different random loopback port for redirectUri:

• 834761c4...json serverUrl=/v1/sse clientId=ZKKCj8CmFPyG3UpJ redirect=:55836
• 882c8c5c...json serverUrl=/v1/mcp clientId=rxHcVriojSGImZa7 redirect=:50196
• c3aad2e8...json serverUrl=/v1/mcp clientId=GooJ5gnzpN7wKw6P redirect=:58905

The two /v1/mcp registrations are 91 seconds apart, both from this morning. Windows Credential Manager has four copilot-mcp-oauth/* entries (three matching the registrations above, one orphaned from a deleted registration).

Likely overlap with #2112 and #1491: the ephemeral redirect port changes the registration fingerprint each launch, so the cached token can't be looked up; the CLI then falls through to a brand-new dynamic client registration instead of either refreshing or reusing.

Happy to grab a full log or run a clean-slate repro if useful.

[bjoern-pag]

Confirming on macOS, CLI 1.0.49, against a self-hosted Atlassian-backed
MCP server inside a datacenter (URL redacted).

Experience

Every single copilot start opens the browser tab for full OAuth consent.
Same five log lines every time:

Starting remote MCP client for <redacted> ...
MCP transport for <redacted> closed
Server <redacted> requires authentication, initiating OAuth flow
Opening browser for <redacted> authentication...
Successfully authenticated with <redacted>

Over the last 7 days that has produced 14 distinct copilot-mcp-oauth
entries in the macOS keychain for the same single MCP server, none of
which were ever reused, all of which still hold refresh-token material.
The two on-disk ~/.copilot/mcp-oauth-config/<hash>.json records also
accumulate, each with a fresh clientId and a fresh loopback redirect
port - exact same fingerprint-rotation pattern darosado-halostudios
documented on Windows above.

What I tried (so others don't waste the cycles)

1. Flip "isStatic": true in the existing
   ~/.copilot/mcp-oauth-config/<hash>.json before launch. Verified
   across two clean restarts. No effect - CLI still does the full
   consent flow on each start. The flag is ignored.
2. Pin a static clientId / redirectUri in the same JSON. Same
   result; CLI overwrites with a fresh dynamic registration anyway.
3. macOS keychain hygiene wrapper. Wrote a small shell wrapper
   around copilot that does time-based GC of svce=copilot-mcp-oauth
   entries older than 14 days. This does not fix the re-consent loop -
   nothing user-side can - but it stops the keychain from accumulating
   dozens of stale refresh tokens. Useful as a stopgap until this
   issue is fixed.

Small observation that might help triage

First auth of the day takes ~38 s (interactive click). Subsequent
restarts within the same browser session complete in 4-5 s with no
visible click, because the upstream IdP silently re-issues the code.
So the user-facing severity feels low on day two onward, but the
underlying request/token churn (and the keychain bloat) is unchanged.

Related: #2036, #2783, #2112, #1491.