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.
Summary
When using the desktop app, a local MCP configured as
npx -y @mcp_router/cli@latest connectfails withMCP 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-routerbug. The desktop app appears to launch the MCP child process with a different Node/PATH resolution than the terminal.Environment
1.4.313.3 (22E252)v22.19.0/usr/local/bin/node -> v16.16.0MCP 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-routershows as failed / disconnected.OpenCode log shows:
And then:
Why this seems like a PATH / Node version issue
The failure is consistent with
@mcp_router/clibeing started under an older Node runtime whereglobal.Requestis not available.On this machine:
node -v->v22.19.0/usr/local/bin/node -v->v16.16.0The same
mcp-routerconfig works fine when run from terminal viaopencode 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
If useful, I can provide a cleaned log excerpt.