[BUG] OAuth callback listener uses a hardcoded port A53280 with no fallback

Status Open
Reported on v2.1.224
Maintainer reply None cached
Activity 0 comments · opened Aug 7, 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?

Claude Desktop's remote MCP connector opens a local listener on a hardcoded port TCP 53280 to receive the OAuth authorization-code callback. If that port cannot be bound, setup fails immediately: no retry, no fallback to an OS-assigned port, no actionable error. The browser consent window never opens.

Claude Code CLI does not have this problem on the same machine, against the same endpoint, in the same OAuth mode. The CLI requests an OS-assigned port (port 0), so it practically never collides — observed redirect URIs on a working install: http://localhost:44350/callback, http://localhost:3118/callback, different every time. Desktop insists on 53280 every time. The endpoint, the OAuth mode and the Atlassian side are identical between the two clients; the callback port is the only variable.

Why 53280 is unavailable on affected machines: with Hyper-V / WSL2 / Virtual Machine Platform enabled, the winnat and hns services claim blocks of the dynamic TCP port range at every boot (~1,400–1,600 ports across ~14 blocks on the machines we measured). An explicit bind to a port inside a NAT-owned block is refused by the OS with EACCES. On the affected boot the block 53214–53313 covered 53280.

<img width="767" height="696" alt="Image" src="https://github.com/user-attachments/assets/e2542c6b-06d6-4553-bc9f-ad08801bf23f" />

What Should Happen?

Bind an OS-assigned port (port 0) for the callback listener and derive the redirect URI from the actual assigned port — exactly what Claude Code CLI already does. The fix is already implemented and proven in the same product family.

Error Messages/Logs

Connector: Atlassian (Rovo MCP). Transport Streamable HTTP, URL https://mcp.atlassian.com/v1/mcp, OAuth left at default.

listen EACCES: permission denied {IP_ADDRESS}
FAILED REQUEST  HTTP https://mcp.atlassian.com/v1/mcp/authv2 -> initialize

Supporting OS-level evidence from the affected machine:

> netsh interface ipv4 show excludedportrange protocol=tcp
   (relevant entry, affected boot)
   Start Port    End Port
   ----------    --------
        53214       53313        <-- contains 53280
        53114       53213        <-- free
        53314       53413        <-- free

> netstat -ano | findstr 53280
   (no output — nothing is listening)

Explicit bind to 53280 → errno 13 (EACCES). OS-assigned bind on the same machine → succeeds, 10 attempts out of 10.

The EADDRINUSE variant (port occupied by a normal process rather than reserved by NAT) fails at the same point with the same lack of fallback.

Steps to Reproduce

  1. Occupy TCP 53280 with any listener:

python -c "import socket;s=socket.socket();s.bind(('127.0.0.1',53280));s.listen();input()"

  1. Claude Desktop → Settings → Connectors & extensions → add a remote MCP connector. Transport Streamable HTTP, URL https://mcp.atlassian.com/v1/mcp, leave OAuth at default.
  2. Click Sign in & test.
  3. → Setup fails on the bind. No browser window opens; no alternative port is attempted.
  4. Control: with the port still occupied, connect the same MCP server from {NAME} Code CLI on the same machine → succeeds.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

Claude 1.26832.0 (056ee2) 2026-08-06T05:43:05.000Z

Claude Code Version

2.1.224

Platform

AWS Bedrock

Operating System

Windows

Terminal/Shell

Other

Additional Information

_No response_

View original on GitHub ↗