Try to install python
I had the same issue with both Cursor and Windsurf on Mac while the mcp servers in Claude worked fine, Consulting with the Warp terminal(highly recomended) the issue was resolved for both clients:
The “npx not found” error in Windsurf persists due to environment isolation - the application isn’t inheriting your shell’s PATH. Let’s implement a universal fix:
Root Cause:
Windsurf runs in a restricted environment (likely a non-interactive shell) that doesn’t source your .bash_profile or .zshrc.
Secure Fix:
Create a system-recognized symlink without sudo using homebrew’s link system:
- Leverage Homebrew’s linking capability (safer than manual symlinks)
brew link --overwrite node
- Verify the symlink chain
ls -l $(which npx) | awk ‘{print $9 " → " $11}’
Post-Fix Verification:
Start Windsurf - npx should now resolve via the standard /usr/local/bin PATH entry.
The error persists because Windsurf isn’t sourcing Homebrew’s binaries path. Let’s implement a universally-recognized fix:
Guaranteed Resolution
Add Homebrew’s binary path to macOS’s global PATH via /etc/paths.d/ (system-approved method):
- Create system-wide path configuration (no sudo needed)
echo ‘/opt/homebrew/bin’ | sudo tee /etc/paths.d/homebrew
- Verify impact across all shells/apps
sudo cat /etc/paths.d/homebrew
This ensures every application (including Windsurf) sees the correct npx path system-wide.
In a nutshell, invoking mcp in cursor is different from other vscode forks if you are using cursor from windows and executing in remote wsl. You have to treat it like running in powershell on windows. So to do this, you need this configuration:
{
“mcpServers”: {
“git”: {
“command”: “wsl”,
“args”: [
“zsh”,
“-c”,
“‘/home/allenpan/.local/bin/uvx mcp-server-git --repository /home/allenpan/repos/nezha.wukong’”
]
}
}
}
You can verify this by running the command directly in powershell which uses wsl and execute through zsh, and you have to point the the exact path of your npm or uvx executables. I am not what is missing from cursors, but I could confirm other vscode forks like windsurf can direct command as uvx or npm, maybe this is a bug to file?
I use both of wsl2 and macos. Meanwhile, I use fnm for managing nodejs version. I met this problem on both systems. And I think I figure out the reason and solution. No matter you use cline or Cursor.
Connect MCP Servers error"spawn npx enoent" means mcp client can’t correctly find npx command in your system. So if you’re using fnm, don’t use which npx to set npx path directly. This path is temporarily created by fnm so it’ll outdate when restart device.
The right way is to find to your fnm directory by command which fnm. For example, mine is /Users/CHJ/.local/state/fnm_multishells/32996_1746258653075/bin/npx. Then access to /Users/CHJ/.local/share/fnm/node-version/<select a version you want to use>/installation/bin/, you should be able to see npx file. To my understanding, fnm create temporary folder based on these nodejs versions under /Users/CHJ/.local/share/fnm/.
Whatever, find the npx file that is constant and permanent. Then use this path alternate the npx in every mcp setting json.
For example, in wsl2 using context7 mcp server by Cursor:
{
"mcpServers": {
"context7": {
"command": "wsl",
"args": [
"bash",
"-c",
"'/Users/CHJ/.local/share/fnm/node-versions/v22.15.0/installation/bin/npx -y @upstash/context7-mcp@latest'"
],
"enabled": true
}
}
}
in macos using context7 mcp server by Cursor:
{
"mcpServers": {
"context7": {
"command": "/Users/CHJ/.local/share/fnm/node-versions/v22.15.0/installation/bin/npx",
"args": [
"-y",
"@upstash/context7-mcp@latest"
]
}
}
}
Hope it can help you.
Use same mcp server settings (in json file) as follows.
{
"servers"[or "mcpServers"]: {
"weather": {
"command": "uv",
"args": [
"--directory",
"/projects/mcp-weather",
"run",
"weather.py"
]
}
}
}
The results of different scenarios:
-
In Local Windows PC
- Vsocode → ok
- Cursor → ok
-
Local Windows SSH Remote Development Connect Linux Server
- Vsocode itself (copilot)-> ok
- Augment / Roo Code / Cline in Vscode → ok
- Augment / Roo Code / Cline in Cursor → ok
- Cursor Itself (.cursor/mcp.json) → Error: client closed
Only the last scenario failed. When I used the json settings above in .cursor/mcp.json. It has the error as follows.
2025-05-13 09:40:47.546 [info] ther: Handling ReloadClient action
2025-05-13 09:40:47.546 [info] ther: Starting new stdio process with command: uv --directory /projects/weather run weather.py
2025-05-13 09:40:47.614 [info] ther: Client closed for command
2025-05-13 09:40:47.614 [error] ther: Failed to reload client: MCP error -32000: Connection closed
What is the root cause? How to fix it?
Now with cursor 0.50, this should no longer be a problem for people who are using wsl due to the support of Run stdio from remote workspace (WSL, Remote SSH). Just use
"git": {
"command": "uvx",
"args": ["mcp-server-git"]
}
like normal case.
You don’t need to manually invoke wsl like this before
"context7": {
"command": "wsl",
"args": [
"zsh",
"-c",
"'source /home/allenpan/.nvm/nvm.sh && /home/allenpan/.nvm/versions/node/v24.0.0/bin/npx -y @upstash/context7-mcp@latest'"
]
}
That all sounds like good suggestions! However, you CAN NOT fix the problem, until you really see the error message!
How to do it.
- Setup Process Explorer
- Go to Process Explorer, set Options > Difference Highlight Duration to 9 seconds
- Open Registry Editor, find the key
HKEY_CURRENT_USER\Software\Sysinternals\Process Explorer\HighlightDuration - Set the key to some reasonable value, like 60000 milliseconds
- Try to restart MCP server from the Cursor interface
- Quickly switch to Process Explorer and find recently exited subprocess of Cursor
- Open the subprocess details
- Copy the command line
- Open a terminal and run the command line that is executed by Cursor
Now, you have the real error message that you need to fix. Once you fix it, you can start the MCP server in Cursor and it should work.
I explained it here, with details and images:
P.S. If someone from Cursor team reads it, please redirect error message from command line to MCP Output logs. It will make troubleshooting easier.
1 Like
cc @msfeldstein
Next version (51) will have stderr properly redirected to mcp output logs
Sorry it took so long, had to upstream a patch to the sdk
1 Like
That would be awesome!
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.