create_relations and add_observations failing WSL2 VSCode

[davidw-philips]

Describe the bug
I'm using VSCODE copilot 4.5 with a custom Agent mode.

To Reproduce
Steps to reproduce the behavior:

For add_observations

Input:
{
"observations": [
{
"entityName": "project",
"contents": [
"Implemented",
"Status system modules: ",
"Status states: CANCELLED",
"All 30 unit tests passing for functionality",
"Progress bar",
"System designed"
]
}
]
}

Output:
Error: MPC -32603: Unexpected non-whitespace character after JSON at position 127 (line 1 column 128)

For create_entities

Input:
{
"relations": [
{
"from": "framework project",
"to": "Implementation",
"relationType": "implements"
}
]
}

Output:
Error: MPC -32603: Unexpected non-whitespace character after JSON at position 127 (line 1 column 128)

Expected behavior
A clear and concise description of what you expected to happen.

Logs
2025-11-17 12:22:01.801 [info] Error reading from async stream, we will reconnect: TypeError: terminated
2025-11-17 12:27:03.682 [info] Error reading from async stream, we will reconnect: TypeError: terminated

Additional context
Restarting it did not work. It failed again with the same error. Here's the MCP.json entry:
"memory": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-memory"],
"startupTimeout": 30000
},

[sstklen]

Hey! I ran into a similar pattern in our bug knowledge base and thought this might help.

What's happening: npx stdout pollution in WSL2 environment. When using npx -y @modelcontextprotocol/server-memory, npx writes package resolution/download messages to stdout before the MCP server starts. Since MCP stdio transport uses stdout for JSON-RPC communication, these extra bytes get prepended or interleaved with JSON-RPC messages. The consistent 'position 127' error indicates a fixed-size npx output fragment is being concatenated with the JSON-RPC payload, causing JSON.parse() to fail. WSL2 exacerbates this because the Windows/Linux interop layer can buffer and flush stdout differently than native Linux.

What worked for us:

Avoid npx stdout pollution by either: (1) installing the package globally first and referencing the binary directly, or (2) using a wrapper script that separates npx setup output from the MCP server's stdout. The core issue is that npx mixes its own diagnostic output with the server's JSON-RPC stdout stream.

Steps:

1. Option A (recommended): Install globally first, then reference directly. Run: npm install -g @modelcontextprotocol/server-memory
2. Update MCP config to use the installed binary directly: { "command": "mcp-server-memory", "args": [] }
3. Option B: Use node directly by finding the package path. Run: npx -y @modelcontextprotocol/server-memory (once to install), then find path with: npm root -g
4. Update MCP config: { "command": "node", "args": ["/path/to/global/node_modules/@modelcontextprotocol/server-memory/dist/index.js"] }
5. Option C: If using WSL2, ensure the MCP server runs inside WSL natively, not through Windows interop. Set the command to use the WSL-native node/npx path explicitly.

// mcp.json - Option A: global install avoids npx stdout noise
{
  "memory": {
    "command": "mcp-server-memory",
    "args": [],
    "startupTimeout": 30000
  }
}

// OR Option B: wrapper script (save as run-memory-server.sh)
// #!/bin/bash
// exec node $(npm root -g)/@modelcontextprotocol/server-memory/dist/index.js "$@"

// Then in mcp.json:
// { "command": "bash", "args": ["/path/to/run-memory-server.sh"] }

📊 We found 1 similar case in our knowledge base with the same pattern — this gives us medium confidence in this analysis.

Hope this helps! Let me know if it doesn't match your case — happy to dig deeper. 🦞

Disclosure: This analysis is from Confucius Debug, an AI-powered community KB for agent bugs. Please verify before applying.

---

_{🦞 Confucius Debug — community knowledge base for AI agent bugs. Free to search via MCP.}

[localden]

Closing as a duplicate of #2030; let's track it there.