CALL FOR HELP! cursor agent timeout in ssh envs

Support Help
,
1

Where does the bug appear (feature/product)?

Cloud Agent (GitHub, Slack, Web, Linear)

Describe the Bug

cursor agent timeout in ssh envs, but works in local envs。

Logs:

The agent execution provider did not respond in time. This may indicate the extension host is not running or is unresponsive.

Steps to Reproduce

Yes. Each time when I use agent in ssh envs

Expected Behavior

response anwers

Operating System

Windows 10/11

Version Information

For cursor Agent: Send->Timeout

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

image
image358×220 8.3 KB

6

Solved！！！
Just revert version to 3.13. The issue has been introduced by version 3.15, maybe.

Waste about 4 hours to solve the problem. Call for rewards or cost-down.

REFERENCE
Remote-SSH agent fails: “agent execution provider did not respond in time” — remote extension host never activates the agent executor - Support / Bug Reports - Cursor - Community Forum

7

Similar issue here — Remote SSH broken after Cursor 3.15 on CentOS 7

We’re seeing the same class of failure on a production cPanel CentOS 7.9 host (kernel 3.10, glibc 2.17). Local Agent works; Remote-SSH does not stay up.

What happens

  • SSH connect succeeds, cursor-server starts fine
  • Remote Extension Host launches, then dies with SIGSEGV within a few seconds
  • Cursor reports: Remote Extension host terminated unexpectedly / reconnect loops (Unknown reconnection token)
  • That matches the “agent execution provider did not respond in time” symptom when the remote EH never stays alive long enough to activate the agent executor

Sandbox also fails on this OS (expected — no Landlock/bwrap), but that alone used to be non-fatal.

Evidence it’s a Cursor regression, not the server

Date Remote server commit Result
Aug 8 047548b… EH ran ~6 hours, clean exit (code 0)
Aug 11 a1f686… (Cursor 3.15.6) EH SIGSEGV repeatedly

Nothing meaningful changed on the host (same CentOS 7 box). Cursor auto-updated on the client and pulled the new linux-legacy-x64 server. Same crash after wiping/reinstalling /root/.cursor-server/bin.

Cursor CLI (agent) also won’t run on this host (GLIBC_2.25+ / newer libstdc++ required).

Agree with the 3.15 finding

Reverting to 3.13 (as you did) lines up with our logs: older remote build worked; 3.15 / a1f686 broke CentOS 7 / legacy glibc Remote-SSH.

Ask for Cursor

Please treat linux-legacy-x64 + CentOS 7 / glibc 2.17 as a regression in 3.15 and either fix the legacy EH binary or document that Remote-SSH on CentOS 7 is no longer supported.

Happy to provide full remoteagent.log / remoteexthost.log excerpts if useful.

9

Hey, thanks for the report, and it’s good you already found a workaround.

You’re right about the version. This is a known Remote-SSH issue after updating the client to 3.15.x. On older Linux remotes with legacy glibc like CentOS/RHEL 7, Debian 9, Amazon Linux 2, the remote extension host crashes during activation, so the SSH agent just hits a timeout even though everything works locally. This isn’t related to Cursor servers or your setup.

The workaround is to roll back the client to a version before 3.15. You rolled back to 3.13 and that works. In a nearby thread, users also confirmed 3.14.27 as the last stable one. Details and discussion here: Regression in Cursor 3.15.6: Remote SSH Extension Host crashes with SIGSEGV on Debian 9 (linux-legacy-x64)

We’re tracking this issue. I can’t share an exact timeline yet, but I’ll post in the thread as soon as there’s an update.

@designers-prescripti, your case (CentOS 7.9, glibc 2.17, SIGSEGV in the remote extension host) is the same class of issue. Thanks for the detailed breakdown with commits. If you can, please paste excerpts from remoteagent.log and remoteexthost.log here and I’ll pass them along. For now, the workaround is the same: roll back the client to 3.14.x.