Remote SSH: Segmentation fault (SEGV_PKUERR) on CPUs without PKU support

[xnkl-ck (qinxiaoyu)]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Bug Description

Cursor Server crashes with SIGSEGV (SEGV_PKUERR) immediately after startup when connecting to a remote Linux host via SSH. The crash occurs when the V8 JIT compiler loads the @vscode/spdlog native module on a CPU that does not support Intel Memory Protection Keys (PKU/MPK).

Environment

• Cursor CLI Version: 2026.01.17-d239e66
• Local OS: Windows 10 (10.0.19045)
• Remote OS: Ubuntu 22.04.5 LTS (kernel 5.15.0-143-generic)
• Remote glibc: 2.35 (fully compatible)
• Remote arch: x86_64
• Cursor Server commit: eb1c4e0702d201d1226d2a7afb25c501c2e56080
• Bundled Node.js: v20.18.2
• CPU PKU support: No (grep pku /proc/cpuinfo returns empty)
• Remote SSH extension: anysphere.remote-ssh-1.0.46

Crash Log (strace)

The crash happens right after loading @vscode/spdlog:

Steps to Reproduce

1. Set up SSH config for a remote Linux host (Ubuntu 22.04, x86_64, CPU without PKU support)
2. In Cursor, connect to this remote host via Remote SSH
3. Wait for Cursor Server to download and install (~89MB)
4. Cursor Server starts, binds to a port, then immediately crashes with “Segmentation fault (core dumped)”
5. Cursor shows error: “Couldn’t install Cursor Server, install script returned non-zero exit status: Code server did not start successfully”

Workaround: Adding export NODE_OPTIONS="--no-node-snapshot --jitless" to the cursor-server startup script (~/.cursor-server/bin/linux-x64//bin/cursor-server) before the last line resolves the crash.

Note: Setting NODE_OPTIONS in ~/.bashrc does NOT work because cursor-server is launched as a background process and does not inherit the shell environment.

Expected Behavior

Cursor Server should start normally and establish Remote SSH connection without crashing. The V8 engine should detect CPU capabilities and gracefully fall back when PKU (Memory Protection Keys) is not supported by the CPU.

Screenshots / Screen Recordings

Operating System

Windows 10/11

Version Information

CLI Version 2026.01.17-d239e66

For AI issues: which model did you use?

N/A - This is not an AI issue

For AI issues: add Request ID with privacy disabled

N/A

Additional Information

Root cause confirmed via strace: V8 JIT compiler triggers SEGV_PKUERR when loading @vscode/spdlog native module on a CPU without Intel PKU support.

Key evidence:

• strace shows: SIGSEGV {si_code=SEGV_PKUERR} right after loading spdlog
• grep pku /proc/cpuinfo returns empty (CPU has no PKU)
• –jitless flag completely fixes the crash (confirms V8 JIT is the cause)
• –no-node-snapshot alone does NOT fix it
• All libraries are present (ldd shows no missing deps)
• No LD_PRELOAD, no GPU drivers, glibc 2.35 is compatible
• Multiple users on the same server are affected (found another user’s core dump from Dec 2025)

Suggested fix: Detect PKU support at runtime and disable PKU code paths when unsupported, or provide a way to pass NODE_OPTIONS to the remote cursor-server process via settings.

Does this stop you from using Cursor

Yes - Cursor is unusable

[deanrie]

Hey, this is a really helpful bug report.

This is a confirmed issue on our side. The startup script for the remote cursor-server should detect the CPU features and handle missing PKU support correctly. I’ve shared this with the team.

One note about the current workaround: --jitless fully disables the V8 JIT compiler, which can noticeably slow down cursor-server since it runs in interpreter-only mode. It works, but you might see higher latency.

In the end we need a proper fix, either runtime PKU detection in the startup script, or a way to pass environment variables into the remote server process. I’ve flagged both options internally.

Let me know if you run into anything else.

[xnkl-ck (qinxiaoyu)]

Hi Dean,

Thanks for the quick response and confirmation! Really glad to hear this has been flagged internally.

A few additional data points that might help:

1. Multiple users affected: At least 2 users on the same server (found another user’s core dump from December 2025), so this has been a long-standing issue.

2. CPU info: The server CPU does not have PKU in its feature flags (grep pku /proc/cpuinfo returns empty). I can provide the full cat /proc/cpuinfo | grep "model name" output if that helps narrow down affected CPU models.

3. Regarding the workaround: Yes, --jitless does add noticeable latency, especially during extension loading. It would be great if the fix could either:

   • Auto-detect PKU support and disable it gracefully (preferred)
   • Or allow passing NODE_OPTIONS via Cursor settings (e.g. remote.SSH.nodeOptions) so users don’t have to manually edit the startup script after every update

4. Current pain point: Every time Cursor updates and re-downloads the server, the manual fix is overwritten. A settings-based approach would survive updates.

In the meantime, I’ve documented the workaround for our team. Happy to test any pre-release fix if you need feedback from an affected environment.

Thanks again for looking into this!