MCP Docker containers fail with name conflicts after Oct 29 update

Bug Reports
1

Where does the bug appear (feature/product)?

Background Agent (GitHub, Slack, Web, Linear)

Describe the Bug

The MCP extension is trying to create multiple instances of each container simultaneously, which causes name conflicts.

Steps to Reproduce

  1. Have a preconfigured MCP connection on the old instance of Cursor
  2. Install the new instance and notice that none of the MCP connections are loading.

Expected Behavior

The MCP connection should work irrespective of which version of the cursor we have installed.

Operating System

MacOS

Current Cursor Version (Menu → About Cursor → Copy)

Version: 2.0.34
VSCode Version: 1.99.3
Commit: 45fd70f3fe72037444ba35c9e51ce86a1977ac10
Date: 2025-10-29T06:51:29.202Z
Electron: 34.5.8
Chromium: 132.0.6834.210
Node.js: 20.19.1
V8: 13.2.152.41-electron.0
OS: Darwin arm64 24.6.0

Additional Information

Cursor MCP Bug Report - October 29, 2025 Release

Summary

MCP Docker containers fail to start due to name conflicts when Cursor tries to create multiple instances simultaneously.

Environment

  • Cursor Version: October 29, 2025 release
  • OS: macOS (darwin 24.6.0)
  • MCP Extension: anysphere.cursor-mcp
  • Container Runtime: Docker Desktop

Issue Description

After updating to today’s Cursor release (Oct 29, 2025), MCP servers using Docker containers fail to connect with the following error:

docker: Error response from daemon: Conflict. The container name "/corp-jira" is already in use by container "xxx". You have to remove (or rename) that container to be able to reuse that name.

Root Cause

The MCP extension appears to be attempting to start multiple Docker containers with the same name simultaneously, causing name conflicts. This occurs even with --rm flag which should auto-remove containers.

Logs Evidence

From ~/Library/Application Support/Cursor/logs/[timestamp]/window1/exthost/anysphere.cursor-mcp/:

2025-10-29 14:25:54.331 [info] Starting new stdio process with command: docker run -i --rm --name corp-jira --env-file ...
2025-10-29 14:25:54.411 [error] docker: Error response from daemon: Conflict. The container name "/corp-jira" is already in use
2025-10-29 14:25:54.470 [info] Starting new stdio process with command: docker run -i --rm --name corp-jira --env-file ...
2025-10-29 14:25:54.521 [error] docker: Error response from daemon: Conflict. The container name "/corp-jira" is already in use

Notice the extension tries to start the same container twice within milliseconds.

Affected MCP Servers

All Docker-based MCP servers are affected:

  • Corp Jira
  • Slack
  • Figma
  • Adobe Wiki Confluence
  • Corp GitHub

HTTP-based MCP servers (like stock-agent-mcp) have separate issues (returning 405 Method Not Allowed).

Configuration Tested

Standard MCP configuration in ~/.cursor/mcp.json:

{
  "mcpServers": {
    "Corp Jira": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "--name",
        "corp-jira",
        "--env-file",
        "/Users/<username>/<companyname>-registry/mcp-servers/src/corp-jira/.env",
        "corp-jira"
      ]
    }
  }
}

Workaround

Use unique container names with timestamps and process IDs:

{
  "mcpServers": {
    "Corp Jira": {
      "command": "bash",
      "args": [
        "-c",
        "docker run -i --rm --name corp-jira-$(date +%s)-$$ --env-file /Users/<username>/<companyname>-registry/mcp-servers/src/corp-jira/.env corp-jira"
      ]
    }
  }
}

This ensures each container gets a unique name even if started simultaneously.

Expected Behavior

  1. MCP extension should start each Docker container only once
  2. If a container with the name exists, it should either:
    • Reuse the existing container
    • Wait for the existing container to be removed
    • Use unique names automatically

Previous Behavior

Before the October 29, 2025 update, the same configuration worked without issues.

Additional Context

  • Docker containers ARE working and responding correctly (verified via docker logs)
  • The issue is purely with the MCP extension’s container lifecycle management
  • Only one MCP server (Adobe Wiki Confluence) worked initially, likely because it won the race condition

Reproduction Steps

  1. Configure multiple Docker-based MCP servers in ~/.cursor/mcp.json
  2. Start/restart Cursor
  3. Observe container name conflicts in logs
  4. MCP resources show as “not found” despite containers running

Request

Please fix the MCP extension to:

  1. Prevent starting duplicate containers simultaneously
  2. Properly manage container lifecycle with --rm flag
  3. Handle race conditions when multiple MCP servers start at once

Reporter: Vivek Jain
Date: October 29, 2025
Workaround Status: Applied and working

Does this stop you from using Cursor

No - Cursor works, but with this issue

2

Hey, thanks for the report. This is a confirmed regression in Cursor 2.0.34 affecting MCP client initialization.

We found a related report with the same root cause: MCP Server Race Condition Causes Infinite Process Spawning on Windows (Cursor 2.0.34)

The MCP extension spawns duplicate client instances before the first connection completes, causing:

  • Docker container name conflicts (your case)
  • Infinite Node.js process spawning on Windows (other report)

Your workaround using unique container names is solid and should help until a fix is released. I’m escalating both reports to the engineering team since this is a critical infrastructure issue.

I’ll update the thread as soon as there’s progress. Thanks for the logs and clear reproduction steps!

1 Like