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)
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.
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.
Same Agent Execution Timed Out on Remote-SSH with Cursor 3.15.6, but this is **not** the linux-legacy / old-glibc case.
**Impact:** SSH, file explorer, and the integrated terminal all work. Agent chat is completely unusable remotely. This is a severe UX break for remote Linux development.
**Remote (modern Ubuntu, not CentOS 7 / Debian 9)**
Ubuntu 22.04.5 LTS
kernel `5.15.0-173-generic`
glibc **2.35**
remote server artifact: **linux-x64** (not linux-legacy-x64)
local XFS `/home`, 1.5 TiB RAM, 224 CPUs
workspace: large Linux SDK (~14GB)
**remoteexthost.log**
`cursor-agent-exec` **never activates**
sandbox preflight fails (Landlock V3 / no `bwrap`), then `Sandbox support detected: false`
workspace lock already held (`vscode.lock` EEXIST)
~52s later: `Extension host terminating: received terminate message from renderer`, exit code 0
The local renderer kills the remote extension host because the agent execution provider never registers. This matches the 3.15.6 timeout, but it happens on current Ubuntu 22.04 / glibc 2.35 / linux-x64.
Please do not treat this as “old kernel only”. Workaround: downgrade local Cursor to **3.14.27** (`047548b00c1a079373d74d00183f32510a4a41e0`).
Hey @oula, thanks for the detailed report. The logs and the fact that you clearly separated your case from the old-kernel story really help.
You’re right, your case is different from what’s described in this thread. Here the root cause is tied to the linux-legacy-x64 build on an old glibc CentOS 7 or Debian 9. You’re on Ubuntu 22.04 with glibc 2.35 and the linux-x64 artifact, so it’s a different environment. This should be tracked separately even if the surface symptom looks the same Agent Execution Timed Out, cursor-agent-exec doesn’t activate, and the renderer sends terminate.
Your workaround is correct. Please stay on 3.14.27 until there’s an update.
So your case doesn’t get mixed with the legacy issue and can be tracked on its own, please open a separate thread for the linux-x64 glibc 2.35 variant. You can just move what you already wrote there. Also include the Request ID from the chat menu in the top right > Copy Request ID. If Privacy Mode is enabled, the ID might not be saved, then just say it’s enabled. A full remoteexthost.log from the remote host would also help.
Once you’ve created it, drop the link here and the team will pick it up.