Quick update on where this stands. We shipped a fix for the startup timeout that was sending MCP servers to Error on launch (the ipcReady / MessagePort failures in your logs). It gives servers more time to come up on cold start, and it’s in the current stable release. So the first step for anyone still seeing this:
Update to the latest version (Help > About to check), then fully quit Cursor (not just Reload Window) and reopen. A full relaunch clears the wedged startup state far more reliably than a reload, which is why reloads felt so hit-or-miss.
If servers still error right after launch, temporarily turn off a few MCP servers in Settings > MCP and reopen. This fails much more often when many servers start at once, so bringing them up with fewer enabled usually gets the rest connected.
On a corporate-managed Windows machine, endpoint security (Core Isolation / EDR / antivirus) can stop Cursor’s helper processes from starting. If updating doesn’t help on a managed device, ask your IT team to allowlist Cursor’s install folder and its helper processes.
A smaller set of reports are still failing on the latest version, where the helper process never finishes starting no matter how many reloads (@brandon.f - your log looks like this case). That’s a separate startup issue we’re actively tracking, and reloads or fewer servers won’t fix it.
If you’re on the latest version and it still fails, this is what helps us dig in - reply with:
Your exact version (Help > About)
Whether your log still shows timed out waiting for ipcReady, and the coldStartTimeoutMs value next to it (30000 means you’re on the fixed build)
MCP logs: open the Output panel (Ctrl+Shift+U), then pick MCP Logs and the specific MCP: from the dropdown
Whether MCP ever recovers on its own after a minute or two
I am already on the latest version, but still encountering the same issue.
Besides, I tried few ways below, all doesn’t seem to work. I even remove all MCP but it still showing the same error which is weird especially there is no MCP setup.
Thanks for confirming all of that. The fact that it still fails with every MCP server removed and after a clean reinstall is the useful clue here: this isn’t your MCP setup at all. It’s the separate startup issue I mentioned, where one of Cursor’s helper processes never finishes starting, so nothing can reach it (that’s the ipcReady timeout in your log).
In the cases we’ve traced that look exactly like yours (latest build, 30000ms timeout, the helper starting but never completing its handshake, no change after reinstalling), the cause has almost always been something on the machine intercepting Cursor’s helper processes as they launch. Most often that’s endpoint security: antivirus, EDR, or Windows Core Isolation / Memory Integrity. That also explains why removing servers and reinstalling don’t change anything.
A few things to try, in order:
If this is a work or managed machine, ask your IT team to allowlist Cursor’s install folder and its helper processes in your antivirus/EDR. On a personal machine, add a Windows Security exclusion for the Cursor install folder.
Quick test to confirm the cause: open Windows Security > Device Security > Core Isolation and temporarily turn off Memory Integrity, then fully quit Cursor (not just Reload Window) and reopen. If things come back, endpoint security is the culprit and the allowlist in step 1 is the durable fix. Memory Integrity is a security feature, so turn it back on once you’ve tested.
To get unblocked in the meantime, Developer: Reload Window (or a full quit and relaunch) usually restores things for the session.
To dig into your specific setup, could you share:
Is this a work/corporate-managed PC? If so, what antivirus or endpoint security is running on it?
A logs export: Ctrl+Shift+P > Developer: Open Logs Folder, then zip the whole folder and attach it here.
After launch, does it ever recover on its own if you wait a minute or two?