Remote-SSH agent fails: "agent execution provider did not respond in time" — remote extension host never activates the agent executor

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Remote-SSH agent fails: “agent execution provider did not respond in time” — remote extension host never activates the agent executor

Summary

On a Remote-SSH workspace, every agent run fails with:

The agent execution provider did not respond in time. This may indicate
the extension host is not running or is unresponsive.
The SSH connection, server install, and remote extension host are all healthy
and fast. The local agent executor requests a remote execution provider, waits
exactly 30s, retries (30s + 5s + 5s) and gives up. On the remote side, the
extension host only ever activates vscode.git-base — the bundled
cursor-agent-exec / cursor-agent-worker / cursor-shadow-workspace
extensions exist on disk but are never activated. This reproduces 100% of the
time across clean reinstalls and multiple versions.

Environment

  • Local client: Cursor 3.7.21 (Windows 11, x64, 10.0.26100), VS Code API 1.105.1
  • Remote server commit: 517f696d8ab6c53eb04fbfdaae705cd146bf3460 (product version 3.7.21)
  • Remote OS: Ubuntu 20.04, kernel 5.4.0-48-generic, glibc 2.31, x86_64
  • The remote is a Kubernetes/minikube node (kubelet/docker running), bare VM (cgroup /init.scope, not inside a restrictive container)
  • Behind a corporate Fortinet proxy with a rotating IP (set via /etc/profile.d/proxy.sh). I added a no_proxy bypass for cursor.sh/cursor.com/cursorapi.com/cursor-cdn.com — no change.
  • Reproduced on server commits b887a26c (3.7.12), 80c653c2 (3.7.19) and 517f696d (3.7.21).

Error / Request IDs

  • f20ff677-2e05-43f3-8b05-6fdd2b36c23a
  • 712b68dd-57c7-4d4f-8f97-5024aaecb6dc
  • 833e06e2-e089-4a7e-a097-c675349686ba
  • 05c0585e-2c41-446f-98f1-f5d60bdab8ac

Smoking gun

Local renderer log (logs/<ts>/window1_wb1/renderer.log) — connection is fast
and healthy, then provider registration times out:
14:12:49 resolveAuthority(ssh-remote) returned ‘WebSocket(…)’ after 2009 ms 14:12:52 [MainThreadShellExec] $updateShellExecCapabilities: hostKind=3, expectedHost=3, isRemote=true, sandboxSupported=true 14:13:01 [ComposerWakelockManager] Acquired wakelock reason=“agent-loop” 14:13:31 [warning] [agent-exec] Provider registration timed out (attempt 1/3, timeout=30000ms), retrying 14:13:36 [warning] [agent-exec] Provider registration timed out (attempt 2/3, timeout=5000ms), retrying

Remote extension host log (~/.cursor-server/data/logs/<ts>/exthost1/remoteexthost.log)
— during the exact same window, the ONLY extension activated is git-base; there is
zero agent/worker/provider activity:
[info] ExtensionService#_doActivateExtension vscode.git-base, startup: true, activationEvent: ‘*’ [info] Extension activated success: vscode.git-base [info] Eager extensions activated

Remote bundled extensions present but never activated:
cursor-agent-exec cursor-agent-worker cursor-shadow-workspace cursor-browser-automation cursor-mcp cursor-retrieval …

So the remote executor extensions are installed but the remote extension host
never activates them, and the local agent-exec never receives a registered
remote provider → 30s timeout.

Also seen (possibly related) in local renderer log

[error] Unable to create workbench contribution ‘JXg’. Cannot register two commands with the same id: workbench.extensions.action.focusExtensionsView [error] … workbench.output.action.switchBetweenOutputs [error] … workbench.extensions.action.openExtensionsFolder

This happens even after a clean reinstall.

Things ruled out (already fixed/verified, problem persists)

  • inotify limits raised to 524288 / 1024 (original ENOSPC fixed)
  • Removed a perpetual ~108MB server re-download per connect (commit-dir mismatch);
    connect time went 206s → 2s — agent still times out
  • Corporate proxy bypassed for Cursor domains — no change
  • glibc / Node / disk / memory all well within requirements
  • Full clean reinstall of local client + full rm -rf ~/.cursor-server on remote
  • Tested with an empty remote folder (~/cursor-test) — same failure
  • Single-window, only the remote folder open — same failure

