Skip to content

extension-DBCode MCP fails on Cursor 3.7.27 (Connection closed); works on 3.7.21 #1139

@batbrain9392

Description

@batbrain9392

Summary

Auto-registered extension-DBCode MCP (stdio bridge via dbcode mcp + DBCODE_MCP_SOCKET) fails on Cursor 3.7.27 with MCP error -32000: Connection closed. The DBCode extension MCP server itself is healthy — the failure appears to be in how Cursor 3.7.27's shared MCP process connects to the extension-provided bridge.

Same setup worked on Cursor 3.7.19 / 3.7.21 (shared-process MCP routing disabled). Regression coincides with Cursor enabling shared-process MCP routing in 3.7.27.

Environment

  • OS: macOS arm64
  • Cursor: 3.7.27 (stable)
  • DBCode: 1.34.0 (also reproduced on 1.34.1 / 1.34.2 before downgrade)
  • Transport: Extension auto-registration (registerMcpServerDefinitionProvider / extension-DBCode)
  • License: No stored license (Auth: No stored license found in DBCode log) — extension MCP worked without license on Cursor 3.7.21

Error

Cursor MCP log (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

After first failure, subsequent reconnects are instant errors (Skipping automatic createClient for non-retryable error server).

Repro

  1. Install DBCode on Cursor 3.7.27
  2. Open a workspace — DBCode registers MCP automatically (MCP LM: registered with Cursor MCP)
  3. Settings → MCP — extension-DBCode shows error / 0 tools
  4. Toggle off/on or reload window — still fails

What works (DBCode side is fine)

DBCode extension log shows the Unix socket comes up:

MCP IPC: listening at /var/folders/.../T/dbcode-mcp-<uuid>.sock

Manual test against the live socket with the bridge CLI succeeds when env is set:

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-<uuid>.sock" \
    ~/.cursor/extensions/dbcode.dbcode-1.34.0-universal/out/cli/dbcode mcp

Other MCP servers in the same Cursor session connect fine (jira, gha, confluence, gitlens extension MCP).

What doesn't help

  • MCP toggle / reload window
  • Full Cursor quit + restart
  • Downgrading DBCode (1.34.2 → 1.34.1 → 1.34.0)
  • HTTP MCP workaround requires Pro license + server start; separate from this stdio regression

Cursor-side difference (from logs)

Working session (Cursor 3.7.21, Jun 10):

[McpProcessAfterRestoredContribution] latched shared-process MCP routing disabled for this session
connection:connect_success for user-dbcode.dbcode-extension-DBCode

Broken session (Cursor 3.7.27, Jun 12):

[McpProcessAfterRestoredContribution] 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: Cursor 3.7.27's shared MCP utility process spawns dbcode mcp without a valid/stale DBCODE_MCP_SOCKET, or resolves extension-provided env before the socket is ready and never refreshes it on reconnect (same resolvedConfigHash reused across toggles).

Related

Suggested investigation

  1. Does the shared MCP process receive DBCODE_MCP_SOCKET from registerMcpServerDefinitionProvider on Cursor 3.7.27?
  2. Is there a startup race (Cursor connects before socket is listening)?
  3. Should config/env be re-fetched on MCP toggle/reload when the socket UUID changes each session?

Happy to provide full log bundles or test a fix build.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions