Desktop app local MCP can fail when PATH resolves an older Node, while CLI works #22299

Summary

When using the desktop app, a local MCP configured as npx -y @mcp_router/cli@latest connect fails with MCP error -32000: Connection closed.

The same config works from the terminal with opencode mcp list.

This looks like a desktop/runtime environment bug rather than an mcp-router bug. The desktop app appears to launch the MCP child process with a different Node/PATH resolution than the terminal.

Environment

• OpenCode version: 1.4.3
• macOS: 13.3 (22E252)
• Terminal Node: v22.19.0
• Also installed on machine: /usr/local/bin/node -> v16.16.0

MCP config

{
  "mcp": {
    "mcp-router": {
      "command": ["npx", "-y", "@mcp_router/cli@latest", "connect"],
      "environment": {
        "MCPR_TOKEN": "<redacted>"
      },
      "type": "local"
    }
  }
}

What happens

In the desktop UI, mcp-router shows as failed / disconnected.

OpenCode log shows:

file:///Users/.../.npm/_npx/.../node_modules/@hono/node-server/dist/index.mjs:23
var Request = class extends GlobalRequest {
              ^

TypeError: Class extends value undefined is not a constructor or null

And then:

MCP error -32000: Connection closed

Why this seems like a PATH / Node version issue

The failure is consistent with @mcp_router/cli being started under an older Node runtime where global.Request is not available.

On this machine:

• terminal node -v -> v22.19.0
• /usr/local/bin/node -v -> v16.16.0

The same mcp-router config works fine when run from terminal via opencode mcp list, but fails in the desktop app. That strongly suggests desktop and terminal are resolving a different Node / PATH for local MCP child processes.

Workaround

I was able to make the desktop app connect by forcing the MCP command to run with a PATH that puts Node 22 first, for example:

{
  "command": [
    "/bin/zsh",
    "-c",
    "export PATH="/Users/<user>/.nvm/versions/node/v22.19.0/bin:/usr/local/bin:/usr/bin:/bin"; exec npx -y @mcp_router/cli@latest connect"
  ]
}

After that, the desktop app connected successfully.

Expected

Desktop app local MCP startup should behave consistently with terminal opencode mcp list, or at least use a predictable Node runtime / PATH resolution strategy.

Possible fix direction

• Make local MCP child processes use a controlled PATH / runtime instead of inheriting an ambiguous desktop environment
• Or log the exact resolved executable / PATH / Node version used for local MCP startup to make this diagnosable

If useful, I can provide a cleaned log excerpt.