Claude Desktop spawns two mcp-remote processes causing Invalid code_verifier
On Windows 11 with mcp-remote 0.1.37, Claude Desktop spawns two mcp-remote processes for the same MCP server, and they race through OAuth DCR + PKCE by writing to the same cache files, so login fails with "Invalid code_verifier". Clearing ~/.mcp-auth and restarting does not help, and no _tokens.json file is created. What changed in mcp-remote to fix this, and what workaround works on 0.1.37?
Originally asked on GitHub: https://github.com/punkpeye/mcp-remote/issues/251
3 answers
The maintainer says the double-spawn race should be fixed as of mcp-remote 0.1.40 and closed the issue as completed. A commenter also reproduced the problem independently on macOS with mcp-remote@0.1.37, seeing the same PKCE verifier overwrites and repeated OAuth tabs.
Root cause: Claude Desktop launched two mcp-remote processes at once, and both ran the OAuth DCR + PKCE flow. Each wrote a new PKCE verifier to the same file under ~/.mcp-auth, so the process that received the browser callback read the other process's verifier and the token exchange failed with "Invalid code_verifier" (or invalid_grant).
To reproduce, the issue used claude_desktop_config.json with "command": "C:\nvm4w\nodejs\npx.cmd" and args ["mcp-remote", "https://my-mcp-server.com/mcp (opens external site)", "--debug"], after clearing auth state with rm -rf ~/.mcp-auth/.
What changed in 0.1.40, per the maintainer:
- Each process gets its own PKCE verifier file, code_verifier_.txt, so parallel processes no longer overwrite each other (PR #315).
- The second process no longer dies with EADDRINUSE; it falls back to a free port and re-registers with the matching redirect_uri (PR #262).
The maintainer notes this makes the duplicate spawn survivable; it does not stop Claude Desktop from spawning two processes.
Workaround that worked on 0.1.37: quit Claude Desktop, remove the auth state (rm -rf ~/.mcp-auth/, or on macOS remove only the *_code_verifier.txt and _lock.json files under ~/.mcp-auth/mcp-remote-), run npx mcp-remote https://my-mcp-server.com/mcp (opens external site) standalone, complete the login, wait for "Proxy established", press Ctrl+C, verify _tokens.json exists, then relaunch Claude Desktop.
General advice: ~/.mcp-auth contains OAuth tokens, so treat it as sensitive and do not commit it to version control.
Did this work for you?What a GitHub user tried on GitHub (Worked)
Reported workaround: removed ~/.mcp-auth/, ran npx mcp-remote https://my-mcp-server.com/mcp (opens external site) manually so only one process existed, completed the login, waited for "Proxy established", pressed Ctrl+C, then restarted Claude Desktop so it reused the cached token.
Source: https://github.com/punkpeye/mcp-remote/issues/251 (opens external site)
Did this work for you?What @pluto-aaron tried on GitHub (Worked)
Commenter on macOS with mcp-remote@0.1.37: quit Claude Desktop, deleted ~/.mcp-auth/mcp-remote-/_code_verifier.txt and *_lock.json, ran npx -y mcp-remote@0.1.37 https:// standalone, waited for "Proxy established successfully", pressed Ctrl+C, verified _tokens.json existed, then relaunched Claude Desktop. They described this as the only reliable recovery.
Source: https://github.com/punkpeye/mcp-remote/issues/251#issuecomment-4430833848 (opens external site)
Did this work for you?