When MCP is using oAuth it is not visible in chat

[ptrstpp950]

I'm using official Miro MCP in GitHub Copilot App with oAuth:

• I see it in settings
• I can sign-in in settings

In chat it is not found at all (see below), but in Copilot CLI it works like a charm.

In Copilot CLI it just works:

Configuration is really simple:

The question is: what should I do? Or there is a bug?

[JakubAnderwald]

I have the same symptom when working with 1.0.21. After downgrading to 1.0.17 Miro MCP works fine, this looks like a regression.

[JakubAnderwald]

I did some debugging locally, here's my findings. Maybe they'll be helpful for the team behind github copilot app:

Confirming this bug — additional reproduction + log-level root cause data

Environment: macOS (Darwin), arm64. Reproduced on app v1.0.21

What the logs show

The app writes per-process logs to ~/.copilot/logs/ (github-app.<pid>.log for the main process, process-<timestamp>-<pid>.log per session daemon). Digging through them surfaced a consistent pattern:

1. Every session daemon starts cold and fails auth for OAuth-based third-party servers:

[ERROR] worker quit with fatal: Transport channel closed, when AuthRequired(
    AuthRequiredError { www_authenticate_header: "https://<mcp-server>/.well-known/oauth-protected-resource" }
)
[ERROR] OAuth required for <server> with no cached tokens; marking as needs-auth

2. The main app process resolves this via cached tokens — but the resolution doesn't reliably reach the session that needs it:

mcp_auth_request_handler: MCP OAuth non-first-party server; cancelling host-token and kicking daemon-owned reconnect so the status badge can resolve  server_name=<server>
mcp_status_third_party_reconnect: third-party MCP server reconnected via cached OAuth tokens  server_name=<server>

Critically, this success is logged against a different session_id than the session that's actually stuck waiting — consistent with "works in Settings, not in chat," since Settings' health check and an open chat session appear to be resolved independently.

3. The clearest signal is a recurring "live-session refresh" telemetry line, which never converges for the affected session:

mcp_status: extensibility live-session refresh completed session_id=<id> mcp_stale=true observed_session_mcp=<N> target_session_mcp=<M> duration_ms=<...>

In one captured case, this fired 4 times over ~25 seconds for the same session, with observed_session_mcp/target_session_mcp at 0/2, 0/3, 0/1, then 1/3 — never reaching parity — right up through the point a chat message was actually sent. Tools from the missing servers were simply absent from that session's tool context.

4. Important nuance — not a strict "always fails" per-session ordering bug. Comparing sibling session daemons spawned within the same few seconds: some did successfully log Service initialized as client for the exact same OAuth-based servers within ~0.5–1.5s of the initial 401 (confirmed via each server's declared server_info.name), while another daemon spawned in the same window never got past partial mcp_stale=true. This looks less like a fixed startup-ordering race and more like contention/inconsistency across concurrently-running session daemons reconciling against the same OAuth token state — some win the race, some don't, and the ones that don't get no further retry trigger once the session is idle.

Suggested angles for a fix

• Single-flight / broadcast the OAuth reconnect result for a given MCP server to every active session daemon watching it, not just whichever session triggered the status check.
• Give the session daemon its own bounded retry/backoff for needs-auth servers instead of depending entirely on an external "kick" from the main process.
• Support hot-reloading tools into a session whose tool context was already sent to the model, once mcp_stale clears.

Happy to share full (sanitized) logs privately if useful — didn't paste raw log files here since they include internal server URLs from our tenant.