Repro

  1. Cursor 3.7.21 on Windows, Remote-SSH into Ubuntu 20.04 (kernel 5.4) k8s node.
  2. Open any remote folder.
  3. Start an agent request.
  4. Agent fails after ~40s with “agent execution provider did not respond in time”.
    Remote exthost log shows only git-base activated.

Ask

Why does the remote extension host activate only git-base and never activate
cursor-agent-exec/cursor-agent-worker on this host, causing remote agent
provider registration to time out? Is there a known incompatibility with kernel
5.4 / the sandbox helper / k8s-node environments, or a way to force-activate /
get diagnostic logs for the remote agent provider registration?

Steps to Reproduce

  1. Install Cursor 3.7.21 on Windows 11 (x64).
  2. Use Remote-SSH to connect to an Ubuntu 20.04 host (kernel 5.4.0-48-generic,
    glibc 2.31), which is also a Kubernetes/minikube node.
  3. Open any remote folder (reproduces even with a brand-new empty folder, and
    with a single window + all third-party extensions disabled).
  4. Send any agent request (e.g. “list the files in this directory”).
  5. After ~40s the agent fails with:
    “The agent execution provider did not respond in time. This may indicate the
    extension host is not running or is unresponsive.”
    • Local renderer log shows: [agent-exec] Provider registration timed out (attempt 1/3, timeout=30000ms) then 2 retries, then gives up.
    • Remote extension host log (~/.cursor-server/data/logs/<ts>/exthost1/ remoteexthost.log) shows ONLY vscode.git-base activates; the bundled
      cursor-agent-exec / cursor-agent-worker extensions are present on disk
      but never activate.
  6. Reproduces 100% of the time, across clean reinstalls of both the client and
    the remote ~/.cursor-server, and across server commits b887a26c (3.7.12),
    80c653c2 (3.7.19) and 517f696d (3.7.21).

Expected Behavior

On a healthy, fast Remote-SSH connection, starting an agent should activate the
remote agent execution provider (cursor-agent-exec / cursor-agent-worker) in
the remote extension host, register it with the local agent, and run the agent’s
tools against the remote workspace — instead of timing out after 30s because the
remote provider was never registered.

Operating System

Windows 10/11

Version Information

Version: 3.7.21 (user setup)
VS Code Extension API: 1.105.1
Commit: 517f696d8ab6c53eb04fbfdaae705cd146bf3460
Date: 2026-06-07T21:46:09.237Z
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.256
OS: Windows_NT x64 10.0.26100

Does this stop you from using Cursor

Yes - Cursor is unusable

7

Hi Minghe,

This is a known issue we’re actively tracking: on Remote-SSH, the agent’s execution provider can fail to register on the remote extension host, which produces the “agent execution provider did not respond in time” timeout. Your specific signature - only git-base activating on the remote while the bundled agent extensions never start - is a distinct and genuinely useful datapoint, so thank you for capturing it.

We don’t have a reliable fix for this exact Remote-SSH variant yet, but your logs point at the right place: cursor-agent-exec never activating on the remote is what leaves the local agent waiting until it times out. To pin down whether it’s failing to load versus never being scheduled to run remotely, could you share two things from the remote host?

  1. Whether ~/.cursor-server/<commit-hash>/extensions/cursor-agent-exec/ actually exists (where <commit-hash> matches the server commit, e.g. 517f696d...).
  2. Any lines mentioning cursor-agent-exec — including errors — from ~/.cursor-server/data/logs/<ts>/exthost1/remoteexthost.log, along with the surrounding Eager extensions activated block.

That tells us whether the extension is failing to load on this host (which can happen with certain kernel/library combinations) versus simply not being started, which directly informs the fix. I’ll keep this linked to our internal tracking and follow up as soon as there’s movement.

8

Thanks — checking those two things actually changed the diagnosis, and I also have a happy update: a Cursor update appears to have fixed it. Sharing both the findings and the confirmation.

## Answering your two questions

**1) Does the extension exist on the remote?**

Yes, fully present and intact:

