MCP HTTP Client Regression

[mattv8]

VS Code 1.122’s built-in HTTP MCP transport is throwing TypeError: fetch failed before it opens a socket. Evidence:

• curl, terminal node, browser fetch, and VS Code’s bundled Electron/Node runtime can all POST to https://mcp.example.com/mcp.
• VS Code’s built-in HTTP MCP client fails against localhost, 127.0.0.1, and even a tiny probe server on 127.0.0.1:8999.
• That probe server logged no connection from VS Code, so the request never reached https://mcp.example.com/mcp or the network layer.
• Switching to a stdio bridge via mcp-remote works immediately. VS Code discovered 3 tools, and my MCP server logged the MCP initialize and tools/list traffic.

Works:

{
  "servers": {
    "my-mcp-server": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://mcp.example.com/mcp"
      ]
    }
  }
}

Does not work as of 1.122.0:

{
  "servers": {
    "my-mcp-server": {
      "url": "https://mcp.example.com/mcp",
      "type": "http"
    }
  }
}

Does this issue occur when all extensions are disabled?: Yes

• VS Code Version: 1.122
• OS Version: MacOS Tahoe 26.5

Steps to Reproduce:

1. Add HTTP MCP server to mcp.json, see examples above.
2. Attempt to start it.
3. It will not start. MCP logs show:

2026-05-28 13:34:03.696 [info] Connection state: Starting
2026-05-28 13:34:03.709 [info] Starting server from LocalProcess extension host
2026-05-28 13:34:03.711 [info] Connection state: Running
2026-05-28 13:34:03.724 [info] Connection state: Error Error sending message to https://mcp.example.com/mcp: TypeError: fetch failed

[mattv8]

Same issue in v1.122.1

[mattv8]

Adding a discovery: the MCP client seems to work on Windows/WSL. MacOS is definitely still broken though.

[pboudoin]

Got this issue too. I'm on macOS btw

[mattv8]

@pboudoin did you see the workaround in mcp.json at least?

{
  "servers": {
    "my-mcp-server": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://mcp.example.com/mcp"
      ]
    }
  }
}

[ThisIsDavidHan]

Confirming this on macOS (VS Code Insiders 1.124.0-insider) — same signature: Connection state: Running immediately followed by Connection state: Error ... TypeError: fetch failed, with no socket ever opened. Affects every HTTP MCP server I tried (ClickUp, Sentry, Microsoft Learn Docs).

The mcp-remote stdio-bridge workaround from above works, but I hit two non-obvious gotchas getting it running on macOS that may help others landing here:

1. npm/npx cache permissions — if you've ever run npm under sudo, the bridge fails first with EACCES ... mkdir /Users/<you>/.npm/_cacache/.... Fix: sudo chown -R $(id -u):$(id -g) ~/.npm.

