Cursor MCP Client fails to reconnect after network drop or sleep/wake cycle

[Nikolay_Miladinov]

Where does the bug appear (feature/product)?

Somewhere else…

Describe the Bug

MCP client fails to reconnect after network interruption (laptop sleep/wake) and requires manual window reload to restore connection
When the laptop enters sleep mode and reconnects to the network, the Cursor MCP client encounters a DNS resolution failure (getaddrinfo ENOTFOUND mcp-staging.chestnut.so) and exhausts its retry attempts (max 2 retries). The client then enters a permanently broken state where it reports “Server not yet created” and cannot recover without manual intervention (window reload).
The issue manifests as:
MCP tools become unavailable
No error message to the user indicating the connection is broken
Silent failure with no recovery attempt

Steps to Reproduce

Open Cursor with an active MCP connection (verify tools are available)
Successfully call an MCP tool to confirm connection works
Close laptop lid (enter sleep mode) for 30+ seconds
Open laptop lid and wait for network to reconnect
Attempt to use an MCP tool
Observe: Tool fails with “No server info found” or connection errors
Key detail: The timing matters - if the network takes a few seconds to stabilize after wake, the retry window (2 attempts) expires before DNS can resolve.

Expected Behavior

MCP client should automatically reconnect with:
Exponential backoff retry strategy (not just 2 fixed retries)
Wait for network availability before retrying
Show user a non-blocking notification: “Reconnecting to MCP server…”
Auto-recover without requiring window reload

Operating System

Windows 10/11

Version Information

Version: 2.4.31 (user setup)
VSCode Version: 1.105.1
Commit: 3578107fdf149b00059ddad37048220e41681000
Date: 2026-02-08T07:42:24.999Z
Build Type: Stable
Release Track: Default
Electron: 39.2.7
Chromium: 142.0.7444.235
Node.js: 22.21.1
V8: 14.2.231.21-electron.0
OS: Windows_NT x64 10.0.26100

Does this stop you from using Cursor

No - Cursor works, but with this issue

[deanrie]

Hey, thanks for the detailed report.

We recently shipped a fix for reconnecting to the MCP server after network issues (like a VPN drop), which sounds really similar to what you’re seeing. The update should be rolling out soon.

Quick question: mcp-staging.chestnut.so looks like a staging endpoint. Is that a custom or remote MCP server you’re connecting to, or is it the default Cursor MCP connection? I want to make sure we’re looking at the right thing.

Let me know how it goes after the update.

[Nikolay_Miladinov]

Yep, it’s a staging endpoint, but should be the same with production one. It’s a remote MCP server deployed on Railway.
Thanks for your response, will see if it’s fixed when the update comes out.