[BUG] Desktop: plugin MCP OAuth sign-in page silently not opened (denied_no_activation) if the confirm dialog isn't answered within ~5s

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [ ] I am using the latest version of Claude Code (the CLI embedded in Claude Desktop is 2.1.271; the latest on npm is 2.1.283. Desktop chooses the embedded version, so I can't update it independently)

What's Wrong?

In Claude Desktop (Code tab), authenticating an HTTP MCP server that comes from a plugin (Settings → Plugins → plugin → Connectors → the server) often never opens the sign-in page.

The flow is:

1. Click the button to authenticate the server.
2. Desktop runs mcpAuthenticate, discovers the OAuth metadata and builds the authorization URL (error=none).
3. Desktop shows a confirmation dialog: "Open <host> to authenticate <server>?" with Cancel / OK.
4. After clicking OK, nothing opens. Desktop only shows "Complete sign-in in your browser, then click Done".

main.log shows that Desktop itself refuses to open the URL: [artifactPopup] passthrough ... outcome: 'denied_no_activation'.

Whether it opens depends only on the time between the click in step 1 and the moment Desktop tries to open the URL. That time is the OAuth discovery round trips plus however long the user takes to press OK in the confirmation dialog. In 14 attempts on the same machine:

| click → authUrl built | click → open attempted | outcome |
|---|---|---|
| 2s | 5s | denied_no_activation |
| 2s | 13s | denied_no_activation |
| 2s | 11s | denied_no_activation |
| 3s | 5s | denied_no_activation |
| 1s | 2s | passed_through |
| 1s | 2s | passed_through |
| 4s | 6s | denied_no_activation |
| 1s | 2s | passed_through |
| 1s | 3s | passed_through |
| 4s | 12s | denied_no_activation |
| 4s | 5s | denied_no_activation |
| 3s | 3s | passed_through |
| 2s | 3s | passed_through |
| 2s | 7s | denied_no_activation |

Every attempt that reached the open step within 3s opened; every attempt that took 5s or more was denied. This matches the ~5s transient user activation window for window.open in Chromium, where the activation seems to be taken from the original click in step 1, not from the OK click in the confirmation dialog.

So the confirmation dialog itself consumes the activation window: a user who reads the dialog before pressing OK gets no sign-in page and no error.

The MCP server side is fine: the authorization URL that Claude Code builds (checked with claude mcp login --no-browser) returns 302 to the login page, and the page renders when opened in a browser.

What Should Happen?

Clicking OK in the confirmation dialog should always open the sign-in page. Either:

• open the URL as a result of the OK click itself (so the OK click provides the user activation), or
• skip the extra confirmation for plugin-provided MCP servers the user explicitly chose to authenticate.

At minimum, if opening is blocked, Desktop should show an error or the URL instead of silently waiting on "click Done".

Error Messages/Logs

[info] [CCD] LocalSessions.mcpAuthenticate: sessionId=local_…, server=plugin:<plugin>:<server>
[info] [CCD] mcpAuthenticate: "plugin:<plugin>:<server>" -> authUrl=<set> callbackExpected=true redirectScheme=localhost error=none
[info] [artifactPopup] passthrough {
  host_window: 'main',
  scheme: 'https',
  outcome: 'denied_no_activation',
  evidence: 'none',
  recent_artifact_click: false
}

Successful attempts log the same lines with outcome: 'passed_through'.

Steps to Reproduce

1. Install a plugin whose .mcp.json has a remote HTTP MCP server protected by OAuth (DCR, PKCE).
2. In Claude Desktop, open Settings → Plugins → the plugin → Connectors → the server, and start authentication.
3. When the "Open … to authenticate …?" dialog appears, wait about 5 seconds, then click OK.
4. The sign-in page does not open; main.log records denied_no_activation.
5. Repeat and click OK immediately: the page usually opens (passed_through).

The more time OAuth discovery takes (for example, a server behind a relayed tunnel where each new TLS connection takes 0.2–1s), the less time the user has to press OK.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Claude Code Version

2.1.271 (embedded in Claude Desktop 2.9939.2)

Platform

Claude Desktop, macOS 26.6.2