Duplicate MCP server instances spawn after reconnect, causing Claude Code Task dispatches to be silently rejected

[iverlov]

Summary

When claude-video-vision MCP server reconnects mid-session, it appears to leave the previous node process running AND spawn a fresh instance. Both then hold open stdio pipes to Claude Code. The interference causes Claude Code's Task (Agent) tool dispatches to be silently rejected with "The user doesn't want to proceed with this tool use" even though the user has done nothing and is in bypass permissions mode.

Symptom

• Agent tool calls return "rejected" instantly without any approval dialog being shown
• 5+ rejections within under a minute, faster than any user input could produce
• Session log records each as toolUseResult: "User rejected tool use" plus [Request interrupted by user for tool use] — Claude Code believes user input arrived when none actually did
• Smaller probe tool calls usually still succeed; long-running dispatches reject reliably

Evidence of duplicate spawn

While debugging this with Get-CimInstance Win32_Process, observed two complete instance pairs of claude-video-vision running at the same time on Windows:

• Two npx-cli.js -y claude-video-vision@latest wrapper processes
• Two claude-video-vision/dist/index.js server processes
• All four started within seconds of each other

So one full instance ran twice in parallel, each with its own stdio handle to Claude Code.

Environment

• Windows 11
• Claude Code 2.1.143 hosted inside Cursor IDE
• claude-video-vision@1.3.2
• Plugin enabled via ~/.claude/settings.json enabledPlugins
• Saw multiple "MCP server disconnected" and "MCP server reconnected" system reminders earlier in the session

What fixed it

1. Manually killed all four processes
2. Removed the entry from enabledPlugins in ~/.claude/settings.json

Immediately after: same dispatches that had been rejecting completed cleanly. Three sustained dispatches in a row, one running close to 8 minutes, without a single rejection.

What we ruled out

• Cursor's terminal GPU acceleration setting
• Custom keybindings sending ESC
• Prompt size, model choice, prompt content
• User pressing Esc (verified)

Suspected root cause

The MCP server's stdio reconnect logic appears to not terminate the previous process before spawning a new one. Both then write to Claude Code's stdin, which the harness reads as new user input arriving during a pending tool call, and cancels the in-flight tool.

Suggested fix direction

On reconnect, ensure the prior server instance is terminated and its stdio handles are closed before spawning a new instance. Alternatively, a PID lockfile in ~/.claude-video-vision/ to detect "already running" and refuse to start a second instance.

Happy to provide more diagnostics if useful. Otherwise excellent plugin, thank you for building it. :-)

[jordanrendric]

Thanks for the detailed report — the Get-CimInstance evidence showing 4 processes and the toolUseResult: "User rejected tool use" appearing without user input is strong diagnose material.

Before proposing a fix I need to scope this. A few questions:

1. Did other MCP servers also duplicate in the same session? If you have other plugins enabled (Linear, GitHub, etc.), does Get-CimInstance show duplicates for them too, or only claude-video-vision? That's the question that decides whether this is our bug or a harness bug.
2. What preceded the reconnect? Laptop sleep? Cursor reload? Network blip? A specific trigger would help reproduce.
3. Logs with MCP_DEBUG=1 when reproducing, if possible. Would surface the handshakes and which instance responded last.

With those three answers we can head to the right fix.