Cursor remote runtime locked to Node 20 — breaks modern extensions requiring Node ≥22 (node:sqlite)

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor remote SSH server uses Node.js 20.18.2 while desktop Cursor uses Node.js 22.x.
Many modern VSCode extensions now require Node ≥22 and rely on built-in modules such as node:sqlite.
When such extensions run in Cursor remote environment, they crash immediately because Node 20 does not provide these modules.
Example: Odoo extension fails with ERR_UNKNOWN_BUILTIN_MODULE: node:sqlite.
The same extensions work correctly in VSCode Remote SSH and other IDEs using Node ≥22.
This creates a runtime mismatch between local Cursor and remote Cursor server that breaks extension compatibility.

Steps to Reproduce

Install latest Cursor (2.4.28).
Connect to a remote Linux machine via SSH using Cursor.
Install an extension that requires Node ≥22 (example: vscode-odoo).
Open workspace and wait for extension host to start.
Extension server crashes with error:
Error [ERR_UNKNOWN_BUILTIN_MODULE]: No such built-in module: node:sqlite.

Expected Behavior

Cursor remote server should use the same Node.js major version as desktop Cursor (Node 22),
or provide a way to configure/override Node runtime for the remote extension host.
Extensions that require Node ≥22 should run normally in remote environments.

Operating System

MacOS

Version Information

Client: macOS (Apple Silicon)
Remote: Ubuntu 22.04 (SSH)

Version: 2.4.28
VSCode Version: 1.105.1
Date: 2026-02-03T00:56:18.293Z
Build Type: Stable
Release Track: Default
Electron: 39.2.7
Chromium: 142.0.7444.235
Node.js: 22.21.1
V8: 14.2.231.21-electron.0
OS: Darwin arm64 25.2.0

Remote cursor-server Node version: 20.18.2

For AI issues: which model did you use?

N/A

For AI issues: add Request ID with privacy disabled

N/A

Additional Information

This issue affects any extension that relies on Node ≥22 APIs (node:sqlite, node:test, newer Node built-ins).
Extensions work in:
VSCode Remote SSH
Antigravity IDE
Local Cursor
They fail only in Cursor remote SSH due to outdated Node runtime (20.x).
Remote runtime appears locked to Node 20 and does not update automatically with desktop Cursor runtime.
The same extensions run correctly in VSCode Remote SSH and Antigravity,
which use newer Node runtimes for their extension hosts.

CURSOR IDE
Version: 2.4.28
VSCode Version: 1.105.1
Date: 2026-02-03T00:56:18.293Z
Build Type: Stable
Release Track: Default
Electron: 39.2.7
Chromium: 142.0.7444.235
Node.js: 22.21.1
V8: 14.2.231.21-electron.0
OS: Darwin arm64 25.2.0

Local Node.js
➜ ~ node -v
v22.22.0

Antigravity
Chromium: 39.2.3
Node.js: 142.0.7444.175
V8: 22.21.1
ОС: 14.2.231.21-electron.0

Does this stop you from using Cursor

Yes - Cursor is unusable

4

Hey, thanks for the detailed report. The exact versions and the comparison with other IDEs were really helpful.

This is a bug. The remote cursor-server is currently using Node.js 20.18.2, while the desktop client ships with Node.js 22.x. Because of that, any extensions that depend on Node APIs from 22 or newer, like node:sqlite, will crash in the remote environment.

I’ve passed this on to the team.

7

How long will it take you to fix the bug?

11

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

cursor-server use old node 20.18, but many mcp-s require 20.19 or above.
in WSL

Steps to Reproduce

cd ~/.cursor-server/bin/…
./node -v

Screenshots / Screen Recordings

Screenshot 2026-04-17 163217.png
Screenshot 2026-04-17 163217.png962×101 9.86 KB

Operating System

Linux

Version Information

Version: 3.1.15 (user setup)
VSCode Version: 1.105.1
Commit: 3a67af7b780e0bfc8d32aefa96b8ff1cb8817f80
Date: 2026-04-15T01:46:06.515Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

