If you run more than one Claude Code session in the same Cursor window, only the first one can attach to the IDE. Every session started after it fails with “Failed to connect to Cursor.”
The extension’s IDE server accepts exactly one WebSocket client per window. When a later session connects, the extension logs “Disconnecting previous WebSocket client” and hands the slot to the newcomer, but the newcomer’s own socket then closes about 1-3 ms later, before its MCP transport can start. It never gets a usable connection, and the takeover it triggered was for nothing.
The session that was already attached keeps working, so this is not fatal. It just means one IDE-attached session per window, and a separate Cursor window for every extra one, which gets old quickly when you run a few sessions side by side.
Steps to Reproduce
Open a project in Cursor and reload the window, so the extension host starts fresh.
Open an integrated terminal and run claude. It attaches fine, and the file indicator shows up in the status line.
Open a second integrated terminal in the same window and run claude.
The second session shows “Cursor disconnected”. Running /ide and picking Cursor gives “Failed to connect to Cursor.”
The first session is unaffected and stays connected.
I hit this 5 times across two extension host lifetimes, on both Git Bash and PowerShell. It happens every time, so it is not a race.
Expected Behavior
Several Claude Code sessions in one window should each be able to hold an IDE connection. Running two or three sessions side by side in one project is a normal way to work, and every one of them past the first loses diagnostics, file context, and the diff viewer.
Failing that, a clear message would help. “Failed to connect to Cursor” gives no hint that the real reason is a slot already taken by another session, so it reads like something is broken in your setup.
Operating System
Windows 10/11
Version Information
IDE: Cursor 3.16.24
VSCode Version: 1.128.0
Commit: 1da364a6e1b9a7f7caabc58cecc5766c173673b0
OS: Windows 11 Pro 26200 (native, no WSL)
Extension: anthropic.claude-code 2.1.233 (win32-x64)
Claude Code CLI: 2.1.233 (@anthropic-aianthropic-ai/claude-code, npm global)
Additional Information
Here is the extension log (Claude VSCode.log) from a freshly reloaded window. Session A connects and holds. Session B arrives ten seconds later, takes the slot, and then dies twice in a row:
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 <-- session A, holds
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 <-- session B dies, 1 ms
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 <-- dies again, 3 ms
The CLI side of the same failure, captured with claude --debug --debug-file on the earlier port:
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 gets accepted and registered, then closes before the MCP transport can start. That is why the error is “WebSocket is not open” rather than a refused connection.
A few things worth knowing:
The already-connected session survives all of this. Its socket stays open and it keeps reporting “Connected to Cursor” with a live file indicator, so the damage is limited to the sessions that cannot get in.
This is not a broken setup on my end. I ruled out, with evidence: version mismatch (CLI and extension are both 2.1.233), a stale or invalid lock file, the auth token (a manual WebSocket handshake with the lock’s token connects fine, and a bogus token logs “Unauthorized” as expected), a dead port, a workspace path mismatch, IPv6 loopback resolution, proxy environment variables (none are set), and contention between Cursor windows (each window gets its own port and lock file).
One caveat on venue: the WebSocket server lives in Anthropic’s extension rather than in Cursor itself, so the actual fix may belong upstream. I am posting here because it reproduces in Cursor and affects Cursor users.
Does this stop you from using Cursor
No - Cursor works, but with this issue
Update: I dug into the extension bundle and found why this happens, and I have filed it upstream.
The limit is by design. The /ide picker in VS Code actually says so: “Note: Only one Claude Code instance can be connected to VS Code at a time.” That note does not appear in Cursor’s picker, which is part of why this looks like a broken install here rather than a documented limitation.
The reason is structural. In extension.js the WebSocket server keeps a single transport variable bound to a single MCP Server instance, and every feature (selection sync, at-mentions, the diff viewer) resolves the current client through one getter. On each new connection it calls close() on the previous one. There is nowhere for a second client to live, so it is not a setting anyone can flip.
The difference on Cursor is that the handoff does not complete. On VS Code a new session takes the connection and the old one drops, which is the intended newest-wins behavior. On Cursor the newcomer triggers the eviction and then loses its own socket 1-3 ms later, so it fails with “Failed to connect to Cursor” instead of taking over.
Since the fix belongs in Anthropic’s extension rather than in Cursor, I filed a feature request asking them to support more than one connected session per window:
If this bites you too, a on that issue genuinely helps. The equivalent report from December (anthropics/claude-code#14865) was auto-closed as a duplicate of an unrelated auth bug, and a well-researched meta-issue about IDE connection instability (#26285) was auto-closed as stale after 41 days. Reactions are what keeps these from disappearing.
In the meantime the only workaround is one editor window per session. Each window runs its own extension host on its own port with its own lock file, so each gets an independent slot.
Hey, thanks for the super detailed report. The logs from both sides (extension + CLI) and the fact you already ruled out version mismatch, the lock file, token, port, and so on really save a lot of time.
There’s an important detail about where this lives, which you also called out. This WebSocket “IDE server” with a single slot per window runs inside the anthropic.claude-code extension itself, not in Cursor’s code. We don’t ship or patch that server, so we can’t fix this on our side. The fix needs to come from upstream. So this isn’t something broken in your setup, you did everything right.
Workaround until a fix lands: keep one IDE-attached Claude Code session per Cursor window, and open extra sessions in separate windows. Each window gets its own port and lock file, so there’s no conflict between windows.
on that issue genuinely helps. The equivalent report from December (anthropics/claude-code#14865) was auto-closed as a duplicate of an unrelated auth bug, and a well-researched meta-issue about IDE connection instability (#26285) was auto-closed as stale after 41 days. Reactions are what keeps these from disappearing.