`~/.cursor-server/bin/linux-x64/517f696d8ab6c53eb04fbfdaae705cd146bf3460/extensions/cursor-agent-exec/`

contains `dist/`, `patches/`, and `package.json` (`“activationEvents”: [“*”]`, `“main”: “./dist/main”`, no `extensionKind` field).

**2) Failing to load, or never scheduled? → Neither, exactly.**

cursor-agent-exec was NOT failing to load. When it WAS scheduled, it activated successfully:

11:54:34.030 _doActivateExtension anysphere.cursor-agent-exec, startup: true, activationEvent: ‘*’ 11:54:36.308 Extension activated success: anysphere.cursor-agent-exec — 2144ms 11:54:37.510 [ExtHostCursorExplorerProviderService] Main thread provider registration acknowledged

The real signature: the remote spawned MULTIPLE extension hosts per session in two flavors, and the agent extensions landed in the wrong (short-lived) one. In a single session I saw 5 hosts:

| host | lifetime | cursor-agent-exec activated? |

|------|----------|------------------------------|

| exthost1 | ~11.5 min | No — only vscode.git-base |

| exthost2 | ~5 sec | YES (2144ms) + provider acknowledged |

| exthost3 | ~5 min | YES + provider acknowledged |

| exthost4 | ~2.5 hr | No — only vscode.git-base |

| exthost5 | ~23 hr | No — only vscode.git-base |

The hosts that loaded the full Cursor set (incl. cursor-agent-exec) were torn down within seconds (“Extension host terminating: received terminate message from renderer”, exit 0). The LONG-LIVED host bound to my remote workspace (exthost1 → 4 → 5), i.e. the one alive when I actually run an agent, only ever activated git-base:

14:38:28.065 _doActivateExtension vscode.git-base, startup: true, activationEvent: ‘*’ 14:38:28.131 Eager extensions activated ← nothing else; no cursor-agent-exec

`grep cursor-agent-exec` over exthost1/4/5 logs → no matches at all.

So it loaded fine when scheduled, but was only ever scheduled into transient hosts that got terminated, while the persistent workspace host was provisioned with git-base only. The agent’s provider-registration request hit that git-base-only host and timed out after 30s (local renderer: `[agent-exec] Provider registration timed out (attempt 1/3, timeout=30000ms)`). This looked like an extension-orchestration / host-selection issue rather than a load failure or kernel/library incompatibility. Possibly related context: the remote renderer logged `[CursorExtensionIsolationService] Extension isolation gate is enabled, effective isolation is disabled (forced disabled in glass mode)`, and I run a multi-window / multi-root setup (a local empty-window agent host + the remote workspace window).

## Update: fixed after a Cursor update :white_check_mark:

After updating Cursor (remote server commit is now `e48ee6102a199492b0c9964699bf011886708ba0`), the agent works — it successfully created a hello-world program in a remote folder. The logs confirm the exact thing that was broken is now correct: the **long-lived** workspace extension host now activates `cursor-agent-exec` at startup (as the root cause that pulls in the rest), instead of only git-base:

07:57:44.562 _doActivateExtension anysphere.cursor-agent-exec, startup: true, activationEvent: ‘*’ 07:57:46.530 Extension activated success: anysphere.cursor-agent-exec — 1924ms 07:57:46.531 Eager extensions activated 07:57:46.531 _doActivateExtension anysphere.cursor-agent-worker, startup: false, activationEvent: ‘onStartupFinished’

Before vs after:

| | Old (517f696d) | After update (e48ee610) |

|—|—|—|

| Long-lived workspace host | git-base only | activates cursor-agent-exec (+ worker/mcp/retrieval) |

| Where agent-exec ran | only in hosts killed within seconds | in the host that lives for the whole session |

| Result | provider registration 30s timeout | agent runs normally |

So from my side this is resolved by the update. Thanks for the help tracking it down — hopefully the “which extension host gets the agent extensions” detail is useful for anyone still hitting the Remote-SSH variant on an older build. Environment for the record: client 3.7.21 → updated (Windows), remote Ubuntu 20.04 / kernel 5.4.0-48-generic / glibc 2.31, also a k8s/minikube node.