Failed to reconnect via SSH due to persistent "failed to create hard link" error

Bug Reports
1

Describe the Bug

When attempting to reconnect to a remote server using Cursor’s Remote SSH plugin after a previous disconnection, I consistently encounter the following error:

failed to create hard link
installing server: Couldn't install Cursor Server, install script returned non-zero exit status: Could not acquire lock after multiple attempts

The only workaround that reliably restores functionality is clicking “Reinstall Server”, which removes and reinstalls the Cursor server on the remote machine. However, this is not a sustainable solution for regular development workflows.

Steps to Reproduce

I’m sorry that this bug may only be reproducible on my server, but I’m glad to provide more specific information to locate this vulnerability. Below, I will provide the process when I encounter this bug

  1. Connect to a remote server using Cursor Remote SSH.

  2. Disconnect from the session (either manually or due to network issues).

  3. Attempt to reconnect to the same server.

  4. Observe the error regarding hard link creation and lock acquisition.

  5. Confirm that reconnect only works after using “Reinstall Server”.

Screenshots / Screen Recordings

屏幕截图 2025-06-28 142330.png
屏幕截图 2025-06-28 142330.png2879×1568 466 KB

Operating System

Windows 10/11
MacOS

Current Cursor Version (Menu → About Cursor → Copy)

Version: 1.1.6 (system setup)
Commit: 1.96.2
Date: 5b19bac7a947f54e4caa3eb7e4c5fbf832389850
Electron: 2025-06-25T02:20:02.577Z
ElectronBuildId: 34.5.1
Chromium: undefined
Node.js: 132.0.6834.210
V8: 20.19.0
OS: 13.2.152.41-electron.0

Additional Information

Remote Server OS: Ubuntu 22.04.3 LTS (GNU/Linux 6.8.0-52-generic x86_64)
Local Host OS: Windows 11 and macOS (issue reproduced on both platforms)

I noticed that even after manually removing the lock file, it reappears immediately.

Using inotifywait, I observed that the lock file is being frequently accessed and modified, even when no devices are actively using Cursor.

yunxiang@yunxiang-U2127:~$ ls -l --time=ctime /tmp/cursor-remote-lock.*
-rw-rw-r-- 1 yunxiang yunxiang 11 Jun 28 06:24 /tmp/cursor-remote-lock.759c0db80d0c1455e0ba48502758a0fd
-rw-rw-r-- 1 yunxiang yunxiang  0 Jun 28 06:22 /tmp/cursor-remote-lock.759c0db80d0c1455e0ba48502758a0fd.target
yunxiang@yunxiang-U2127:~$ rm -f /tmp/cursor-remote-lock.*
yunxiang@yunxiang-U2127:~$ ls -l --time=ctime /tmp/cursor-remote-lock.*
-rw-rw-r-- 1 yunxiang yunxiang 11 Jun 28 06:24 /tmp/cursor-remote-lock.759c0db80d0c1455e0ba48502758a0fd
yunxiang@yunxiang-U2127:~$ inotifywait -m /tmp -e open -e create -e delete -e modify
Setting up watches.
Watches established.
/tmp/ OPEN cursor-remote-lock.759c0db80d0c1455e0ba48502758a0fd
/tmp/ MODIFY cursor-remote-lock.759c0db80d0c1455e0ba48502758a0fd
/tmp/ MODIFY cursor-remote-lock.759c0db80d0c1455e0ba48502758a0fd
/tmp/ OPEN cursor-remote-lock.759c0db80d0c1455e0ba48502758a0fd
/tmp/ MODIFY cursor-remote-lock.759c0db80d0c1455e0ba48502758a0fd
/tmp/ MODIFY cursor-remote-lock.759c0db80d0c1455e0ba48502758a0fd
/tmp/ OPEN cursor-remote-lock.759c0db80d0c1455e0ba48502758a0fd
/tmp/ MODIFY cursor-remote-lock.759c0db80d0c1455e0ba48502758a0fd
/tmp/ MODIFY cursor-remote-lock.759c0db80d0c1455e0ba48502758a0fd
^C

This suggests a persistent background process may be holding or recreating the lock unexpectedly.

I suspect this may be related to using different Cursor versions across multiple devices that have previously connected to the same server. However, I confirm that when the error occurs, only one device is actively attempting a connection.

I found similar discussions in the forum and have already updated the Remote SSH plugin to the latest version(i.e 1.0.17) , but the issue persists.

Does this stop you from using Cursor

No - Cursor works, but with this issue

3

Hi @zf0827, thank you for this detailed bug report.

When initializing the remote server, we use a time-based lock, where we write to that lock file every second to indicate that the installation is still ongoing. It sounds like there might be a detached process that it still writing to that lockfile even after the installation finished (or was aborted), which is causing it to appear locked (and time out) on future installations. Could you try running killall bash to forcefully terminate the dangling processes?

For context, inside the setup script, we spawn a sub-shell that runs:

while true; do
    date +%s > "$lockfile"
    sleep 1
done &

We attempt to clean this subshell when the installation finishes (or errors), though it’s possible during errors that this subprocess is left behind. Running killall bash will terminate this dangling process.

4

Thank you so much for the quick fix! I really appreciate it.