I am writing to formally complain about a severely degraded experience after a recent Cursor update. I rely on Remote SSH daily for development on remote Linux servers, and the latest version has made my workflow unusable without any clear warning or recovery path.
What happened
After updating Cursor, connecting to my remote Linux server via Remote SSH fails repeatedly.
The client attempts to download and install Cursor Server from downloads.cursor.com. On my server this fails with “Unable to establish SSL connection” (the OS has an outdated OpenSSL/TLS stack).
Even after I manually uploaded and installed the server package, the client still failed because:
The install path changed (missing linux-x64 segment).
The commit hash in the download URL did not match the runtime path the client actually checks.
When the server files were finally in the correct location, the bundled Node.js 20+ failed with errors such as:
GLIBC_2.27 not found
GLIBC_2.28 not found
GLIBCXX_3.4.21 not found
The error message explicitly states: “Please manually install Node.js 20 or higher on your remote system” — but Node 20 does not run on older enterprise Linux due to glibc limitations. This is a dead end for many servers still on legacy distributions.
Why I am upset
I did not change my server; Cursor updated on Windows and broke a previously working setup.
There is no easy rollback: auto-update pushes the latest version; update.mode: none is unreliable on Windows.
Remote SSH install scripts assume modern Linux (glibc 2.27+, Node 20+), but many real production servers still run older LTS distributions.
I spent hours manually fixing paths, symlinks, and uploads — work that should not fall on users.
Your product positions itself as a VS Code replacement for professional development, yet remote development on common server OS versions is effectively unsupported after update.
What I expect from Cursor
Document minimum remote server requirements clearly (glibc version, Node version, supported distros) before users update.
Stop forcing auto-updates or provide a reliable “stay on this version” option on Windows.
Ship Remote Server builds compatible with older glibc, or clearly document unsupported legacy systems and suggest alternatives.
Align commit hashes between download URLs and runtime paths to avoid manual install confusion.
Provide an official rollback path and older client installers without hunting third-party mirrors.
Until these issues are addressed, I cannot recommend Cursor for teams using legacy Linux servers. I am considering downgrading and permanently disabling updates, which should not be necessary for a paid professional tool.
I expect a substantive response, not a generic troubleshooting link.
Sincerely,
[WELLS_HR]
[[email protected]]
Remote OS: legacy enterprise Linux (glibc 2.17 class)
Client: Windows 10, recent Cursor 3.10.x (attempting rollback)
A colleague facing the same situation was having trouble.
It will not be easy to perform version updates in the future.
Given the high expectations I had, this situation makes me unsure whether to continue using it.
I completely agree. I was also using CentOS 7, and after updating, SSH connections stopped working, forcing me to downgrade.
If the only way to keep using Cursor is to stay on an older version, we will have no choice but to consider discontinuing its use. I hope this issue will be addressed as soon as possible.
Same here. Please DO address this issue, or in no time many will turn to alternatives once and for all. Also, I would prefer receiving warnings of certain dependency changes prior to upgrade launching in the future.
the same problem occurred on mu centos 7 system !
hope the Cursor team can solve this problem as soon.
because many productivity servers are based on the old system.
by the way, why i from VScode to Cursor, it was becuase it supports the old system !
Hey, thanks for the detailed write-up, it helps pinpoint where things break. I’ll respond directly, without generic links.
What’s happening: starting from recent versions, Cursor Server, same as upstream VS Code since 1.99, requires glibc >= 2.28 and GLIBCXX >= 3.4.25 on the remote machine. The bundled Node in the server is now v22, which also needs glibc 2.28+. Your server CentOS 7 or similar with glibc 2.17 is below that bar, so manually installing Node 20 won’t help since it hits the same glibc limit. This isn’t a client-side bug, it’s the minimum requirements being raised in line with upstream. To be transparent, bringing back support for legacy glibc 2.17 isn’t planned right now, so I don’t want to promise a fix that may not happen.
Practical options you can try right now:
Community workaround from this thread, Liujh0223 Post #11. Right now this is the best path without an OS upgrade. Install nodejs=20 via conda together with compatible libstdcxx-ng and libgcc-ng, then set LD_LIBRARY_PATH. For a few users this temporarily removes the GLIBC errors.
Use the Anysphere Remote - SSH extension instead of Microsoft Remote - SSH. This helped users on glibc 2.27, see thread 113316: GLIBC backward compatibility. On 2.17 it still might not start, but it’s worth a try.
Pin an older version: set “update.mode”: “none” in settings, and you can grab an older client installer from the community mirror oslook/cursor-ai-downloads that you already mentioned. This lets you stay on a version whose server still worked with legacy glibc.
The real long-term fix is upgrading the remote OS to glibc 2.28+, like RHEL, Alma, Rocky 8+, Ubuntu 20.04+, or Debian 10+, if that’s possible for your servers.
On the other points, documenting minimum remote server requirements ahead of time, warning about dependency changes before updates, and a reliable stay on version flow on Windows, that feedback makes sense and I’ll pass it to the team. The artifacts you saw like missing linux-x64 and a commit hash mismatch are caused by manual installation on an unsupported OS. Separately from glibc, they are not the blocker.
Let me know if the conda option or the Anysphere extension helped. If not, please share the logs from the Remote - SSH output window and we can dig in further.