Agentforce Vibes does not handle OAuth deep link callbacks for MCP Server authentication

[djodrell]

What happened?

When configuring an external MCP server that requires OAuth 2.0 authentication, Agentforce Vibes correctly initiates the OAuth flow, but it fails to process the returning deep link callback. (vscode.window.registerUriHandler)

During the discovery and authorize phases, the extension generates and sends a redirect_uri in this format: vscode://salesforce.salesforcedx-einstein-gpt/mcp-auth/callback/<server_hash>

However, when the identity provider successfully redirects the browser back to that exact URI with the authorization code, VS Code comes to the foreground but the extension silently ignores the URI. The authentication flow hangs and never completes. (Note: This same OAuth flow works perfectly with other MCP clients like Claude and Cline).

Steps to reproduce

1. Configure an MCP server in Agentforce Vibes that utilizes OAuth authentication.
2. Initiate the connection, which opens the browser for authentication.
3. Complete the authentication in the browser.
4. The browser performs a 302 redirect back to the extension's requested callback URI (vscode://salesforce.salesforcedx-einstein-gpt/mcp-auth/callback/...).
5. Notice that VS Code comes to the foreground but does not complete the auth flow.

Additional context

You can manually reproduce the missing handler by running this command in a terminal (tested on mac):
open "vscode://salesforce.salesforcedx-einstein-gpt/mcp-auth/callback/1234567890abcdef1234567890abcdef?code=test_code&state=test_state"

Salesforce Telemetry ID

ecf33eb24ba4ff7c33e35cab1c102d7a22a9f333.

[mohanraj-r]

Thanks for the detailed write-up — this looks like a real gap worth confirming. Could you let us know whether this still happens on the latest Agentforce Vibes 4.x release? MCP connection and auth handling has changed substantially since this was filed.

If it still reproduces, it would help to know which MCP server/client you're connecting to (name and auth flow, without sharing anything sensitive), and whether you see the same behavior with a different remote MCP server. We'll keep this open pending that.