[BUG] Browser window stuck in loading state after successful MCP OAuth callback to Claude Desktop

Resolved 💬 4 comments Opened Jan 1, 2026 by poodle64 Closed Mar 3, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

After successfully completing MCP OAuth authentication with a third-party OAuth provider, the browser window that initiated the OAuth flow remains stuck in a "loading" state indefinitely. The authentication succeeds, Claude Desktop receives the callback, and the MCP server connects properly - but the browser UX is broken.

Important distinction: This is NOT a connection or authentication failure. Everything works correctly. The bug is purely about the browser window UX after the OAuth handoff.

Environment:

  • Claude Desktop (latest)
  • MCP server with OAuth via nginx reverse proxy + Authentik (third-party OAuth2 provider)
  • macOS

What Should Happen?

After OAuth authorization completes and Claude Desktop receives the callback:

  1. The browser should either:
  • Display a success message (e.g., "Authentication successful! You can close this window."), OR
  • Automatically close the browser tab/window
  1. The user should NOT need to manually close a stuck loading page

Error Messages/Logs

No error messages - the browser simply shows a loading spinner indefinitely. The actual OAuth flow succeeds as demonstrated by Claude Desktop successfully connecting to the MCP server.

Steps to Reproduce

  1. Configure an MCP server with OAuth authentication via a third-party provider (e.g., Authentik, Keycloak, or any OAuth2 provider)
  2. Add the MCP server to Claude Desktop configuration
  3. Start Claude Desktop and initiate a connection to the OAuth-protected MCP server
  4. Browser opens to the OAuth provider's login page
  5. Complete authentication (login to the OAuth provider)
  6. OAuth provider redirects back, browser prompts "Open in Claude Desktop?"
  7. Click "Open Claude Desktop" (or similar button)
  8. Expected: Browser shows success or closes
  9. Actual: Browser stays stuck on a loading/spinner page indefinitely

The MCP connection works correctly in Claude Desktop - tools are available and functional. Only the browser window is left in a broken state.

Claude Model

N/A (MCP OAuth UX issue)

Is this a regression?

Unknown - MCP OAuth with third-party providers is relatively new

Claude Code Version

Claude Desktop (latest)

Platform

Claude Desktop

Operating System

macOS

Terminal/Shell

N/A (Desktop app)

Additional Information

What works:

  • OAuth authentication completes successfully
  • Claude Desktop receives the callback properly
  • MCP server connects and exposes tools correctly
  • Token is stored and persists across sessions

What's broken:

  • Browser window UX after callback handoff
  • User must manually close the stuck loading window

OAuth flow context:

  • Using nginx auth_request for bearer token validation
  • Authentik as the OAuth2 provider with authorization_code flow
  • Claude's OAuth callback URL is https://claude.ai/api/mcp/auth_callback

This appears to be a missing success page or auto-close functionality in Claude's OAuth callback handler.

View original on GitHub ↗

This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