Claude Desktop spawns two instances causing OAuth callback server to die before receiving callback

[kunyback]

Bug Description

When Claude Desktop starts an MCP server, it always spawns two instances of mcp-remote in rapid succession (~1 second apart). The first instance opens the OAuth callback server on port 21371 and waits for authorization, but Claude Desktop sends an intentional shutdown to the first connection almost immediately. When the user completes the OAuth flow in the browser, the callback reaches port 21371 — but that instance has already been shut down, resulting in "site cannot be reached" error in the browser.

Steps to Reproduce

1. Configure mcp-remote with a custom OAuth 2.1 server in Claude Desktop
2. Claude Desktop spawns instance A → opens OAuth callback server on port 21371
3. ~1 second later, Claude Desktop shuts down instance A (Server transport closed (intentional shutdown)) and spawns instance B
4. Instance B sees instance A's lockfile still active and defers to it via wait-for-auth polling
5. User completes OAuth in browser → browser redirects to localhost:21371 → connection refused (server is dead)

Log Evidence

[54792] OAuth callback server running at http://127.0.0.1:21371
[54792] Authentication required. Waiting for authorization...
Server transport closed (intentional shutdown)   ← Claude Desktop kills instance A
[54862] Another instance is handling authentication on port 21371 (pid: 54792)
[54862] Waiting for authentication from the server on port 21371...
[54862] Querying: http://127.0.0.1:21371/wait-for-auth   ← polling forever, nobody home

Browser shows: 사이트에 연결할 수 없음 (ERR_CONNECTION_REFUSED on localhost:21371)

Root Cause

Claude Desktop intentionally shuts down the first MCP connection and re-initializes. The first instance owns the callback server (port 21371) but gets killed before the user can complete OAuth. The second instance defers to the first via the lockfile mechanism, but the first is already dead.

Expected Behavior

OAuth callback should be received and token exchange should complete successfully.

Environment

• mcp-remote: latest (0.1.37+)
• Claude Desktop on macOS
• Custom OAuth 2.1 server with PKCE + dynamic client registration

Workaround

None found. The two-instance spawn behavior from Claude Desktop makes OAuth via mcp-remote currently broken.

[dirien]

Hitting what looks like the same symptom on macOS with Claude Desktop.

• mcp-remote version: 0.1.31 (also reproduced after upgrading to 0.1.38)
• Node: v22.17.1
• Server: a remote FastMCP server behind CloudFront with Google OAuth

Repro: click the auth link from Claude Desktop, sign in with Google. Browser is redirected back to http://localhost:<port>/oauth/callback?code=...&state=... and shows ERR_CONNECTION_REFUSED. Hitting Reload a few seconds later succeeds — the page returns "Authorization successful! You may close this window and return to the CLI." So the listener does eventually bind, just after the redirect arrives.

Consistent with the duplicate-spawn / race scenarios in this issue and #141 / #179. Happy to attach mcp-remote debug logs from a fresh repro if useful — let me know which env vars / flags you'd like enabled.