Remote SSH handshake times out after 120s although manual SSH works

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Hi Cursor Team,

I’m reporting a Remote SSH connection issue.

Environment

  • Cursor Pro ($20/month)

  • Windows 11 x64

  • Ubuntu 22.04 VPS

  • Remote SSH

Issue

Manual SSH works correctly.

ssh <SSH_USER>@<VPS_IP>

I can log into the VPS immediately from Windows PowerShell using my configured SSH key.

However, Cursor Remote SSH consistently fails with the following error:

SSH connection timed out after 120s without receiving any data from the remote host

Earlier today Cursor successfully:

  • Connected via SSH

  • Installed the Cursor Server

  • Started the remote server

  • Detected Node.js v20.18.2

Later the connection terminated with ECONNRESET.

Since then, Cursor has never completed the Remote SSH handshake again.

Troubleshooting Already Performed

  • Restarted Windows

  • Restarted Cursor

  • Restarted the VPS

  • Reinstalled the Remote SSH extension

  • Deleted the local Cursor Remote SSH cache

  • Deleted ~/.cursor-server and allowed a fresh installation

  • Verified that manual SSH works correctly outside Cursor

Remote SSH Log

Cursor launches:

ssh -T -D ... bash --login -c bash

After exactly 120 seconds, it consistently fails with:

SSH connection timed out after 120s without receiving any data from the remote host

Steps to Reproduce

  1. Open Cursor IDE on Windows 11.

  2. Connect to an Ubuntu 22.04 VPS using Remote SSH.

  3. Cursor starts the remote installation.

  4. Wait approximately 120 seconds.

  5. Cursor fails with:

SSH connection timed out after 120s without receiving any data from the remote host
  1. Manual SSH using
ssh <SSH_USER>@<VPS_IP>

works immediately.

Expected Behavior

Cursor should successfully establish the Remote SSH connection, start the Cursor Server on the Ubuntu VPS, complete the handshake, and open the remote workspace successfully.

Operating System

Windows 10/11

Version Information

Version: 3.9.16 (User Setup)
VS Code Extension API: 1.105.1
Commit: 042b3c1a4c53f2c3808067f519fbfc67b72cad80
Date: 2026-06-27T06:41:01.941Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Windows_NT x64 10.0.26200

For AI Issues

N/A (Remote SSH issue)

Additional Information

  • Manual SSH succeeds immediately using the configured SSH key.

  • The VPS is reachable and fully interactive.

  • Cursor establishes the SSH transport and starts the remote installation.

  • The Cursor Server never completes the expected handshake.

  • The timeout consistently occurs after exactly 120 seconds.

  • The issue began after a VPS/network interruption and has persisted across Cursor restarts.

  • The same VPS is accessible from Windows PowerShell, confirming that standard SSH connectivity is functioning normally.

Could you please advise whether this is:

  • A known Remote SSH regression?

  • A Cursor Remote Server issue?

  • A known compatibility issue with the current Remote SSH implementation?

  • Or are there additional diagnostic logs that would help identify the root cause?

I’m happy to provide:

  • Full Remote SSH logs

  • Verbose SSH output (ssh -vvv)

  • Cursor logs

  • Remote Cursor Server logs

  • Any additional diagnostics required to help reproduce and resolve the issue.

Does this stop you from using Cursor?

No – Cursor works, but with this issue.

5

Hey, thanks for the detailed report. The pattern “worked once → ECONNRESET → no more handshakes, but manual ssh is OK” usually points to a stuck state on the VPS, not a network or auth issue. The handshake needs a clean channel from a fresh bash --login, and if something breaks it, the resolver hangs for exactly 120s.

Try these steps on the VPS:

  1. Kill a possible orphaned server process removing ~/.cursor-server won’t kill it if it’s still running:

    pkill -f cursor-server

    Or run ps aux | grep cursor and kill it manually. Then reconnect.

  2. Check that your shell init files ~/.bashrc, ~/.bash_profile, ~/.profile don’t print anything to stdout for non-interactive sessions. Any echo, banner, neofetch, fortune, conda banner, or motd breaks the JSON handshake and you get “received no data”. Wrap any output with this guard:

    case $- in *i*) ;; *) return;; esac

    Put it at the top of .bashrc so non-interactive sessions exit before any output.

  3. Check disk space and inode usage:

    df -h
df -i

These are the 3 most common causes of this timeout. If it still hangs after that, increase remote.SSH.connectTimeout and send the full log from Output → “Remote - SSH” so we can see exactly which step the handshake gets stuck on. Let me know how it goes.

6

I gathered some additional diagnostics on the VPS.

The Cursor server appears to start successfully, but the handshake still never completes.

Additional diagnostics:

• remoteagent.log reports:

Error getting extensions control manifest
Timeout getting extensions control

• remoteexthost.log reports:

Failed to resolve Linux sandbox backend
Landlock V3 filesystem restrictions not supported
Bubblewrap backend requested but no root-owned executable “bwrap” was found on PATH

Additional environment information:

• which bwrap returns no result (Bubblewrap is not installed).
• Ubuntu 22.04
• Kernel: 5.15.0-181-generic
• /sys/kernel/security/lsm includes:
lockdown, capability, landlock, yama, apparmor

The Cursor server processes remain running on the VPS, but the client still times out after exactly 120 seconds waiting for the Remote SSH handshake.

The extension host log reports that sandbox support is disabled after the failed detection, but the extension control manifest still times out.

Could these extension host diagnostics explain why the Remote SSH handshake never completes, or would you recommend collecting any additional logs to identify where the handshake is stalling?

I’m happy to provide the complete Remote SSH logs, remoteagent.log, remoteexthost.log, verbose SSH output (ssh -vvv), or run any additional diagnostic commands that would help identify the root cause.

7

Thanks for the logs, they narrow things down.

First about the sandbox messages. You can ignore them. Failed to resolve Linux sandbox backend, Landlock V3 not supported, and bwrap not found are non critical warnings. The server just disables sandboxing and keeps running, it does not affect the handshake. If you want to remove the noise, install it with sudo apt install bubblewrap, but it is not related to the timeout.

The most interesting part is here:

Error getting extensions control manifest
Timeout getting extensions control

Cursor Server starts, but it looks like it cannot reach an HTTPS endpoint it needs during init. The request hangs, the server never signals ready, and the client hits the 120s timeout. Manual ssh still works because it only uses port 22, but the server also needs outbound HTTPS from the VPS. This is a working hypothesis, not a confirmed diagnosis, so let’s verify.

Run this directly on the VPS:

curl -vI https://api2.cursor.sh
curl -vI https://marketplace.cursorapi.com

Per our docs, the host needs access to *.cursor.sh, cursor-cdn.com, and marketplace.cursorapi.com. If these requests hang or fail, it’s an egress issue firewall, provider security group, SSL inspection. You’ll need to allow outbound traffic to these domains, and if SSL inspection is in place, add them to the exceptions list.

If curl works fine, try disabling HTTP/2 in the remote session. In the remote window open Settings via Ctrl+Shift+,, search for HTTP/2, enable Disable HTTP/2, then restart Cursor.

Let me know what curl returns and whether the HTTP/2 toggle helped, and we’ll know where to dig next.