2. Node version resolution — mcp-remote depends on undici@7, which needs Node ≥ 20.18.1. On an older default Node (mine was 18.16.0 via nvs) it crashes with:

   ReferenceError: File is not defined
       at .../undici/lib/web/webidl/index.js:537
   

   The tricky part: pointing the MCP command at a Node 20+ binary isn't enough, because npx then spawns the mcp-remote bin via #!/usr/bin/env node, which re-resolves to the old default Node. Setting env.PATH in mcp.json didn't override it either.

   What finally worked was bypassing npx/shebang entirely and running the proxy entry point directly with an absolute Node 20+ binary:

   "my-server-bridge": {
     "command": "/absolute/path/to/node20+/bin/node",
     "args": [
       "/absolute/path/to/mcp-remote/dist/proxy.js",
       "https://mcp.example.com/mcp"
     ]
   }

   (Install once with npm i -g mcp-remote under your Node 20+, then point at that install's dist/proxy.js.)

Native HTTP transport would obviously be preferable — posting the workaround details in case they save someone the same debugging session.

Environment

• VS Code: Insiders 1.124.0-insider (commit 8d1fba12d9d9821515cf54d1a506305502971a1c)
• OS: macOS 26.5 (build 25F71), Apple Silicon

[RareBird15]

I’m seeing what appears to be the same issue in VS Code Insiders with multiple remote HTTP MCP servers.

Environment:

Version: 1.124.0-insider (user setup)
Commit: 16390e9faa4bd687a9fceb13901534de1748bf76
Date: 2026-06-04T06:56:22+10:00
Electron: 42.2.0
ElectronBuildId: 14159160
Chromium: 148.0.7778.97
Node.js: 24.15.0
V8: 14.8.178.14-electron.0
OS: Windows_NT x64 10.0.26300

Remote HTTP MCP servers tested:

"supermemory": {
  "url": "https://mcp.supermemory.ai/mcp",
  "type": "http",
  "headers": {
    "Authorization": "Bearer ${input:supermemory_api_key}"
  }
},
"Exa": {
  "url": "https://mcp.exa.ai/mcp",
  "type": "http"
},
"composio": {
  "url": "https://connect.composio.dev/mcp",
  "type": "http"
},
"Cloudflare": {
  "url": "https://mcp.cloudflare.com/mcp",
  "type": "http"
}

All of those fail in Insiders with the same pattern:

Connection state: Error Error sending message to <remote MCP URL>: TypeError: fetch failed

Example logs:

Starting server Exa
Connection state: Running
Connection state: Error Error sending message to https://mcp.exa.ai/mcp: TypeError: fetch failed

Starting server composio
Connection state: Running
Connection state: Error Error sending message to https://connect.composio.dev/mcp: TypeError: fetch failed

Starting server Cloudflare
Connection state: Running
Connection state: Error Error sending message to https://mcp.cloudflare.com/mcp: TypeError: fetch failed

Additional notes:

• A stdio MCP server works in the same Insiders build. Example: io.github.upstash/context7 starts successfully and discovers 2 tools.
• Supermemory works in VS Code Stable using the same account/server.
• Opening https://mcp.supermemory.ai/mcp in a browser returns Unauthorized, which appears expected and confirms the endpoint is reachable.
• Adding a Supermemory API key header did not change the error.
• This looks like remote type: "http" MCP transport is failing before auth/server-specific behavior matters.

Happy to test a proposed fix or collect more logs if useful.

[mattv8]

I had some time (and tokens) to throw at this problem, and here's what I think is happening:
The regression was introduced in 1.122 by the @vscode/proxy-agent upgrade from 0.41.0 -> 0.42.0 (via @deepak1556's microsoft/vscode-proxy-agent#100, commit 9cd7264dd10). The MCP HTTP client code itself was not changed between 1.121 and 1.122.

Most Likely Root Cause
The MCP HTTP transport calls fetch() with redirect: 'manual' to handle redirects manually. In the VS Code extension host, globalThis.fetch is monkey-patched by src/vs/workbench/api/node/proxyResolver.ts -> patchGlobalFetch(). When redirect: 'manual' is detected, the monkey-patched fetch routes the request through patchedFetch (from @vscode/proxy-agent's createFetchPatch) rather than using electron.net.fetch.

The call chain is:

McpHTTPHandle._sendStreamableHttp()
 -> _fetchWithAuthRetry()
 -> _fetch()                            # adds redirect: 'manual', signal, user-agent
 -> McpHTTPHandleNode._fetchInternal()  # imports undici (triggers patchUndici)
 -> super._fetchInternal()              # calls globalThis.fetch(url, init)
 -> monkey-patched globalThis.fetch     # proxyResolver.ts
 -> patchedFetch()                      # @vscode/proxy-agent createFetchPatch

Evidence

1. @vscode/proxy-agent 0.41.0 -> 0.42.0 is the only change in the fetch call chain:
   • 0.41.0 was in 1.121 (package-lock.json at tag 1.121.0)
   • 0.42.0 is in 1.122 (package-lock.json at tag 1.122.0)
   • Added the options parameter with { interceptors } support + withInterceptors dispatcher composition
2. MCP client code unchanged: extHostMcp.ts, extHostMcpNode.ts had zero behavioral changes (only a Windows shell escaping fix unrelated to fetch)
3. Runtime unchanged: Electron 39.8.8, Node.js 22.22.1, undici 7.24.4 — all identical between 1.121 and 1.122
4. proxyResolver.ts changes are minimal: only added __vscodeCreateFetchPatch exposure (needed by Copilot HTTP cache). The createPatchedFetch() is called without options (no interceptors), so the patched fetch behavior should be identical.
5. Error occurs before network: The TypeError: fetch failed happens 13ms after "Running" state, before any socket is opened — consistent with a failure in undici's dispatcher initialization or signal validation.

Isolated testing most likely won't reproduce this because testing proxy-agent 0.42.0 with redirect: 'manual', Uint8Array body, and AbortSignal in a standalone Node.js process works fine. The issue only manifests in the VS Code extension host where:

• globalThis.fetch is monkey-patched
• undici.Agent / undici.ProxyAgent are monkey-patched via patchUndici() when undici is imported
• The http, https, net, tls modules are intercepted and replaced
• The proxy resolution pipeline calls back to the main process via IPC

Recommended Fix / Verification

1. Verification: Downgrade @vscode/proxy-agent from 0.42.0 to 0.41.0 in a 1.122 build and test the MCP HTTP connection — if it works, the issue is confirmed in proxy-agent 0.42.0
2. Mitigation: In McpHTTPHandleNode._fetchInternal() (src/vs/workbench/api/node/extHostMcpNode.ts:150), after importing undici, use it directly for ALL http/https fetches (not just pipe/unix) instead of falling through to super._fetchInternal() which calls the monkey-patched globalThis.fetch. The undici fetch() from the imported module should bypass the proxy-agent monkey patch:

// For non-pipe, non-unix URLs, currently does:
} else {
    return super._fetchInternal(url, init);  // uses monkey-patched globalThis.fetch
}
// Could instead use undici's fetch directly:
} else {
    const { fetch } = await this._undici.value;
    const undiciResponse = await fetch(url, init);
    return { status: undiciResponse.status, ... };
}

[appatalks]

👋 team, Running into this too. Following.

[info] Starting server <mcp-server>
[info] Connection state: Starting
[info] Starting server from LocalProcess extension host
[info] Connection state: Running
[info] Connection state: Error Error sending message to https://<mcp-server>/mcp: TypeError: fetch failed

Testing results side-by-side

Build	Version	undici	proxy-agent	Remote HTTP MCP
VS Code (stable)	1.123.0	7.24.4	0.42.0	✅ works
VS Code Insiders	1.124.0-insider	7.26.0	0.42.0	❌ fetch failed

(macOS 26.5 Tahoe).

Potentially related issue:

• VS Code Insiders MCP + OAuth Protected Resource Regression (works in Stable, fails in Insiders) #319913