Agent Execution Timed Out only when using SSH / Remote SSH on macOS

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor Agent fails with ERROR_EXTENSION_HOST_TIMEOUT / Agent Execution Timed Out [deadline_exceeded] when I use Cursor through SSH / Remote SSH.

Important detail: this only happens in SSH / Remote SSH workspaces. Local workspaces do not trigger this issue.

The Extension Host appears to start, and Cursor internal Agent extensions appear to activate according to exthost.log, but the Agent provider does not register successfully. The UI eventually shows:

ERROR_EXTENSION_HOST_TIMEOUT
Agent Execution Timed Out [deadline_exceeded]

The error message says:
“The agent execution provider did not respond in time. This may indicate the extension host is not running or is unresponsive.”

Steps to Reproduce

  1. Open Cursor on macOS.
  2. Connect to a remote machine using SSH / Remote SSH.
  3. Open a remote workspace through the SSH session.
  4. Open Cursor Agent / chat.
  5. Send any Agent request.
  6. Wait for the response.

Result:
Cursor shows ERROR_EXTENSION_HOST_TIMEOUT / Agent Execution Timed Out [deadline_exceeded].

This does not happen in a local workspace. The issue only appears when using SSH / Remote SSH.

Expected Behavior

Cursor Agent should work in SSH / Remote SSH workspaces the same way it works in local workspaces.

After the Extension Host starts, the Agent provider should register successfully and the Agent request should run normally without timing out.

Screenshots / Screen Recordings

iShot_2026-05-21_15.10.29.png
iShot_2026-05-21_15.10.29.png1236×1936 140 KB

Operating System

MacOS

Version Information

IDE:
Cursor IDE
Version: 3.5.17
VSCode Version: 1.105.1
Commit: d5b2fc092e16007956c9e5047f76097b9e626ca0
Date: 2026-05-20T02:43:31.559Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Darwin arm64 25.2.0

Install path:
/Users/apple/IDE/Cursor.app

Local system:
ProductName: macOS
ProductVersion: 26.2
BuildVersion: 25C56
Architecture: arm64
Device: MacBook Air
Shell: zsh

Remote/SSH:
This issue only happens in SSH / Remote SSH workspaces.
Local workspaces do not trigger this error.

For AI issues: which model did you use?

The issue happens before the model response starts. It is an Agent execution/provider registration timeout, so it does not appear to be model-specific.

I was using Cursor Agent. The selected model is not the main factor; the error occurs with:
ERROR_EXTENSION_HOST_TIMEOUT
Agent Execution Timed Out [deadline_exceeded]

For AI issues: add Request ID with privacy disabled

Request IDs:

cfe00ec1-d430-440e-a92d-bc595bfb104b
fec876d5-c4ff-4b30-a567-6370a9181450
38ac5894-9a1a-4cb2-bf0a-79fa6cbccb7c
a44e6259-7847-4872-a689-b83203eae44d

Additional Information

Important clarification:
This issue only occurs when using SSH / Remote SSH. Local workspaces do not trigger this error.

Relevant Extension Host log lines:

Extension host with pid 2258 started
ExtensionService#_doActivateExtension anysphere.cursor-agent-exec, startup: true, activationEvent: ‘*’
No bundle location found for extension anysphere.cursor-agent-exec
ExtensionService#_doActivateExtension anysphere.cursor-mcp, startup: false, activationEvent: ‘api’, root cause: anysphere.cursor-agent-exec
No bundle location found for extension anysphere.cursor-mcp
Extension activated success: anysphere.cursor-agent-exec
ExtensionService#_doActivateExtension anysphere.cursor-agent-worker, startup: false, activationEvent: ‘onStartupFinished’
ExtensionService#_doActivateExtension anysphere.cursor-socket, startup: false, activationEvent: ‘onStartupFinished’
No bundle location found for extension anysphere.cursor-agent-worker
No bundle location found for extension anysphere.cursor-socket
Extension activated success: anysphere.cursor-agent-worker
Extension activated success: anysphere.cursor-socket

The Extension Host appears to start and Cursor internal Agent extensions appear to activate, but the Agent provider still does not register successfully in the SSH / Remote SSH workspace.

Question:
Is Cursor Agent expected to work in SSH / Remote SSH workspaces? If yes, what remote-side components or logs should I check?

It would also be helpful if Cursor could provide a clearer diagnostic message for this case, because the current message says the extension host may not be running, while the logs suggest the extension host did start.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

5

Hey, thanks for the detailed report and logs. It really helps.

This is a known issue and we’re tracking it. The Agent should work over Remote SSH, but recently we’ve seen a spike of ERROR_EXTENSION_HOST_TIMEOUT specifically over SSH. The symptom matches what you’re seeing: the remote extension host starts, anysphere.cursor-agent-exec activates, but the RPC registration for the agent exec provider doesn’t finish back on the main thread before the timeout. The No bundle location found messages are about localization bundles and don’t affect the agent, so you can ignore them.

