[BUG] Cursor IDE integration fails: option disappears after brief availability

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/12449
2. https://github.com/anthropics/claude-code/issues/20713
3. https://github.com/anthropics/claude-code/issues/18268

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

This is NOT a strict duplicate.

While it shares the underlying technical symptom (MCP connection closed/race condition) with #12449 and #20713, and the platform symptoms with #18268 (Windows 11), this report specifically confirms the issue for Cursor IDE.

Issue #18268 refers to IntelliJ. The fix for IntelliJ might not solve the issue for Cursor if the extension implementation differs. Please keep this open to ensure the fix is verified against Cursor on Windows as well.

Still relevant

Same failure here on Windows 11 with Cursor 3.16.24, CLI and extension both 2.1.233. I captured the extension side, which I have not seen posted in this thread yet, and I think it explains the connect-then-close-after-0s signature.

The underlying cause looks like the one-connection-per-window design rather than a detection problem. In extension.js the WebSocket server keeps a single transport variable bound to a single MCP Server instance, and on every new connection it closes the previous one:

if (u) {
  n.info("Disconnecting previous WebSocket client")
  if (d) { p.unregisterClient(d); d = null }
  try { u.close() } catch (O) { n.error("Error closing previous transport:", O) }
}
let C = new xZ(w)
u = C
a.connect(C).then(...)

The /ide picker states the limit on VS Code ("Note: Only one Claude Code instance can be connected to VS Code at a time.") but that note does not render in Cursor, so on Cursor it just looks like a broken install.

Extension log from a freshly reloaded window. Session A connects and holds. Session B arrives ten seconds later, takes the slot, then dies twice:

15:26:54.980 [info] MCP Server running on port 18419 (localhost only)

15:27:12.615 [info] New WS connection from: /
15:27:12.615 [info] MCP server connected to transport
15:27:12.615 [info] Registered diagnostic client: client_0

15:27:22.177 [info] New WS connection from: /
15:27:22.177 [info] Disconnecting previous WebSocket client
15:27:22.177 [info] [DiagnosticStreamManager] Unregistered client client_0. Total clients: 0
15:27:22.177 [info] Registered diagnostic client: client_1
15:27:22.178 [info] WS client disconnected

15:27:22.180 [info] New WS connection from: /
15:27:22.180 [info] Disconnecting previous WebSocket client
15:27:22.180 [info] [DiagnosticStreamManager] Unregistered client client_1. Total clients: 0
15:27:22.180 [info] Registered diagnostic client: client_2
15:27:22.183 [info] WS client disconnected

CLI side of the same moment, from claude --debug --debug-file:

2026-08-16T12:20:48.418Z [DEBUG] MCP server "ide": Starting connection with timeout of 30000ms
2026-08-16T12:20:48.467Z [DEBUG] MCP server "ide": Connection failed after 50ms: WebSocket is not open. Cannot start transport.
2026-08-16T12:20:48.467Z [ERROR] MCP server "ide" Connection failed: WebSocket is not open. Cannot start transport.

The socket is accepted and registered, then closes before transport.start() runs, which is why the error is WebSocket is not open rather than a refused connection.

The difference between the two editors is that on VS Code the handoff completes (new session connects, old one drops, which is the intended newest-wins behavior) while on Cursor the newcomer triggers the eviction and then loses its own socket, so it never takes over. Reproduced 5 times across two extension host lifetimes, on both Git Bash and PowerShell, so it is deterministic rather than a race.

Ruled out on my side: version mismatch, stale or invalid lock file, auth token (a manual WebSocket handshake with the lock's token connects fine, a bogus token logs Unauthorized), dead port, workspace path mismatch, IPv6 loopback resolution, proxy env vars, and contention between windows.

I filed a related feature request to lift the one-connection limit, with the same evidence: #87130