[FEATURE] Support more than one IDE-connected Claude Code session per editor window

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Only one Claude Code session per VS Code or Cursor window can hold an IDE connection. The /ide picker says so directly: "Note: Only one Claude Code instance can be connected to VS Code at a time."

Running two or three sessions on one project in one window is a normal way to work, and the docs encourage running sessions in parallel. Today every session past the first silently loses diagnostics, file context, and the diff viewer. Those sessions still function, they just work blind, and nothing in the UI explains why.

The failure is also hard to read. A second session prints "Failed to connect to Cursor." with no indication that the reason is a slot already held by another session, so it looks like a broken install. I spent a few hours ruling out lock files, ports, auth tokens, IPv6 resolution, and proxy settings before finding the note in the picker.

Proposed Solution

Let several sessions in one editor window each hold a working IDE connection.

From the extension bundle (anthropic.claude-code 2.1.233, extension.js), the limit is structural rather than a policy check. The WebSocket server keeps a single u transport and a single MCP Server instance, and every feature resolves the current client through a m = () => u getter. On each new connection the extension calls u.close() on 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(...)

So supporting N sessions means holding an array of transports instead of the single u, a Server instance per connection, and fanning out diagnostics notifications to all of them. For features that can only have one target, such as the diff viewer or at-mention insertion, routing to the session that most recently interacted would be a reasonable rule.

If the full change is too large, a much smaller fix would still help: make the failure legible. Replacing "Failed to connect to Cursor." with something like "Another Claude Code session is already connected to this window" would save people the debugging entirely.

Alternative Solutions

One editor window per session. This works, since each window runs its own extension host on its own port with its own lock file, so each gets an independent slot. But a second window costs several hundred MB and splits one project across windows, and it stops being reasonable past two or three sessions.

Running the extra sessions without the IDE connection. This is what I do now. They lose diagnostics, file context, and the diff viewer, which is exactly the integration I installed the extension for.

Exiting one session before starting another. Fine for two sessions, tedious as a habit.

Priority

Medium - Would be very helpful

Feature Category

MCP server integration

Use Case Example

Example scenario:

1. I have a Next.js project open in one Cursor window, with the frontend and an API route I am changing together.
2. I run claude in one integrated terminal to work on the API route, and a second claude in another terminal to work on the UI at the same time.
3. The first session connects. The second prints "Failed to connect to Cursor." and runs without diagnostics, file context, or the diff viewer.
4. To get the integration in both, I have to open a second Cursor window on the same folder, which means two copies of the same workspace, roughly double the memory, and my editor state split across windows.
5. With this feature I would keep one window, both sessions would see type errors and lint diagnostics as they work, and edits from either would open in the diff viewer.

Additional Context

The limit is documented in the CLI

The /ide picker prints, on VS Code:

Note: Only one Claude Code instance can be connected to VS Code at a time.

So this is a known limitation. I am asking for it to be lifted, not reporting it as a surprise.

Secondary symptom: the handoff does not always complete

The design is newest wins, and u.close() evicts the incumbent on purpose. On VS Code that works: the new session connects and the old one drops.

On Cursor 3.16.24 with the same extension version, the newcomer triggers the eviction and then fails itself, so it never takes over. Extension log from a freshly reloaded window, session A connects and holds, session B arrives ten seconds later and 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 failure, 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. Reproduced 5 times across two extension host lifetimes, on both Git Bash and PowerShell, so it is deterministic rather than a race.

Prior art

#14865 reported the one-connection limit in December 2025 with a clean repro. It was auto-closed as a duplicate of #13448, which is an unrelated WSL2 and OAuth bug about CLI sessions losing their API connections, labeled area:auth and area:core. #13448 was then auto-closed as not_planned. Both are locked, so there is currently no open issue tracking this.

#20826 is open and shows the same connect-then-close signature, but it is framed as Cursor detection failing rather than as the one-connection limit.

Environment

• Claude Code CLI 2.1.233 (@anthropic-ai/claude-code, npm global)
• Extension anthropic.claude-code 2.1.233 (win32-x64)
• Cursor 3.16.24 (VS Code base 1.128.0), and VS Code with the same extension
• Windows 11 Pro 26200, native, no WSL
• Integrated terminal, reproduces on both Git Bash and PowerShell

Ruled out

Version mismatch between CLI and extension, stale or invalid lock file, auth token (a manual WebSocket handshake using the lock's token connects fine, and a bogus token logs Unauthorized as expected), dead port, workspace path mismatch, IPv6 loopback resolution, proxy environment variables, and contention between editor windows. Reloading the window, deleting lock files, and starting from a fresh extension host all reproduce it identically.