I can’t share an ETA for a fix yet.

A few things to try as workarounds:

  • Reload Window after connecting over SSH. Sometimes registration works on the second try.
  • Fully kill cursor-server on the remote and reconnect: pkill -f .cursor-server or rm -rf ~/.cursor-server for a clean start, then open the Remote SSH window again.
  • If you use SSH ControlMaster or multiplexing in ~/.ssh/config, try disabling it temporarily with ControlMaster no. We suspect multiplexing can sometimes delay RPC.
  • Check CPU load and free memory on the remote machine during startup. If the host is busy, activation might not finish within 40s.

Also, if you can share:

  • OS and architecture of the remote host Linux x86_64, ARM, etc.
  • Does it reproduce 100% of the time, or does it sometimes work?
  • Are you using SSH multiplexing, ProxyJump, or a VPN to reach the host?

I’ll link your thread to the existing issue. If I get an update, I’ll reply here.

7

Thanks for the clarification.

I have an update.

After running the following command on the remote machine:

rm -rf ~/.cursor-server

and then reconnecting with Remote SSH, Cursor Agent started working normally again.

So it looks like the issue may be related to the remote-side cursor-server state or installation.

However, the behavior is intermittent. It is not always permanently broken. Sometimes Agent works, and sometimes it fails again with:

ERROR_EXTENSION_HOST_TIMEOUT
Agent Execution Timed Out [deadline_exceeded]

Local workspaces continue to work normally. The issue only appears in SSH / Remote SSH workspaces.

Remote host information:

uname -a:
Linux zls–91e31c52c98f-v45duj7dvr 5.15.0-89-generic #99-Ubuntu SMP Mon Oct 30 20:42:41 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

uname -m:
x86_64

Shell:
/bin/bash

/etc/os-release:
PRETTY_NAME=“Ubuntu 24.04.2 LTS”
NAME=“Ubuntu”
VERSION_ID=“24.04”
VERSION=“24.04.2 LTS (Noble Numbat)”
VERSION_CODENAME=noble
ID=ubuntu
ID_LIKE=debian
UBUNTU_CODENAME=noble

SSH setup:
I checked my local ~/.ssh/config and I do not appear to be using SSH multiplexing. There is no ControlMaster, ControlPath, ControlPersist, ProxyJump, or ProxyCommand in the config.

VPN:
No VPN is used.

Reproducibility:
The issue is intermittent. It does not reproduce 100% of the time, but when it happens, it is specific to SSH / Remote SSH workspaces.

Workaround result:
Deleting ~/.cursor-server on the remote host and reconnecting fixes the issue temporarily.

This suggests that the remote cursor-server state may sometimes get into a bad state where the Agent exec provider RPC registration does not complete.

8

I am facing this same issue,

Reproducible 100% times

Deleted ~/.cursor-server ~/.cursor on remote, but still seeing this issue

~ → uname -a
Linux {abcd.com} 5.10.237-1.el8.{abcd}.x86_64 #1 SMP Tue Oct 28 17:57:33 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
01:48:25 garvit.bhateja@garvit-bhateja ~ → uname -r
5.10.237-1.el8.{abcd}.x86_64

9

What works for me:

Downgrade the remote-ssh extension to 1.0.49

Identifier

anysphere.remote-ssh

Version

1.0.49

10

@1Keria - thanks for the update. The intermittent, temporary fix by clearing ~/.cursor-server fits the hypothesis about a race condition while registering the agent exec provider RPC. Deleting the whole folder forces the server to reinstall cleanly, but if the race is still there, the issue comes back. I’ll pass this to tracking.

@Garvit_Bhateja - thanks for adding more data, especially about downgrading anysphere.remote-ssh to 1.0.49. That could be an important signal. Can you confirm:

  • What version of anysphere.remote-ssh were you on before the downgrade? Extensions panel → Remote SSH → Version
  • Your Cursor version: Help → About, and your macOS version on the client
  • If you have them, a couple of Request IDs from failures before the downgrade

Also, after switching back to 1.0.49, did the problem go away completely, or did it just happen less often? I’m trying to understand if the downgrade is a full fix or only a partial one.

I’ll add the updated info to the existing issue. I can’t share an ETA for a fix yet, but the extension downgrade workaround is a good lead for the investigation.

11

Thanks!
I tried downgrading anysphere.remote-ssh to 1.0.49, and it does fix the issue for me as well.

In some cases I still need to delete ~/.cursor-server and ~/.cursor on the remote machine, but overall this workaround works pretty well.

Looks like this might be a regression introduced after 1.0.49.

12

Thanks for confirming. Two independent reports on 1.0.49 is a strong signal and it really helps narrow things down. This looks like a regression that landed in anysphere.remote-ssh after 1.0.49. I’ll log it in the issue tracker.

