Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
Observed sequence (timestamps from MCP output log)
1. Initial connection refused (benign, self-resolves):
[warning] Error connecting to streamableHttp server, falling back to SSE: fetch failed
[error] Error connecting to SSE server after fallback: SSE error: TypeError: fetch failed: connect ECONNREFUSED ::1:64342, connect ECONNREFUSED 127.0.0.1:64342
[warning] Connection failed: SSE error: TypeError: fetch failed: connect ECONNREFUSED ::1:64342, connect ECONNREFUSED 127.0.0.1:64342
This happens because Rider’s embedded MCP HTTP server isn’t ready yet at the moment Cursor first tries to connect. It resolves on its own ~1 minute later.
2. Malformed root URI kills a successful connection:
[info] Successfully connected to streamableHttp server
[warning] MCP HTTP exchange completed
[error] Client error: Streamable HTTP error: Error POSTing to endpoint: {"jsonrpc":"2.0","error":{"code":-32700,"message":"Invalid JSON-RPC payload: Root URI must start with 'file://', got: c:\\Users\\manu\\RiderProjects\\wpf"},"id":null}
[warning] [V2 FSM] connection:transport_error: conn=connected,auth=valid -> conn=failed,auth=valid
Right after a successful handshake, Cursor sends the workspace root as a raw Windows path (c:\Users\manu\RiderProjects\wpf) instead of a proper file:// URI (e.g. file:///c:/Users/manu/RiderProjects/wpf). The JetBrains MCP server validates the URI format strictly and rejects it with a JSON-RPC -32700 error, which kills the transport that had just connected successfully.
3. Reconnect attempts fail with 409 Conflict, exhausting retries:
[error] Client error: Streamable HTTP error: Failed to open SSE stream: Conflict
[warning] [V2 FSM] connection:transport_error: conn=connected,auth=valid -> conn=failed,auth=valid
[error] Client error: Failed to reconnect SSE stream: Streamable HTTP error: Failed to open SSE stream: Conflict
[error] Client error: Maximum reconnection attempts (2) exceeded.
Because the previous session wasn’t cleanly closed server-side after the transport error in step 2, the next SSE reconnect attempt collides with the stale session and the server returns 409 Conflict. After 2 failed attempts, Cursor gives up and the connection stays in a failed state indefinitely.
Steps to Reproduce
Workaround: Manually toggling the JetBrains MCP server off/on in Tools & MCP immediately restores the connection (forces a clean client-side session teardown/recreate). Simply waiting does not reliably fix it — sometimes it takes tens of minutes to self-recover, sometimes it doesn’t recover until the manual toggle.
Expected Behavior
- Cursor should encode the workspace root as a valid
file://URI when sending it to MCP servers on Windows (this looks like the same class of Windows-path-encoding bug reported elsewhere for MCP, e.g. backslash handling in stdio server paths). - After a transport error, Cursor should perform a full client-side teardown (equivalent to the manual toggle) before attempting to reconnect, instead of retrying a new SSE stream against a session the server still considers active.
Operating System
Windows 10/11
Version Information
Version: 3.12.10 (user setup)
VS Code Extension API: 1.128.0
Commit: 24a12dbd9cabf48956ce5bb3dbd234e41385b3d0
Date: 2026-07-16T03:15:48.538Z
Layout: IDE
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: Windows_NT x64 10.0.26200
For AI issues: which model did you use?
Sonnet 5
Does this stop you from using Cursor
No - Cursor works, but with this issue