Remote SSH agents fail with ERROR_EXTENSION_HOST_TIMEOUT — cursor-agent-exec is installed but never activates

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Cursor agents no longer work in any Remote SSH workspace.

This previously worked correctly on the same Windows PC, Cursor installation, SSH account, and system.

Local Windows agents still work normally. Remote SSH itself also works: I can connect, browse and edit files, use the integrated terminal, and run Git commands.

However, every agent request in a Remote SSH window fails with:

ERROR_EXTENSION_HOST_TIMEOUT

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.

Agent Execution Timed Out [deadline_exceeded]
ConnectError: [deadline_exceeded] Agent Execution Timed Out

This affects both:

The regular Agent inside the Cursor IDE
The separate Agents Window

Even a trivial prompt such as:

Reply only with: WORKING

fails before the agent begins processing it.

Steps to Reproduce

Open Cursor on Windows.
Connect to the Linux Cluster system through Remote SSH.
Open any remote folder, including the remote home directory.
Confirm that the terminal and file explorer work.
Start a new Agent chat.

Send:

Reply only with: WORKING
Wait for the request.

The request fails with ERROR_EXTENSION_HOST_TIMEOUT.

The same failure occurs in both the normal IDE Agent and the separate Agents Window.

Expected Behavior

The agent execution provider should activate on the Remote SSH host and allow the Agent to work inside the connected remote workspace.

This previously worked correctly in the same environment.

Actual Behavior

The Remote SSH workspace connects successfully, but the Agent execution provider never registers.

Every Agent request times out before the Agent begins processing the prompt.

Operating System

Windows 10/11

Version Information

Version: 3.12.17 (user setup)
VS Code Extension API: 1.128.0
Commit: 0fb762053c34788bb7760d5673f8a6d4c8589d50
Date: 2026-07-17T02:53:53.006Z
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.256
OS: Windows_NT x64 10.0.19045

For AI issues: which model did you use?

Auto

For AI issues: add Request ID with privacy disabled

fc14eeb5-d654-4fba-9ecd-a926ca830aed

ERROR_EXTENSION_HOST_TIMEOUT

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

Agent Execution Timed Out [deadline_exceeded]
ConnectError: [deadline_exceeded] Agent Execution Timed Out

Additional Information

What works:
Local Windows agents
Remote SSH connection
Remote file explorer
Remote terminal
File editing
Git operations
Direct SSH from PowerShell

What fails:
IDE Agent in every Remote SSH workspace
Agents Window connected to the Remote SSH workspace
Agent from the remote home directory
Agent from the project directory
Trivial prompts requiring no file access or command execution
Troubleshooting already performed

I have already tried all of the following:

Restarted Cursor completely.
Confirmed that no Cursor update is available.
Tested with third-party extensions disabled.
Tested multiple remote folders.
Tested the remote home directory.
Tested the project directory.
Reinstalled ~/.cursor-server from scratch.
Tested a fixed login node instead of the cluster’s load-balanced hostname.
Confirmed that Cursor was connected to the intended fixed hostname.
Confirmed that Workspace Trust was already disabled.

Set the following local User setting:

“remote.SSH.showLoginTerminal”: false
Tested both the IDE Agent and Agents Window.
Confirmed that local agents continue to work.
Reproduced the failure with Privacy Mode disabled.

None of these steps resolved the problem.

Does this stop you from using Cursor

Yes - Cursor is unusable

5

Hey, thanks for the detailed report. The logs and repro steps really help.

This is a familiar class of issue. The remote extension host isn’t activating cursor-agent-exec, so the provider registration times out before the request ever reaches the backend. That’s why there’s nothing useful under the Request ID. It fails before the call happens. A similar issue used to be fixed by updating, but you’re already on the current stable 3.12.17, so this looks like a separate case specific to your cluster environment.

A couple things that will help narrow it down:

  1. On our side, there have been server changes over the last few days. Please do a full restart of Cursor today, fully quit the app, not just reload, then check if it still reproduces.

  2. If it still reproduces, please send the remote extension host log from the cluster:

    • path: ~/.cursor-server/data/logs/<latest date>/exthost*/ file remoteexthost.log
    • I’m looking for lines containing cursor-agent-exec, and the block around Eager extensions activated. I want to see whether cursor-agent-exec is being activated on the long-lived host for the whole session, or if it’s only git-base.

As a workaround while we investigate, the cursor-agent CLI on the remote host works independently of the extension host, so you can run the agent from there.

Let me know how it goes after the restart, and share the log, then we’ll know where to dig next.

6

Thanks for the response.

I fully quit Cursor, restarted the computer, reconnected, and reproduced the issue again.

I reviewed the latest remoteexthost.log. The extension host starts normally, the sandbox preflight succeeds, and the workspace lock is acquired. However, there are no lines mentioning:

  • cursor-agent-exec
  • Eager extensions activated
  • git-base

Developer: Show Running Extensions still shows cursor-socket, but cursor-agent-exec is absent.

I am not comfortable posting the unredacted cluster log publicly. So, I have attached a redacted version that preserves the relevant diagnostic content.
remoteexthost-latest-20260722-111023-redacted.txt (2.6 KB)

Does this confirm that cursor-agent-exec is not being activated on the long-lived remote extension host? Please let me know what additional diagnostic information or workaround you would recommend next.

7

Thanks, the log helped. Yep, it confirms the diagnosis: the remote extension host itself starts fine (startup, sandbox preflight, workspace lock are all OK), but cursor-agent-exec never activates there. That’s why you don’t see any cursor-agent-exec / Eager extensions activated / git-base lines, and why Running Extensions shows cursor-socket but not cursor-agent-exec. The provider isn’t registering under the ssh-remote authority, so the request times out before it even reaches the backend, and there’s nothing under the Request ID.

Since this reproduces after a full restart and a reboot today too, meaning after the recent server changes, it’s likely specific to your cluster environment, not a general regression. This is a familiar class of issues, I’ll report it internally with your logs. I can’t give an ETA for a fix yet.

To narrow down what’s happening on your cluster, two things would help:

  1. On the remote host, do you have the anysphere.cursor-agent-exec folder under ~/.cursor-server/extensions/? This helps tell apart extension installed but not activating vs not making it to the remote or resolving to the wrong extension kind.
  2. The log from the local window, not the remote one. I need the lines around provider registration, especially [agent-exec] Provider registration timed out (attempt X/9) and any extension activation errors.

Workaround for now: the cursor-agent CLI on the remote host works independently of the extension host, so you can run the agent from there.

Send those two items and we’ll figure out where to dig next.

9

Also experiencing this exact issue. Have chatted with Cursor support and they advised me to watch this thread.

11

Hey @Shahar_Katz,

There have been some changes in this area since your report. The latest Cursor release includes a fix for the case where the agent execution provider doesn’t start in Remote SSH windows. Can you check again? Quick check:

  1. Update Cursor to the latest version (you were on 3.12.17).
  2. Connect to the cluster via Remote SSH and open a remote folder.
  3. Start a new Agent chat and send a trivial prompt like “Reply only with: WORKING”.

Let me know if requests are still timing out. If they are, the two diagnostic items from my message above will help us dig deeper: check the anysphere.cursor-agent-exec folder under ~/.cursor-server/extensions/, and grab logs from the local window with lines around [agent-exec] Provider registration timed out (attempt X/9).

For testing: the cursor-agent CLI on the remote host works independently of the extension host, so you can run the agent from there.

cc @mgwhg