Auth Failure Retry Handler `_hasCompletedAuthFlow`

[lokendra-ss]

Auth Retry Handling for Remote MCP Proxies

Current Behavior

We use _hasCompletedAuthFlow to prevent infinite recursion during MCP Server authentication, which works well for standard use cases.

The Challenge

When building custom proxies like mcp-remote or mcp-connector, we need more flexible authentication retry logic.

Remote MCP Servers often use scope-based authentication, where each tool requires specific permissions. This creates a scenario where:

1. A user adds a new tool to their MCP Server
2. When they try to execute it, the request returns a 401 Unauthorized error
3. This happens because the local access token stored in the proxy doesn't include the scope required for the new tool

Required Solution: Two-Tier Retry Strategy

Case 1: Token Refresh
Attempt to obtain a new access token using the existing refresh token (with updated scopes).

Case 2: Full Re-authentication
If token refresh fails, restart the entire authentication flow from scratch.

The Problem

Once _hasCompletedAuthFlow is set to true, any subsequent authentication attempts throw an error. This prevents Case 2 from being implemented, leaving proxies unable to handle full re-authentication scenarios.

Proposed Solution

Expose _hasCompletedAuthFlow through one of the following approaches:

• Add a public getter method to check the authentication state
• Make the variable public to allow direct access

This would enable custom proxy implementations to:

• Check the current authentication state
• Reset the flag when full re-authentication is needed
• Implement proper retry handling without functionality breakage

[felixweinberger]

this is currently labeled as a bug but it looks more like an enhancement request — the circuit breaker is working as designed to prevent infinite auth loops.\n\nthe existing code already resets _hasCompletedAuthFlow on successful responses and handles 403 insufficient_scope via upscoping. can you share a concrete scenario where the current flow doesn't work? ideally a minimal repro showing the exact sequence of requests/responses where you hit the "401 after successful auth" error and why the existing reset-on-success + upscoping logic isn't sufficient.\n\nalso, exposing private internals has API design implications — if we do this, we'd want to get the shape right. a callback/hook might be more flexible than a raw getter.