MCP OAuth (Copilot Desktop app): non-first-party HTTP servers cancel host-token then never launch the "runtime browser flow" they deferred to — no auth, no error, no popup

[admatt01]

Describe the bug
In the GitHub Copilot Desktop app, remote MCP servers configured with "type": "http" that are non-first-party (e.g. Atlassian, incident.io) fail to authenticate. Toggling the server off/on in Settings produces no browser popup and no visible error — the server simply never connects.

Affected version
Desktop app shell: v1.0.15 (latest, confirmed via in-app update check)
Bundled Copilot CLI engine: v1.0.69-0 (AppData\Local\github-copilot-sdk\cli\1.0.69-0\copilot.exe)

Steps to reproduce
Add a non-first-party remote MCP server with "type": "http" and a url in mcp-config.json (e.g. https://mcp.atlassian.com/v1/mcp/authv2)
Enable it via Settings → MCP servers in the Desktop app
Toggle it off, then on again
Observe: no browser window ever opens; the server stays disconnected with no user-facing error

Expected behavior
A browser window should open for OAuth consent, as it does for the raw copilot CLI and for local-type servers wrapped in npx mcp-remote.

Actual behavior
~/.copilot/logs/github-app..log shows this single log line and nothing further:

github_app::session::manager::mcp_status: MCP OAuth non-first-party server; cancelling host-token so runtime browser flow runs server_name=

This line repeats on every toggle attempt (confirmed 43 occurrences across multiple sessions for both atlassian and incident.io), but there is no subsequent log entry anywhere indicating the "runtime browser flow" it defers to is ever actually invoked — no browser-launch attempt, no OAuth URL, no error surfaced to the user.

## Root cause hypothesis
This behavior appears tied to the MCP host token-injection OAuth rework shipped in copilot-cli v1.0.66 (2026-06-30 changelog entry: "Added runtime telemetry for the MCP host token-injection OAuth flow, recording when an OAuth broadcast is emitted to the host and how the host responds (token or cancelled)"). For non-first-party servers, the host correctly identifies it should defer to a client-side browser flow and cancels its own token injection — but that deferred browser flow is never triggered inside the Desktop app shell.

## Workaround
Reconfiguring the server as a local type wrapping npx mcp-remote bypasses the broken Desktop-app host/browser-flow handoff entirely, since mcp-remote runs its own independent OAuth implementation:

```json
"atlassian": {
  "type": "local",
  "command": "npx",
  "args": ["--yes", "mcp-remote", "https://mcp.atlassian.com/v1/mcp"]
}

This works reliably. Native "type": "http" does not, for any non-first-party server, in the Desktop app.

Additional context

Possibly related to #2536, but distinct: that issue is about the raw copilot CLI's "Opening browser for X authentication..." log line firing and a browser genuinely opening, just re-registering (DCR) on every launch. In this Desktop-app case, the browser-flow deferral log line fires but no browser-launch attempt is ever logged afterward — a different failure point entirely (host→client handoff, not CLI OAuth caching).