Extension-provided stdio MCP fails on 3.7.27 (shared-process routing) — works on 3.7.21

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Extension-provided stdio MCP servers (via registerMcpServerDefinitionProvider) fail on Cursor 3.7.27 with MCP error -32000: Connection closed after ~1.7–2s.

Reproduced with DBCode (extension-DBCode). The DBCode extension MCP server itself is healthy — the failure appears to be in Cursor’s shared MCP utility process failing to connect the stdio bridge.

Regression: Same extension MCP worked on Cursor 3.7.21 when shared-process MCP routing was disabled. On 3.7.27, routing is enabled (“after OAuth migration”) and extension MCP breaks.

User-defined ~/.cursor/mcp.json stdio servers (jira, gha, confluence) and other extension MCP (GitLens) connect fine in the same session. Only extension-provided servers with dynamic env (e.g. DBCODE_MCP_SOCKET → per-session Unix socket) appear affected.

Steps to Reproduce

  1. Install DBCode extension (1.34.0+; also reproduced on 1.34.1 / 1.34.2).
  2. Use Cursor 3.7.27 on macOS arm64.
  3. Do NOT add DBCode to ~/.cursor/mcp.json — rely on auto-registration (extension-DBCode).
  4. Open any workspace.
  5. Settings → MCP → extension-DBCode shows error, 0 tools.
  6. Optional: check log at ~/Library/Application Support/Cursor/logs//mcp-server-user-dbcode.dbcode-extension-DBCode.log

Also tried without success:

  • MCP toggle off/on
  • Full Cursor quit + restart
  • Downgrading DBCode extension version

Expected Behavior

extension-DBCode connects like it did on Cursor 3.7.21: Cursor spawns the dbcode mcp stdio bridge with correct DBCODE_MCP_SOCKET, completes MCP initialize handshake, tools appear and stay available for the session.

Operating System

MacOS

Version Information

IDE: Cursor 3.7.27 (stable), macOS arm64 (Darwin)
DBCode extension: 1.34.0 (also reproduced on 1.34.1 / 1.34.2)
Transport: extension auto-register (extension-DBCode), stdio bridge via dbcode mcp CLI
Related DBCode report: extension-DBCode MCP fails on Cursor 3.7.27 (Connection closed); works on 3.7.21 · Issue #1139 · dbcodeio/public · GitHub

For AI issues: which model did you use?

N/A — MCP connectivity bug, not an AI model issue.

For AI issues: add Request ID with privacy disabled

N/A

Additional Information

ACTUAL ERROR (from mcp-server-user-dbcode.dbcode-extension-DBCode.log):
connecting stdio for “extension-DBCode” (user-dbcode.dbcode-extension-DBCode)
Connection failed: MCP error -32000: Connection closed
durationMs: ~1958
mcp_version: shared_process
isRetryable: false

After first failure, toggling MCP reuses the same resolvedConfigHash and does not recover.

DBCODE SIDE IS HEALTHY — manual proof:

DBCode extension log:
MCP IPC: listening at /var/folders/…/T/dbcode-mcp-.sock
MCP LM: registered with Cursor MCP

Manual bridge test with correct env succeeds:
printf ‘%s\n’ ‘{“jsonrpc”:“2.0”,“id”:1,“method”:“initialize”,“params”:{“protocolVersion”:“2024-11-05”,“capabilities”:{},“clientInfo”:{“name”:“test”,“version”:“1.0”}}}’ | env DBCODE_MCP_SOCKET=“/var/folders/…/dbcode-mcp-.sock” ~/.cursor/extensions/dbcode.dbcode-1.34.0-universal/out/cli/dbcode mcp

CURSOR LOG CONTRAST:

Working (Cursor 3.7.21, Jun 10):
latched shared-process MCP routing disabled for this session
connection:connect_success for user-dbcode.dbcode-extension-DBCode

Broken (Cursor 3.7.27, Jun 12):
latched shared-process MCP routing enabled for this session after OAuth migration
connecting stdio … mcp_version: shared_process
Connection failed: MCP error -32000: Connection closed

HYPOTHESIS:
Shared MCP process spawns dbcode mcp without valid/stale DBCODE_MCP_SOCKET, or resolves extension-provided env once at startup and never refreshes when socket UUID changes or on MCP toggle.

SUGGESTED FIXES:

  1. Pass extension-provided env vars correctly from extension host → shared MCP process.
  2. Re-resolve registerMcpServerDefinitionProvider config on reconnect / when provider notifies changes.
  3. Option to disable shared-process MCP routing (3.7.21 behavior) until extension MCP is stable.

Related (different symptom, same MCP lifecycle area):

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hey, thanks for the report. It’s one of the most detailed I’ve seen. The manual proof with a manual spawn of dbcode mcp, plus the side-by-side logs for 3.7.21 vs 3.7.27, really help.

Confirmed, this is a regression on our side. What we’re seeing matches what you described. Extension-provided stdio MCP with dynamic per-session env breaks when the shared-process MCP routing gets patched to enabled after the OAuth migration, while static ~/.cursor/mcp.json stdio and SSE/HTTP extension servers keep working. I’ve filed this internally as a separate issue.

About a workaround, honestly there isn’t a clean user-side workaround right now. Toggling MCP, a full restart, and downgrading the extension don’t fix it, which matches what you already tried. There’s also no user-facing switch to force legacy MCP routing. So I don’t have a temporary fix to suggest yet.

I can’t share an ETA for a fix, but once there’s an update, I’ll reply here. If you notice the same symptom with other extension providers, not just DBCode, please share the name. It’ll help us understand the scope.