Remote-SSH broken on CentOS 7 (glibc 2.17) since 3.15.x — no linux-legacy server artifact, extension host SIGSEGV loop

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Remote-SSH to a CentOS 7 host (glibc 2.17) worked reliably through 3.14.7 and broke on 3.15.19. The server install log reports that no legacy artifact exists for the new commit and falls back to the regular package:

Legacy glibc detected but no linux-legacy server artifact was found for this commit; keeping the regular package
The server then starts, but the extension host segfaults repeatedly and the file watcher aborts:

[File Watcher (universal)] restarting watcher after unexpected error: terminated by itself with code null, signal: SIGABRT (ETERM)
[File Watcher (universal)] gave up attempting to restart watcher
[ExtensionHostConnection] <32412> Extension Host Process exited with code: null, signal: SIGSEGV
[ExtensionHostConnection] <32531> Extension Host Process exited with code: null, signal: SIGSEGV
[ExtensionHostConnection] <32641> Extension Host Process exited with code: null, signal: SIGSEGV
UI shows: “Remote Extension host terminated unexpectedly 3 times within the last 5 minutes.”

Notably, node itself runs fine on the host (v20.18.1 from the 3.15.19 server bundle executes and reports its version), so this is not a loader/link failure — it looks like a native module compiled against a newer toolchain crashing at runtime.

Steps to Reproduce

Remote-SSH from Cursor 3.15.19 to a CentOS 7 host (glibc 2.17, kernel 3.10)
Server downloads/installs, extension host launches
Extension host segfaults within seconds, repeatedly

Expected Behavior

Working vs broken

Version Server commit Result
3.14.7
a758f2241ca99fecf380180b6cbdbbce0f1f42cf
Works
3.15.19
de07bee81cefe43461ebf4f40c3d2d78d15052aa
SIGSEGV loop
Versions 3.7.42, 3.8.24, 3.9.16, 3.10.20 and 3.14.7 all worked on the same host.

Already tried

Developer: Reload With Extensions Disabled — still crashes
A custom glibc-2.17 Node build is present on the host and was sufficient prior to 3.15.x
Workaround Downgrade the client to 3.14.7 and disable auto-update.

Request Please restore the linux-legacy server artifact for the 3.15.x line, or document the minimum supported glibc so affected users can plan.

Operating System

Windows 10/11

Version Information

Environment

Client: Cursor 3.15.19, Windows 11 x64
Remote: CentOS Linux 7 (Core), kernel 3.10.0-1062.el7.x86_64, glibc 2.17, x86_64

Does this stop you from using Cursor

Yes - Cursor is unusable

7

Hey there! Stay on Cursor 3.14.x with auto-update off for now. That is the working setup for CentOS 7 / glibc 2.17 hosts on 3.15.x.

The extension host crash isn’t something you misconfigured. We’ve let the team know and this is an issue we’re tracking, same as this thread. No timeline yet, but I’ll post here when there’s an update.

One clarification: the linux-legacy server package is published for 3.15.19. Your install log saying it wasn’t found is a host-side check failing open (often TLS inspection / egress filtering on the box). Even a successful legacy download still hits the same crash on 3.15.x, so pinning 3.14.x remains the right move. If you can share the full Remote - SSH output log (View > Output → “Remote - SSH”), I can look at why that check failed.

Regular remote needs glibc 2.28+; 2.17–2.27 is meant to use the legacy server automatically. I’ll pass along the ask to document that publicly.