Doesn’t work anymore in 0.51
This worked in 50 but now in 51 doesn’t. What’s different?
Can you give more details what you’re trying to do, what server you’re running, any errors?
We added support for oauth but that shouldn’t have broken anything
As @mwjt42 said, I used MCP when working in WSL with no extra hacks in 0.50, but in 0.51:
2025-05-31 21:39:30.033 [warning] No workspace folders found, using current path for . expansion
2025-05-31 21:39:30.033 [info] king: Starting new stdio process with command: npx -y @modelcontextprotocol/server-sequential-thinking
2025-05-31 21:39:31.301 [error] user-sequential-thinking: Sequential Thinking MCP Server running on stdio
2025-05-31 21:40:26.889 [info] king: Client closed for command
2025-05-31 21:40:26.910 [info] king: Handling ListOfferings action
2025-05-31 21:40:26.910 [error] king: No server info found
0 verbose cli C:\Program Files\nodejs\node.exe C:\Program Files\nodejs\node_modules\npm\bin\npm-cli.js
1 info using [email protected]
2 info using [email protected]
3 silly config load:file:C:\Program Files\nodejs\node_modules\npm\npmrc
4 silly config load:file:C:\Users\memyselfandi\.npmrc
5 silly config load:file:C:\Users\memyselfandi\AppData\Roaming\npm\etc\npmrc
6 verbose title npm exec @modelcontextprotocol/server-sequential-thinking
7 verbose argv "exec" "--yes" "--" "@modelcontextprotocol/server-sequential-thinking"
8 verbose logfile logs-max:10 dir:C:\Users\memyselfandi\AppData\Local\npm-cache\_logs\2025-05-31T19_39_30_311Z-
9 verbose logfile C:\Users\memyselfandi\AppData\Local\npm-cache\_logs\2025-05-31T19_39_30_311Z-debug-0.log
10 silly logfile start cleaning logs, removing 1 files
11 silly logfile done cleaning log files
12 silly packumentCache heap:4345298944 maxSize:1086324736 maxEntrySize:543162368
13 http fetch GET 200 https://registry.npmjs.org/@modelcontextprotocol%2fserver-sequential-thinking 178ms (cache revalidated)
14 silly packumentCache heap:4345298944 maxSize:1086324736 maxEntrySize:543162368
15 verbose cwd C:\Users\memyselfandi\AppData\Local\Programs\cursor
16 verbose os Windows_NT 10.0.26100
17 verbose node v22.14.0
18 verbose npm v10.9.2
19 verbose exit 0
20 info ok
So, as I can see - now my MCP settings file is in WSL home. That is the difference between 0.50 and 0.51. MCP starts in Windows not in WSL. And then I get time out.
I had 2 issues on WSL with Bun. Going to “Output” tab > “MCP Logs” helped me figure it out.
-
I wanted to use
bunx
and it wasn’t found even though I have it installed. So I had to use the full path “~/.bun/bin/bunx” -
Then it was running but was using the older version of node I have installed not through nvm which wasn’t compatible with the MCP server code. Adding
--bun
to command forces it to use bun instead and now it’s working.
@msfeldstein, I forgot to mention that all MCPs in WSL have the same issue. Anyone else has this issue?
FYI, since 0.51/1.0 in WSL you should use cmd:
{
"mcpServers": {
"context7": {
"command": "cmd.exe",
"args": [
"/c",
"npx",
"-y",
"@upstash/context7-mcp@latest"
]
}
}
}
Just using “cmd” won’t work, it has to be “cmd.exe”
I am on Cursor 1.0.1
I have found a solution for running a MCP servers in WSL. The key issues were:
-
Cursor defaults to Windows commands even in WSL projects
-
Non-interactive WSL shells don’t load nvm/node properly
-
Environment variables don’t pass through wsl.exe boundary
Working solution:
-
Use wsl.exe explicitly to force WSL execution
-
Export PATH to include node/npm and system binaries
-
Embed environment variables in the command (env section doesn’t work with WSL)
This configuration successfully connects and loads all 39 MCP tools:
{
"mcpServers": {
"todoist": {
"command": "wsl.exe",
"args": [
"bash",
"-c",
"cd /home/phil71/code/mcp-testing && export PATH='/home/phil71/.nvm/versions/node/v24.1.0/bin:/usr/bin:/bin:$PATH' && export TODOIST_API_KEY='xxx' && npx -y doist/todoist-mcp"
]
}
}
}
I have recently migrated all my projects on WSL. Cursor seems to work better, especially with project rules. For MCP servers, not so much.
I will wait a little bit for these issues to iron out.
My understanding was from ~0.51 the wsl.exe bash/cmd -c workarounds were no longer necessary, and ‘npx’ would run (as expected) in WSL if Cursor was connected to it.
At least I thought that was happening… It certainly seemed to work!