VS Code MCP: createMcpProcessChannelConnectionResult error

The symptom

You add an MCP server to VS Code (or Cursor, which is built on the same Electron base) and it refuses to start. The notification or the MCP output shows something like:

Failed to acquire MessagePort for response channel
'vscode:createMcpProcessChannelConnectionResult'

The tell is that every MCP server fails the same way, and the exact same server starts fine when you run its command by hand in a terminal. That is the signature of a problem in the editor, not your configuration, which is why the usual mcp.json fixes do not move it.

Why this happens

VS Code runs each stdio MCP server in a separate utility process (Code.exe --type=utility on Windows, the equivalent helper on macOS and Linux). The editor window talks to that process over an internal Electron MessagePort channel named createMcpProcessChannelConnectionResult.

When the handshake between the window and the utility process does not finish, the MessagePort is never created and you get this error. The MCP server itself may be perfectly fine. The break is in the IPC layer, which is why your config, your transport, and your server command are all red herrings here. It is widely reported as an editor-side bug, not a problem in your mcp.json.

Fix 1: reload the window

The handshake is racy. Re-running it clears the failure most of the time. Open the Command Palette (Cmd+Shift+P / Ctrl+Shift+P) and run Developer: Reload Window. If that does not take, fully quit and reopen the app so the utility process is recreated rather than reused.

Fix 2: update VS Code or Cursor

Because this is an editor-side IPC bug rather than your configuration, getting current is worth trying first. Update VS Code or Cursor to the latest stable build, and in VS Code update the GitHub Copilot Chat extension as well, then reload. Native MCP support is still young in both editors, and users report the handshake failing less on recent builds than on the first releases that shipped it.

Fix 3: unblock the utility process (Windows)

On managed or corporate Windows machines this is the most common real cause. Antivirus, EDR agents, and Windows Core Isolation (HVCI / memory integrity) can block or sandbox Code.exe --type=utility, so the MessagePort handshake never completes.

• Allow-list the VS Code / Cursor install directory in your antivirus or EDR.
• Temporarily toggle Core Isolation > Memory integrity off (Windows Security > Device security) to confirm it is the cause, then ask IT for an exception rather than leaving it off.
• Confirm the utility process is actually allowed to spawn: in Task Manager you should see a --type=utility child appear when a server starts.

Fix 4: enable fewer servers at once

Because the handshake is timing-sensitive, starting several MCP servers at once lowers the odds that any given one connects. In .vscode/mcp.json (or your user mcp.json), disable all but the one you need, confirm it connects cleanly, then re-enable the rest one at a time. A server that only fails when others are present is hitting the cold-start race, not a config problem.

Fix 5: read the MCP output log

If reloading and updating do not help, get the underlying error instead of the generic MessagePort line. Run MCP: List Servers from the Command Palette, select the server, and choose Show Output. If a server is genuinely crashing on launch (a bad command, a missing npx -y, a path that does not resolve), the log names it there, and that is a config fix rather than an editor bug.

When it really is your config

If only one server fails and the log points at it, the problem is that server, not the MessagePort layer. The two that catch most people:

• Wrong root key or file location in mcp.json. See VS Code with Copilot: wrong root key in mcp.json.
• A malformed config that never parses. Paste it into the MCP Config Validator to catch JSON and shape errors in the browser.

The connection type that sidesteps it

This whole failure mode is specific to local stdio servers, the ones VS Code spawns as a child process. A hosted, remote MCP server connects over an HTTP URL instead, so there is no spawned utility process and no MessagePort handshake to fail.

Hjarni is a hosted MCP server: you add it with a URL (https://hjarni.com/mcp) and sign in once, with nothing to spawn locally. If you are wiring up a knowledge base your AI can read and want to avoid the local-process class of failure entirely, that is one way to do it. See Hjarni for GitHub Copilot for the exact mcp.json entry.