Does this stop you from using Cursor

No - Cursor works, but with this issue

12

Can you provide a workaround? I need to call npxin a mcp server. How to set the node version for mcp server?

13

With cursor’s help, this is the rule I came up with that seems to be working for me. I was having a bunch of weird errors and discovered it was because the agent was using an unsupported version of Node. It even attempted to downgrade my project to fix it! No bueno… I’m not sure why the agent would even use a bundled version of node instead of just directing the user to install node if not already.

NOTE: I believe this fix requires that node is installed on the system via nvm.

cat .cursor/rules/node-pinned-npm-builds.mdc (remote system)


---
description: Prefer shell-resolved Node/npm for build and test commands
alwaysApply: true
---

# Shell-Resolved Node for npm Commands

Use the active shell Node/npm runtime for substantive npm commands so the agent does not default to Cursor's bundled Node runtime.

## Preferred command pattern

- Use the global wrapper script:
  - `bash ~/.cursor/scripts/npm-shell.sh run test`
  - `bash ~/.cursor/scripts/npm-shell.sh run build`
  - `bash ~/.cursor/scripts/npm-shell.sh run lint`

## Fallback when wrapper is unavailable

1. `export NVM_DIR="$HOME/.nvm"`
2. `[ -s "$NVM_DIR/nvm.sh" ] && . "$NVM_DIR/nvm.sh"`
3. `NVM_NODE="$(nvm which default 2>/dev/null || true)"`
4. If present: `NVM_BIN="$(dirname "$NVM_NODE")" && export PATH="$NVM_BIN:$PATH"`
5. Re-resolve:
   - `ACTIVE_NODE="$(command -v node)"`
   - `ACTIVE_NPM="$(command -v npm)"`
   - `ACTIVE_NODE_VERSION="$(node -v)"`
6. Execute with resolved npm:
   - `"$ACTIVE_NPM" run build` (or test/lint)

## Guardrails

- Never assume a hardcoded Node path/version.
- For substantive runs, report `ACTIVE_NODE` and `ACTIVE_NODE_VERSION` (or wrapper output equivalent).

Edit: this rule is installed on the remote system.

15

npm-shell.sh

#!/usr/bin/env bash
set -euo pipefail

export NVM_DIR="${HOME}/.nvm"
if [ -s "${NVM_DIR}/nvm.sh" ]; then
  # shellcheck disable=SC1090
  . "${NVM_DIR}/nvm.sh"
fi

NVM_NODE="$(nvm which default 2>/dev/null || true)"
if [ -n "${NVM_NODE}" ]; then
  NVM_BIN="$(dirname "${NVM_NODE}")"
  export PATH="${NVM_BIN}:${PATH}"
fi

ACTIVE_NODE="$(command -v node)"
ACTIVE_NPM="$(command -v npm)"
ACTIVE_NODE_VERSION="$(node -v)"

echo "Using node: ${ACTIVE_NODE} (${ACTIVE_NODE_VERSION})"
echo "Using npm:  ${ACTIVE_NPM}"

exec "${ACTIVE_NPM}" "$@"
16

Is there any update regarding this issue?

I am also experiencing this issue. I have global git hooks that use Node. They were failing because node 20 was being used. I found “~/.cursor-server/bin” being added to PATH variable. Currently, my workaround is to have my bash git hook remove the folder from PATH prior to calling node.

17

No, the Cursors development team still hasn’t fixed this. And they haven’t even given an approximate timeframe for fixing this bug. Because of this issue, I switched to Google’s Antigravity for projects that require functionality they still haven’t fixed.

19

Hey, no update on the fix yet. Both issues are logged and sitting in the backlog the Node 22 upgrade and the PATH override from cursor-server/bin. I can’t share an ETA.

Your workaround removing ~/.cursor-server/bin from PATH before calling node is valid. For users with nvm, in post #13 above @minuteZERO shared a rule plus a wrapper script that forces the active shell node instead of the bundled one. That works too.

I’ll post here when there’s an update on the fix.