Hey, this is a known issue. On WSL and Remote SSH, cursor-server puts its bundled Node v20.18.2 at the front of PATH, and git hooks via husky pick that up instead of your system nvm or fnm Node. There are similar reports already:
We’re tracking this on our side, but I can’t share an exact fix date yet. As a workaround, you can explicitly call the Node you need in the hook, for example via the absolute path to your nvm version or npx --node-version=22, but that’s a workaround, not a real fix. I’ll post in the thread when we have an update on the fix.
I hit the same issue when committing from Cursor Source Control.
The Git hook reports:
Detected Node.js v20.18.2
This suggests Cursor’s Git commit flow is not using the integrated terminal shell environment. When clicking Commit in the Source Control panel, the Git hook appears to be launched by Cursor’s Git extension process, inheriting the environment from the Cursor desktop app startup, rather than the Node version selected later via nvm in the integrated terminal.
Expected: Git hooks launched from Cursor Source Control should respect the workspace/user shell Node environment, or at least provide a documented way to configure the Node used by hooks.
Hey, @YTY1, yep, it’s the same issue described in the thread above. The Source Control commit runs git hooks via an extension that inherits the cursor-server environment, with its bundled Node v20.18.2 at the start of PATH, so switching via nvm in the integrated terminal doesn’t get picked up.
We’re tracking this bug, but I can’t share an ETA for a fix yet. As a workaround, you can explicitly point the hook to the Node you need, either by using the absolute path to your nvm version or via npx --node-version=22. We’ll post an update in the thread once we have it.
If anyone’s using husky/nvm, here’s what worked for me on WSL: husky sources ~/.config/husky/init.sh before every hook, so you can force your nvm Node onto PATH there and beat cursor-server to it:
Worth knowing: sourcing nvm.sh on its own won’t fix it, and nvm use default doesn’t either. Cursor-server’s bin still ends up earlier in PATH for some reason, so you have to prepend it yourself. The snippet follows whatever your nvm default is. If you want to pin a specific version, just hardcode the path on the NODE_BIN= line.
Hey @Anas thanks for the detailed snippet with ~/.config/husky/init.sh. It’s cleaner than what I suggested above, and it should work for most users on nvm. I’ll leave it here as a reference for anyone who comes across this thread.
As for the bug, we’re still tracking the issue on our side, and there’s no ETA for a fix yet. As soon as I have an update, I’ll reply here.
Hey folks, I can’t run any vscode task that requires Node LTS because of this nonsense. I don’t use cloud agents and don’t care about them, but you decided to put whatever is bundled with Cursor into PATH of EVERY task that can be triggered from the IDE. That’s poor engineering, please own it and fix it already. This is unacceptable.
Hey @goodov, this is a known bug and this thread is about it.
It’s not just cloud agents. In WSL and Remote SSH, cursor-server puts its bundled Node v20.18.2 at the front of PATH for anything launched via extensions like git hooks, tasks, and source control. The usual workarounds via server-env-setup, .bashrc, or nvm use don’t work because cursor-server prepends its bin again after those scripts run.
We’ve reported the issue internally. There’s no ETA for a fix yet, and we’ll post an update here as soon as we have one.
For now, as a workaround for tasks, you can either set an absolute path to the Node you want in the task definition, or use the same approach as @Anas in Post #9 which force-prepends your desired bin to the front of PATH in your shell init script. It’s not ideal, but it works until we ship a fix.
Is the fix coming? At the moment, any node script launched by an agent from the agent window is still hitting this problem, agents workaround is to use local npx and reinstall pnpm store
This is very slow and resource consuming, it starts to be blocking. I find myself returning back to TUI for agents, defeating the purpose of a tool like cursor.
@Antoine_Codogno A fix should have landed in 3.7.5. If you’re using a newer version, could I suggest you raise a new bug report with all sections filled out including steps to reproduce? It will help us determine whether it’s the same issue.