The fact that rm -rf ~/.cursor-server (and sometimes ~/.cursor) is still needed even after downgrading is also an interesting detail. It looks like the cache can stay in a bad state even without the latest extension version. Good signal that the fix should include a cleanup path too.

I can’t share an ETA yet. For now, keep the workaround 1.0.49 plus clearing ~/.cursor-server or ~/.cursor if needed as a temporary solution. Once I have an update on the fix, or if we need you to test a build, I’ll reply here.

Also, if you hit a fresh failure after upgrading anysphere.remote-ssh again for comparison, please share the Request ID and the exact extension version where it reproduced. That’ll help pinpoint which update introduced the regression.

@Garvit_Bhateja if you have a minute, I’d still like to see the answers from my earlier message. The previous anysphere.remote-ssh version before the downgrade, your Cursor and macOS versions, and a couple of Request IDs from before the downgrade. That’ll really help with prioritization.

13

Extension Version before downgrade:

1.0.51

(Didnt try 1.0.50, as was also recently released, wanted stable release, so went direct to 1.0.49)

MacOS:

26.5 (25F71)

Cursor Details:

Version: 3.5.17

VSCode Version: 1.105.1

Commit: d5b2fc092e16007956c9e5047f76097b9e626ca0

Date: 2026-05-20T02:43:31.559Z (3 days ago)

Layout: editor

Build Type: Stable

Release Track: Default

Electron: 39.8.1

Chromium: 142.0.7444.265

Node.js: 22.22.1

V8: 14.2.231.22-electron.0

OS: Darwin arm64 25.5.0

I dont have the request IDs

14

I tried the same workaround as before — downgrading anysphere.remote-ssh to 1.0.49 and removing ~/.cursor-server / ~/.cursor on the remote machine — but Cursor Agent still doesn’t work over Remote SSH now.

The error is still:

ERROR_EXTENSION_HOST_TIMEOUT
Agent Execution Timed Out [deadline_exceeded]

Local workspaces still work normally.

Is there any update on this issue, or any new workaround/fix I can try?

15

Hey @1Keria thanks for coming back with an update. The fact that the 1.0.49 plus clearing ~/.cursor-server / ~/.cursor combo stopped working is an important signal. It looks like a new regression on top of the one we were already tracking.

To pass this to tracking with up to date data, can you please send:

  • Fresh Request IDs from the latest failures with Privacy Mode off. Chat menu in the top right > Copy Request ID.
  • Your current anysphere.remote-ssh version Extensions > Remote SSH > Version and your Cursor version Help > About.
  • Did Cursor or anysphere.remote-ssh update since the last time the workaround still worked?
  • Did anything change on the remote host load, environment, container? Last time you connected to the zls--... container. Is it the same host?

For now you can also try:

  • After clearing ~/.cursor-server and ~/.cursor, reinstall 1.0.49 from scratch. Fully uninstall the extension, then install exactly 1.0.49, then reopen the Remote SSH window.
  • Reload Window a couple times after connecting. Sometimes registration works on the second try.
  • Check CPU and memory on the remote host when the session starts. If the host is busy, activation might not finish before the timeout window.
16

Here is the latest info:

Request ID: 39e72e01-4991-4359-945c-7a99b11ccc52

Privacy Mode was off when I copied the Request ID.

Remote SSH extension version:
anysphere.remote-ssh 1.0.49

Cursor info:
Version: 3.6.31
VS Code Extension API: 1.105.1
Commit: 81fcf2931d7687b4ff3f3017858d0c6dee7e2a60
Date: 2026-05-31T17:46:29.630Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
xterm.js: 6.1.0-beta.220
OS: Darwin arm64 25.2.0

Additional details:

  • The Remote SSH extension has not been updated since the workaround last worked.
  • The remote host has changed. It is not the same host as before.
  • The remote host load was not very high when the issue happened.
17

Thanks for the fresh details, this is a helpful signal. The key point is that downgrading to 1.0.49 plus clearing the cache stopped helping after you updated Cursor to 3.6.31 and switched the remote host. So it looks like it’s not only the anysphere.remote-ssh version, the host environment likely matters too. I’ll log this in the tracker along with your Request ID.

To narrow this down, can you share a bit more about the new remote host:

  • Is it a regular VM or bare metal, or is it a container or chroot or jail-style environment like Docker, dev container, Coder, ISPConfig, etc.? This is often the key factor.
  • OS and architecture of the new host from uname -a.
  • Does this happen 100% of the time on the new host, or does the Agent sometimes start anyway?

In the meantime, you can try:

  • On the new host, completely remove ~/.cursor-server and ~/.cursor, then reopen the Remote SSH window from scratch.
  • After connecting, run Reload Window 1 or 2 times, sometimes registration works on the second attempt.
  • If the new host is in a container or jail, make sure the user can write to $HOME and that the cursor-server process isn’t getting killed by environment limits.

I can’t share an ETA for a fix yet, but I’ll post here as soon as I have an update.