Agent Execution Timed Out / Remote Extension Host crash loop on Remote-SSH — regression in 3.15.6, fixed by downgrading to 3.14.27

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

After updating to Cursor 3.15.6, connecting to a Remote-SSH host repeatedly triggers:

“Remote Extension host terminated unexpectedly 3 times within the last 5 minutes.”
“Agent Execution Timed Out — The agent execution provider did not respond in time. This may indicate the extension host is not running or is unresponsive.”

Local editing and the integrated terminal work fine over the same Remote-SSH connection; only the Agent/Composer execution fails.

Checking remoteexthost.log on the remote host, the extension host is not crashing on its own — it exits cleanly (exit code 0) after receiving a terminate message from the renderer, which suggests the local client is not receiving a response in time and force-restarting it, rather than the extension host actually dying.

Steps to Reproduce

Update Cursor to 3.15.6 on Windows.
Connect to a Remote-SSH host running on an old kernel (CentOS 7 / kernel 3.10).
Open Agent/Composer and submit any request.
Observe repeated “Agent Execution Timed Out” and “Remote Extension host terminated unexpectedly” errors.

Expected Behavior

Agent/Composer should connect to the execution provider and respond normally over Remote-SSH, as it does in Cursor 3.14.27.

Already tried without fixing the issue (on 3.15.6)

Deleted ~/.cursor-server on the remote host and let it reinstall
Deleted local state.vscdb
Set “remote.SSH.connectTimeout”: 120 in settings.json
Confirmed remote disk is local xfs (not NFS/overlay), 89% used but not full
Confirmed sufficient remote memory (free -h: ~2.8G available)

Operating System

Windows 10/11

Version Information

Version: 3.15.6 (system setup)
VS Code Extension API: 1.128.0
Commit: a1f686545fd0ce8917bbd2449f733551a9bce420
Date: 2026-08-06T01:41:03.876Z
Layout: IDE
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.291
OS: Windows_NT x64 10.0.26200

Additional Information

Environment

  • Reproduced on two different local machines:
    • Windows_NT x64 10.0.26200
    • macOS
  • Reproduces on: Cursor 3.15.6 (both platforms)
  • Fixed by downgrading to: Cursor 3.14.27
  • Remote: CentOS 7-family, kernel 3.10.0-1127.19.1.el7.x86_64, xfs local disk (AWS EBS, /dev/xvda1), direct SSH connection (no VPN)
  • Remote falls back to the linux-legacy-x64 build due to the old kernel. Sandbox preflight fails (Landlock/user-namespace/bwrap unsupported on this kernel) but falls back to unsandboxed execution within milliseconds — this does not appear to be the cause of the timeout.

Workaround
Downgrading to Cursor 3.14.27 (2026-08-04 build) resolves the issue completely on the same remote host.

Does this stop you from using Cursor

Yes - Cursor is unusable

5

Hey, thanks for the detailed report. The environment info, logs, and what you already ruled out really help.

This is a known issue we’re tracking. On 3.15.x, remote hosts on older kernel or glibc, in your case CentOS 7 / kernel 3.10 where the server uses the linux-legacy-x64 build, can crash the remote extension host. That makes Agent or Composer time out, while local editing and the terminal keep working. The same behavior was reported on Debian 9 here: Regression in Cursor 3.15.6: Remote SSH Extension Host crashes with SIGSEGV on Debian 9 (linux-legacy-x64)

Your workaround is the right call. Stay on 3.14.27 until there’s an update. Everything you tried, wiping ~/.cursor-server, deleting state.vscdb, tweaking remote.SSH.connectTimeout, won’t help here. And you were right to rule out the sandbox preflight. It’s not related to this timeout.

I can’t share an exact timeline yet, but I’ll post in the thread as soon as we have an update. Thanks again for laying it all out so clearly.