Describe the bug
After signing in to a third-party OAuth MCP server (Atlassian Remote MCP, https://mcp.atlassian.com/v1/mcp) through the GitHub Copilot app UI, the server shows a green "Connected" badge, but none of its tools are ever available to the agent in the CLI sessions the app spawns. The first-party GitHub MCP server works fine. Restarting the app, re-enabling the server, re-signing-in, and updating the app do not help.
Root cause (from investigation): the green "Connected" badge reflects the app's OWN background/daemon MCP connection, authenticated with tokens the app stores in the OS credential store (Windows Credential Manager, service "copilot-mcp-oauth"). Each spawned session is a SEPARATE MCP client that obtains OAuth via host-delegation - it asks the app for a token at connect time. For first-party GitHub the app returns a token; for third-party servers the app cancels the host-token hand-back and only reconnects its own daemon so the badge resolves green. The session's token store is also ephemeral, so it cannot fall back to the tokens already cached on disk/keychain. Net effect: sessions never receive third-party credentials and mark the server "needs-auth", so no tools are exposed.
Affected version
GitHub Copilot CLI 1.0.70 (bundled in GitHub Copilot desktop app 1.0.20)
Steps to reproduce the behavior
- In the GitHub Copilot app, add the Atlassian MCP server (https://mcp.atlassian.com/v1/mcp) and complete the OAuth sign-in. The server shows a green "Connected" badge.
- Open any session and ask the agent to list its tools, or to use a Jira/Confluence tool.
- No atlassian-* tools are available to the agent.
- The session log (~/.copilot/logs/process-*.log) shows the server being marked needs-auth:
Starting remote MCP client for atlassian with url: https://mcp.atlassian.com/v1/mcp
Connecting MCP client for atlassian...
Server atlassian requires authentication, initiating OAuth flow
OAuth required for atlassian with no cached tokens; marking as needs-auth
Expected behavior
Once the app shows a third-party MCP server as "Connected", its tools should be available to the agent in the CLI sessions the app spawns, exactly like the first-party GitHub MCP server. The valid OAuth token the app already holds (and keeps refreshed) should be handed to the session, or the session should be able to read it from the shared persistent token store.
Additional context
- OS: Windows 11 Pro (build 10.0.26200), CPU x86_64 (AMD64)
- GitHub Copilot desktop app: 1.0.20; bundled CLI: 1.0.70
- MCP server: Atlassian Remote MCP (HTTP + OAuth), https://mcp.atlassian.com/v1/mcp
Evidence the tokens themselves are valid: using the refresh token cached by the app to mint a fresh access token and calling the Atlassian MCP endpoint directly returns initialize=200 and tools/list with all 31 tools. Injecting that same token as a static "Authorization: Bearer " header on the atlassian entry in ~/.copilot/mcp-config.json makes sessions connect and load all 31 tools. This confirms the only missing piece is the app -> session token hand-off for third-party servers.
Relevant app policy log string observed: "MCP OAuth non-first-party server; cancelling host-token and kicking daemon-owned reconnect so the status badge can resolve".
Suggested fix: bridge third-party MCP OAuth tokens to spawned sessions the same way the first-party GitHub token is handed off (or let sessions read the persistent "copilot-mcp-oauth" token store), instead of cancelling the host-token hand-back for non-first-party servers.
Impact: all third-party OAuth MCP servers are effectively unusable inside app sessions despite showing "Connected"; only first-party GitHub MCP works.
Workaround (insufficient): a static Authorization header in mcp-config.json works, but the access token expires after a few hours and rotates, so it breaks whenever the machine is offline past expiry and needs an external refresher - not a real fix
Describe the bug
After signing in to a third-party OAuth MCP server (Atlassian Remote MCP, https://mcp.atlassian.com/v1/mcp) through the GitHub Copilot app UI, the server shows a green "Connected" badge, but none of its tools are ever available to the agent in the CLI sessions the app spawns. The first-party GitHub MCP server works fine. Restarting the app, re-enabling the server, re-signing-in, and updating the app do not help.
Root cause (from investigation): the green "Connected" badge reflects the app's OWN background/daemon MCP connection, authenticated with tokens the app stores in the OS credential store (Windows Credential Manager, service "copilot-mcp-oauth"). Each spawned session is a SEPARATE MCP client that obtains OAuth via host-delegation - it asks the app for a token at connect time. For first-party GitHub the app returns a token; for third-party servers the app cancels the host-token hand-back and only reconnects its own daemon so the badge resolves green. The session's token store is also ephemeral, so it cannot fall back to the tokens already cached on disk/keychain. Net effect: sessions never receive third-party credentials and mark the server "needs-auth", so no tools are exposed.
Affected version
GitHub Copilot CLI 1.0.70 (bundled in GitHub Copilot desktop app 1.0.20)
Steps to reproduce the behavior
Starting remote MCP client for atlassian with url: https://mcp.atlassian.com/v1/mcp
Connecting MCP client for atlassian...
Server atlassian requires authentication, initiating OAuth flow
OAuth required for atlassian with no cached tokens; marking as needs-auth
Expected behavior
Once the app shows a third-party MCP server as "Connected", its tools should be available to the agent in the CLI sessions the app spawns, exactly like the first-party GitHub MCP server. The valid OAuth token the app already holds (and keeps refreshed) should be handed to the session, or the session should be able to read it from the shared persistent token store.
Additional context
Evidence the tokens themselves are valid: using the refresh token cached by the app to mint a fresh access token and calling the Atlassian MCP endpoint directly returns initialize=200 and tools/list with all 31 tools. Injecting that same token as a static "Authorization: Bearer " header on the atlassian entry in ~/.copilot/mcp-config.json makes sessions connect and load all 31 tools. This confirms the only missing piece is the app -> session token hand-off for third-party servers.
Relevant app policy log string observed: "MCP OAuth non-first-party server; cancelling host-token and kicking daemon-owned reconnect so the status badge can resolve".
Suggested fix: bridge third-party MCP OAuth tokens to spawned sessions the same way the first-party GitHub token is handed off (or let sessions read the persistent "copilot-mcp-oauth" token store), instead of cancelling the host-token hand-back for non-first-party servers.
Impact: all third-party OAuth MCP servers are effectively unusable inside app sessions despite showing "Connected"; only first-party GitHub MCP works.
Workaround (insufficient): a static Authorization header in mcp-config.json works, but the access token expires after a few hours and rotates, so it breaks whenever the machine is offline past expiry and needs an external refresher - not a real fix