Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
Cursor Remote-SSH repeatedly disconnects/reconnects on dev server; multiplex server leaks zombie node processes and breaks Agent sessions
Steps to Reproduce
Title:
Cursor Remote-SSH repeatedly disconnects/reconnects on dev server; multiplex server leaks zombie node processes and breaks Agent sessions
Cursor Version:
Version: 3.4.16 initially, later auto-updated to commit 93e603f703cd553a6bb3644711a3379bbbb31180
VSCode Version: 1.105.1
OS: macOS Darwin arm64 25.0.0
Remote OS: Linux x86_64
Summary:
Remote-SSH to my dev server repeatedly disconnects and enters “Opening Remote-SSH…” / “Attempting to connect…” loops. This happens many times per day and frequently breaks active Agent conversations. Regular SSH remains available, but Cursor’s remote extension host / management WebSocket gets stuck.
Impact:
This makes Remote-SSH + Agent nearly unusable for long-running work. Active Agent conversations often need reload/new window and lose state.
Observed Today:
- Around 10 disconnect/reconnect events in one day.
- Server restart intervals observed: about 9-50 minutes, with one longer stable interval when there was continuous activity.
- Zombie node processes accumulated from 0 to ~30 over the day.
- Multiple Remote-SSH windows end up stuck in “Opening Remote-SSH”.
- New windows often reuse the same half-broken remote server/multiplex instance and fail the same way.
Key Evidence:
-
Remote server runs Cursor 3.x multiplex mode:
~/.cursor-server/bin/multiplex-server/…js
~/.cursor-server/bin/linux-x64//bin/cursor-server --start-server … -
multiplex log repeatedly shows:
Server received connection
[command][…] Executing command: echo 1
[command][…] Process exited with code 0. Sending exit message
[remoteServer][…] Socket closed; killing child process
[remoteServer][…] Failed to kill child process -
Remote has many zombie node processes:
[node]
These accumulate after disconnects/reconnects. -
Renderer logs show repeated WebSocket handshake failures:
[remote-connection][Management][…][WebSocket(127.0.0.1:)] the handshake timed out
Error: Time limit reachedAlso:
WebSocket close with status code 1006
Error received from starting extension host (kind: Remote) -
Remote-SSH log shows /version and multiplex echo often succeed:
Successfully connected to Cursor server at http://127.0.0.1:/version
Successfully ran ‘echo 1’ against the multiplex serverBut the actual Management / ExtensionHost WebSocket handshake still times out.
-
remoteagent.log repeatedly shows stale RPC replies:
RequestStore#acceptReply was called without receiving a matching request -
On one occasion, Cursor auto-updated from commit f736016… to 93e603…, which forced remote server reinstall and dropped the Agent session.
Current local mitigations already tried:
- Disabled auto forwarded ports:
remote.autoForwardPorts=false
remote.restoreForwardedPorts=false - Disabled auto update:
update.mode=manual
update.enableWindowsBackgroundUpdates=false
extensions.autoUpdate=false
extensions.autoCheckUpdates=false - Tried:
remote.SSH.useExecServer=false
remote.SSH.useFlock=true
remote.SSH.connectTimeout=60 - SSH keepalive:
ServerAliveInterval 20
ServerAliveCountMax 6
TCPKeepAlive yes - Removed SSH ControlMaster because it may reuse bad tunnels.
- Added .ignore to remote workspace to suppress rg --files --hidden --follow scanning large symlink-heavy workspace.
Important finding:
Even with remote.SSH.useExecServer=false, Cursor still starts multiplex-server on the remote. It appears Cursor 3.x Remote-SSH still uses multiplex mode regardless of this setting.
What seems broken:
- Remote multiplex-server can become half-broken after SSH disconnects.
- It continues to be reused by new windows.
- It fails to clean child processes, leaving zombie node processes.
- Cursor frontend can pass /version and echo health checks but still fail Management / ExtensionHost WebSocket handshake.
- New windows reuse stale remote server/multiplex state and get stuck.
Expected behavior:
- If /version succeeds but WebSocket handshake fails repeatedly, Cursor should detect the remote server/multiplex instance as unhealthy and restart it cleanly.
- New windows should not reuse a half-broken multiplex server.
- Remote-SSH should not require manual pkill / rm / reload loops.
- Agent sessions should survive short SSH reconnects, or at least fail gracefully without corrupting reconnect state.
Actual behavior:
- Cursor keeps reusing half-broken multiplex/code server state.
- Windows get stuck in Opening Remote-SSH or Attempting to connect.
- Agent sessions are interrupted or lost.
- Manual cleanup is required repeatedly:
pkill local ssh -T -D tunnel
pkill remote ~/.cursor-server processes
rm /tmp/cursor-remote-*
sometimes move ~/.cursor-server and reinstall
Request:
Please investigate Cursor 3.x Remote-SSH multiplex-server reconnect behavior, child process cleanup, and stale reconnect-token/session handling. This is severely impacting Remote-SSH + Agent workflows.
Operating System
MacOS
Linux
Version Information
Version: 3.4.16 initially, later auto-updated to commit 93e603f703cd553a6bb3644711a3379bbbb31180
VSCode Version: 1.105.1
OS: macOS Darwin arm64 25.0.0
Remote OS: Linux x86_64
Does this stop you from using Cursor
Sometimes - I can sometimes use Cursor