Plugin MCPs time out in Remote SSH: mcp.createClient / EverythingProvider

[ivnmood (Ivan)]

Where does the bug appear?

Cursor IDE → managed Plugin MCPs in an official Anysphere Remote SSH environment.

Describe the bug

All managed Plugin MCPs fail only in the SSH environment. Atlassian, Context7, and Figma show Needs attention, while the same plugins work in Local and a user-configured MCP remains connected in the same SSH window.

Reloading any affected plugin waits 30 seconds and fails inside the internal MCP client path:

Timeout waiting for EverythingProvider with command mcp.createClient
MCP IPC timeout: mcp.runCommand.mcp.createClient exceeded 30000ms

Because several unrelated providers fail at the same internal command while Local works, this looks like an SSH-scoped MCP client or extension-host IPC issue rather than three independent OAuth failures.

Steps to reproduce

1. Enable the managed Atlassian, Context7, and Figma plugins.
2. Connect to an Ubuntu host using the official Anysphere Remote SSH extension.
3. Open Cursor Settings → Tools & MCPs.
4. Observe that Local is connected, but each Plugin MCP reports Needs attention in SSH.
5. Open one plugin and click Reload for the SSH environment.
6. Wait about 30 seconds.
7. Open Show Output and observe the EverythingProvider / mcp.createClient timeout.

The result reproduces after Developer: Reload Window and after fully quitting and reopening Cursor. It affects multiple Plugin MCPs; a user MCP can remain connected in the same SSH window.

Expected behavior

The Plugin MCP client should initialize in SSH and either connect or return a specific authentication or network error. mcp.createClient should not hang for 30 seconds. If SSH needs separate authorization, Cursor should show a sign-in prompt instead of an internal IPC timeout.

Environment

• Cursor IDE 3.15.6
• Commit a1f686545fd0ce8917bbd2449f733551a9bce420
• Anysphere Remote SSH 1.1.14
• Client: macOS 26.5.1 (25F80), Apple Silicon
• Remote: Ubuntu 24.04, Linux 6.8.0-137-generic, x86_64
• Remote resources were healthy with sufficient RAM and disk; Node and rg are available
• Not model-specific and not associated with an Agent Request ID

Representative sanitized logs

[MCPService] createClient: identifier=plugin-atlassian-atlassian, serverName=atlassian
[MCPService] Error creating client: Timeout waiting for EverythingProvider with command mcp.createClient
MCP IPC timeout: mcp.runCommand.mcp.createClient exceeded 30000ms

The remote session also logged:

EverythingProvider command mcp.createClient already registered by provider provider-id
EEXIST: file already exists, open .../workspaceStorage/.../vscode.lock

There were also frequent extension-host starts and exits. At inspection time, multiple remote extensionHost processes were active and several were using high CPU. This suggests duplicate or stale remote extension-host state, or a provider-registration race, but that is only a hypothesis.

Affected identifiers include:

• plugin-atlassian-atlassian
• plugin-context7-plugin-context7
• plugin-figma-figma

The UI can alternate between connected, needsAuth, and timeout states, but the stable failure is the 30-second createClient timeout in SSH. Local remains connected.

Related reports

• Timeout waiting for EverythingProvider Error
• MCP fails to start — utility process never reaches `ipcReady` (Windows)
• MCP failed in ssh remote server

Impact and logs

Cursor itself remains usable, but Plugin MCPs are unavailable in Remote SSH. I can provide a full Developer: Export Logs archive privately; it contains workspace and repository paths, so I am not attaching it publicly.

Screenshots

[deanrie]

Hey, thanks for the detailed report. The logs, repro steps, and versions help a lot.

A couple things to narrow this down. In your logs you’ve got an EEXIST on vscode.lock in workspaceStorage, a duplicate registration EverythingProvider command mcp.createClient already registered, and several active remote extensionHost processes with high CPU. This looks like stale or duplicated state on the remote server, not three independent plugin failures. So it’s worth doing a full remote host cleanup instead of just Reload Window:

• Close all Cursor windows connected to this Ubuntu host.
• On the host, kill any stuck Cursor server processes and remove stale locks, for example:
  • pkill -f '.cursor-server' (or find the PID via ps aux | grep cursor-server)
  • Delete any remaining */workspaceStorage/*/vscode.lock if it’s still there after the processes are killed
• Reconnect over SSH and open Tools & MCPs again.

If after a clean restart the plugins still hang for 30 seconds on mcp.createClient, then it’s probably not something in your setup. In that case, please send the full Developer: Export Logs archive you mentioned you can share privately. You can DM it here. Also check this: if you temporarily disable and then re-enable one plugin from the panel, does it connect, or does it still time out?

This is an area we’re tracking, but we don’t have the exact root cause yet specifically for SSH-scoped plugin MCP. With fresh logs after the cleanup, it’ll be clearer where to dig. Let me know how it goes.