Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
OAuth consent on honeycomb.io succeeds, but the browser then fails to connect when redirected to http://127.0.0.1:8787/callback?… (connection refused / site can’t be reached). Auth never completes in Cursor.
Root cause (on my machine): Cursor’s MCP OAuth callback listener binds to IPv6 loopback only, while the OAuth provider redirects to IPv4 127.0.0.1.
Diagnostics during an active auth attempt
$ lsof -iTCP:8787 -sTCP:LISTEN -P -n
COMMAND PID USER FD TYPE NODE NAME
Cursor ... mp 43u IPv6 ... TCP [::1]:8787 (LISTEN)
$ curl -sS -o /dev/null -w "localhost: %{http_code}\n" http://localhost:8787/callback
localhost: 200
$ curl -sS -o /dev/null -w "127.0.0.1: %{http_code}\n" http://127.0.0.1:8787/callback
curl: (7) Failed to connect to 127.0.0.1 port 8787: Couldn't connect to server
So localhost works (resolves to ::1 on macOS), but 127.0.0.1 does not — even though both are semantically “loopback”. OAuth requires exact redirect URI string matching, and many providers (including Honeycomb via dynamic client registration) redirect to 127.0.0.1 rather than localhost.
Workaround that works: When the browser lands on the failed 127.0.0.1:8787 URL, manually change the host to localhost (keep port/path/query intact). Cursor then receives the callback and auth completes.
Suggested fix: The MCP OAuth callback server on port 8787 should listen on both 127.0.0.1 and ::1 (dual-stack loopback), or consistently use one host in both the registered redirect URI and the listener bind address. For reference, OpenAI Codex’s MCP OAuth implementation explicitly binds local callbacks to 127.0.0.1.
Steps to Reproduce
On macOS, add a remote OAuth MCP server that redirects to 127.0.0.1 (e.g. Honeycomb):
{
"mcpServers": {
"honeycomb": {
"url": "https://mcp.honeycomb.io/mcp"
}
}
}
In Cursor Settings → Tools & MCP, click Authenticate / Connect for that server.
Complete login and consent in the browser.
Observe the redirect to http://127.0.0.1:8787/callback?… fails with connection refused.
Optionally confirm with lsof -iTCP:8787 -sTCP:LISTEN -P -n (listener on [::1]:8787 only) and the two curl checks above.
Change the URL host to localhost and reload: callback succeeds and Cursor finishes auth.
Operating System
MacOS
Version Information
Version: 3.10.20
VS Code Extension API: 1.125.0
Commit: 23b9fb205fe595ea2be29da7214e19762d037fc0
Date: 2026-07-07T07:03:33.071Z
Layout: Agent Window
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Darwin arm64 25.5.0
Does this stop you from using Cursor
No - Cursor works, but with this issue