Remote SSH setup hangs on system-wide ps scan and holds installation lock on shared Linux host

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

On a shared Linux login node at NERSC Perlmutter, Remote SSH authentication succeeds, but Cursor server setup stalls after Checking node executable and the successful v24.18.1 output. Later attempts fail with Could not acquire lock after multiple attempts.

The installer was waiting for a ps pipeline. The ps process had STAT D and WCHAN access_remote_vm; its open file descriptor pointed to /proc/<other-user-PID>/cmdline. The target process belonged to another account. This blocked read is a host/kernel condition whose underlying cause is still unknown; the extension is affected because setup scans arguments system-wide while holding its installation lock.

Inspecting the generated setup template in anysphere.remote-ssh 1.1.16 found 2 uses of ps ax during build cleanup and 8 uses of ps -o pid,args -A for server discovery/reuse and related operations. One unrelated process can therefore block setup and subsequent retries.

Steps to Reproduce

Observed on October 14, 2026:

  1. Connect with Remote-SSH to a shared Linux login node where reading one unrelated user’s /proc/PID/cmdline blocks.
  2. Authentication succeeds and the installed server’s Node executable prints its version.
  3. Setup’s system-wide ps scan blocks in access_remote_vm.
  4. Retry the connection; the earlier setup process retains the installation lock and retries fail to acquire it.

This requires the abnormal host condition; I do not have a portable way to create it on a healthy machine. While diagnosing the affected node (procps 3.3.17), these checks were performed:

pids=$(ps -u "$USER" -o pid= | tr -d " " | paste -sd, -)

timeout -k 2s 5s ps -u "$USER" -o pid,args >/dev/null
# exit 137

timeout -k 2s 5s ps -p "$pids" -o pid,args >/dev/null
# exit 124; ps reported signal 15 and ps/display.c:70

timeout -k 2s 5s ps -q "$pids" -o pid,args >/dev/null
# exit 0

The -u and -p output filters did not avoid the blocked read on this system. GNU ps quick mode (-q) restricted reads to the specified PIDs and completed.

Expected Behavior

For a server installed in the connecting user’s home directory, process discovery should inspect only the relevant user’s PIDs or known server PIDs, avoiding unrelated users’ command-line reads. On GNU/Linux, collecting PIDs without arguments and then using ps -q is one tested approach.

If discovery blocks or fails, setup should stop within a bounded time, release the installation lock, and report which operation failed. Failed scans should not be treated as proof that no server is running during build cleanup.

Operating System

MacOS

Version Information

Cursor IDE: 3.24.12
Commit: 37b865941ccb31e2fc90c685157534efca87f960
Build date: 2026-10-09T20:56:41.904Z
Extension: anysphere.remote-ssh 1.1.16
Client: macOS 26.3, arm64
Remote: GNU/Linux x64, NERSC Perlmutter login node
Remote ps: procps 3.3.17
Bundled server Node: v24.18.1

Additional Information

A local workaround was applied to the extension’s Bash setup template by replacing the 10 scans with a helper. On GNU/Linux it collects only the connecting user’s PIDs without arguments, then uses quick PID mode:

pids=$(ps -u "$(id -u)" -o pid= | tr -d "[:blank:]" | paste -sd, -)
if [ -n "$pids" ]; then
    ps -q "$pids" -o pid,args -ww
fi

The patched helper is scoped locally to NERSC’s Linux environment; other hosts retain the original command. JavaScript and Bash syntax checks passed, and the remote quick-PID diagnostic returned 0. A full Cursor reconnect has not yet been verified in this investigation.

NERSC support has separately been notified about the underlying blocked command-line read. The request here is to make Remote SSH setup resilient to unrelated processes on shared hosts. Other platforms need their appropriate process-discovery implementation.

Impact: Cursor remote development is blocked on the affected login node; local use remains available.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

7

Hey @isaachyw, thanks for the detailed report and the diagnostics.

You’re right about how this happens. The server setup step lists processes system-wide while it holds the install lock. When that listing gets stuck, the setup shell stays alive. Later connection attempts see a lock owner that is still running and won’t take the lock over, so every retry ends with “Could not acquire lock after multiple attempts”. I’ve passed this to the team, including your quick-PID approach and the point about cleanup treating a failed scan as “nothing running”.

Until there’s a fix, this should get you unstuck on the affected node:

  1. Open a regular terminal and ssh to the same login node.
  2. In Cursor, open the Output panel, pick “Remote - SSH”, and find the line Locking <path>/cursor-remote-lock.<hash>.
  3. Run cat <that path> and note the owner_pid= value.
  4. Run ps -u "$USER" -o pid,ppid,stat,etime,comm (leaving out args avoids reading other users’ command lines). Find that owner PID and any ps process whose parent it is.
  5. kill -9 those PIDs, then rm -f <that path> <that path>.target*.

After that, a new connection can take the lock. It will hang again on a node where the blocked read is still present, so if your site lets you SSH to a specific login node, point a separate Host entry at one where timeout 5 ps -o pid,args -A >/dev/null returns 0. Your locally patched script also works, but extension updates will replace it, so keep a copy.

If you get a chance to try a full reconnect with your patch, I’d like to know whether it got all the way through.