MCP server launched via npx crashes repeatedly in dsh on Windows (no TTY): node.exe error popup + "fetch failed"

[datongcfl]

Environment

• dsh 0.1.0-rc.6, Windows 11
• MCP server: @modelcontextprotocol/server-github@2025.4.8 (stdio transport)

Config

- id: mcp-github
  name: '@deepseek-ai/dsh-mcp-client'
  config:
    serverName: github
    transport: stdio
    command: cmd
    args: ['/c', 'npx', '-y', '@modelcontextprotocol/server-github@2025.4.8']
    env:
      GITHUB_TOKEN: !!js process.env.GITHUB_TOKEN

Symptoms

1. Windows "node.exe - Application Error" popups appear repeatedly while working.
2. Every call to mcp__github__* tools fails with MCP error -32603: fetch failed.
3. The spawned MCP server node process keeps dying and being restarted (observed PID churn: a process disappears, a new one appears ~2 minutes later), so the popups recur.

What works fine on the same machine

• Running the same server manually responds to MCP initialize correctly:
  npx -y @modelcontextprotocol/server-github@2025.4.8 → serverInfo: github-mcp-server 0.6.2.
• Same result via cmd /c npx ... (mimicking the dsh spawn path).
• GITHUB_TOKEN is valid: GET https://api.github.com/user with the token returns the authenticated user.
• Network to api.github.com is fine.

Hypothesis

The failure only happens when the server is spawned by dsh (no TTY, stdio pipes owned by the host). This looks like the known class of issues where npx-based MCP servers fail silently in no-TTY environments (e.g. anthropics/claude-code#25044, modelcontextprotocol/servers#1082). npx does its own version resolution and child-process indirection, which can misbehave when stdin/stdout are pipes rather than a TTY.

Suggested improvements

1. On Windows, allow / document launching MCP servers via the direct Node entry path instead of going through npx (avoid the .cmd/ps1 wrapper + npx indirection).
2. Add a Windows-specific section to the mcp-client README with a known-good config template.
3. Log the spawned server's exit code / stderr when it dies, so "crash loop" cases like this are diagnosable from logs alone.

Happy to provide more logs or test another configuration if useful. Thanks for the great project!

[Electricitysheep]

Windows 无 TTY 下 MCP stdio server 用 npx 拉起崩溃（node.exe error popup + fetch failed）——Windows 上 stdio 传输的经典问题：无 TTY 时 npx 子进程的 stdio 握手不稳定。

临时：1) MCP server 用本地安装（非 npx 即时拉取）2) 检查 PATH 里 node 可达性。MCP 接入细节见第 9 章：https://github.com/Electricitysheep/dsh-handbook/blob/main/docs/09-mcp-subagent-workflow.md

[datongcfl]

@Electricitysheep Thanks for confirming the root cause — and the handbook ch.9 was exactly the reference I needed!

Here's how I handled it on my end:

1. Disabled the npx-based GitHub MCP server (disabled: true in cordis.patch.yml) to stop the crash loop and node.exe error popups.
2. Replaced it with a small shared Python module (github_runner.py) that calls the GitHub REST API directly via GITHUB_TOKEN — no npx, no stdio handshake. search / repo / read / issue / tags all work reliably.
3. Also pinned @playwright/mcp to 0.0.79 (was @latest) for the same stability reason.

Your suggested local-install approach (pre-install the server, then run via node directly instead of npx) is exactly the right follow-up — I'll try that next to restore the native mcp__github__* tools. Will report back here if it stabilizes.

Thanks again!

[Electricitysheep]

It is my pleasure.

[datongcfl]

@Electricitysheep Confirmed — your fix works. ✅

What I did:

• Pre-installed the server locally: npm install -g @modelcontextprotocol/server-github@2025.4.8
• Pointed the config at the local entry via node directly (no npx):
  command: D:\Program Files\nodejs\node.exe, args: [<npm-global>/@modelcontextprotocol/server-github/dist/index.js]

Result:

• mcp__github__* tools are now stable — multiple searches succeeded in a row.
• The earlier crash loop, node.exe error popups, and fetch failed are gone.
• Root cause confirmed: npx stdio handshake is unstable in a no-TTY environment on Windows.

So for anyone else hitting this: pre-install the MCP server and launch it via node directly (or another non-npx launcher) on Windows. Thanks again for the pointer!