Cursor3.9 works fine but 3.10 not works on ssh to ubuntu18.04

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Bug Report: Remote-SSH connection fails on older Linux distros (Ubuntu 18.04) due to GLIBC_2.28 requirement in v3.10+
Describe the bug
After updating Cursor to the latest version (v3.10+), the Remote-SSH extension fails to connect to older Linux servers (such as Ubuntu 18.04). The Cursor Server installation script fails with an error indicating that the bundled NodeJS requires GLIBC_2.28, which is missing on these systems.
This issue did not occur in Cursor v3.9 (where Remote-SSH worked perfectly under the same server environment).
To Reproduce
Use Cursor v3.10+ on the local machine.
Attempt to connect via Remote-SSH to a remote server running Ubuntu 18.04 LTS (or any distro with glibc < 2.28).
The connection fails during the “Checking node executable” phase.

Steps to Reproduce

[info] (ssh_tunnel) stdout: Checking node executable
[info] (ssh_tunnel) stdout: Node executable at /home/user/.cursor-server/bin/linux-x64/…/node is not working, checking system node
[info] (ssh_tunnel) stderr: …/node: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.28’ not found
[error] Error installing server: Couldn’t install Cursor Server: The bundled NodeJS failed to run, and system node is too old. Please manually install NodeJS 20 or higher on your remote system

Operating System

Linux

Version Information

Version3.9 works fine when ssh remote to ubuntu18.04, but version 3.10 not works.

Does this stop you from using Cursor

Yes - Cursor is unusable

5

Hey, thanks for the detailed report and logs. This isn’t a bug, it’s a platform requirement change.

Starting with 3.10, the remote cursor-server requires glibc >= 2.28. Upstream VS Code did the same for its server. Ubuntu 18.04 ships glibc 2.27 and has been EOL since mid 2023, so it fails at Checking node executable. The bundled Node just can’t link against libc 2.27, which is why you see version GLIBC_2.28 not found. In 3.9, the remote-server used an older Node/base where 18.04 still met the minimum.

Our direction is to raise the minimum runtime version, not bring back 18.04 support, so there won’t be an automatic fix here. Your options are:

  • Upgrade the OS on the remote host to 20.04+ where glibc is 2.31. This is the most reliable path.
  • Stay on Cursor 3.9 locally if you can’t upgrade the host yet.
  • Install a newer glibc on 18.04. It’s possible, but risky for the system environment, so I wouldn’t recommend it for production.

Quick note about the skip flag VSCODE_SERVER_CUSTOM_GLIBC_LINKER. It only skips the check script, but it won’t make the bundled Node link with glibc 2.27, so it won’t work as a real workaround unless you also patch glibc.

Related discussion: Subject: Forced updates broke Remote SSH on production servers — please fix rollback and legacy Linux support
Let me know if upgrading the host isn’t an option and I can share more details.

6

Thank you for the detailed and clear explanation. I completely understand that following upstream VS Code’s decision to drop support for legacy glibc (< 2.28) environments is a necessary direction for Cursor’s long-term maintenance.

Unfortunately, in my case, upgrading the remote host’s operating system from Ubuntu 18.04 is absolutely not an option due to strict hardware/production environment constraints.

Since staying permanently on an outdated local Cursor version (v3.9) is also not ideal for catching up with your latest AI features, I would deeply appreciate it if you could share more details on the alternative workarounds you mentioned at the end of your message.

Specifically, I would like to know:

  1. Is there a viable way to manually inject or point the cursor-server to a custom-built/patched Node.js binary on the remote host that can run on glibc 2.27?

  2. Are there any other community-tested workarounds (like specific Docker/Container routing or glibc shims) that you would recommend for environments like mine?

Thank you again for your time and support!

7

Hey, glad the explanation helped. I’ll answer both requests directly.

  1. Pointing cursor-server to a custom Node for glibc 2.27

There’s no official way to tell the server to use a custom Node binary, but there’s a community workaround that effectively does this. It installs Node 20 together with compatible runtime libs and injects them via LD_LIBRARY_PATH. The author @Liujh0223 shared a working setup using conda in this forum thread: Subject: Forced updates broke Remote SSH on production servers — please fix rollback and legacy Linux support

conda create -n cursor-node -c conda-forge nodejs=20 libstdcxx-ng libgcc-ng -y
echo 'export PATH=$HOME/anaconda3/envs/cursor-node/bin:$PATH' >> ~/.bashrc
echo 'export LD_LIBRARY_PATH=$HOME/anaconda3/envs/cursor-node/lib:$HOME/anaconda3/lib:$LD_LIBRARY_PATH' >> ~/.bashrc

Do the same in ~/.bash_profile too.

The idea is that conda brings its own libstdc++ and libgcc, and Node links against those instead of the system glibc 2.27. For some users this removes GLIBC errors. You’re on glibc 2.27, not 2.17 like CentOS 7 in that thread, so the odds it works are better. One note, this is unsupported and only community tested, so expect possible rough edges.

  1. Docker and glibc shims

We don’t have an official Docker recipe for this, and honestly it’s hard to make it reliable. You can’t fully swap glibc via LD_PRELOAD or shims. glibc isn’t just a library you can drop in, so I wouldn’t recommend glibc shims for this.

The only truly reliable container approach is to run your dev environment inside a container based on glibc 2.28 or newer, like Ubuntu 20.04+, Debian 10+, or Rocky or Alma 8, then connect to that. In practice it’s similar to running a newer OS, just isolated. If you can’t upgrade the host due to hardware or production limits, a container on top can be a compromise.

Another option in the same area is the Anysphere Remote - SSH extension instead of Microsoft Remote - SSH. It helped some users on glibc 2.27. Details are here: GLIBC backward compatibility

If the conda approach or the Anysphere extension works for you, let me know how it goes. If not, share the logs from the Remote - SSH output window and we can dig in.