Remote SSH Agent hangs: second extension host spawns with vscode.lock EEXIST despite cursor-agent-exec ready on exthost1

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Agent hangs indefinitely when used in a Remote SSH workspace on Linux. The remote extension host exthost1 successfully activates anysphere.cursor-agent-exec, but when an Agent request is sent, Cursor spawns a second extension host (exthost2) that fails to acquire the workspace lock (EEXIST). Agent never responds.

The same machine worked with Remote SSH Agent approximately one week ago. Current version: Cursor 3.19.13 (commit dd066f332fcea7382764400fde902f61920648d0).

Agent works normally in a local Windows window; the issue is specific to Remote SSH.

Environment
Component Details
Client OS
Windows 10/11
Client Cursor version
3.19.13 (commit dd066f332fcea7382764400fde902f61920648d0)
Remote OS
Rocky Linux (VirtualBox VM)
Connection
Remote-SSH (localhost / SSH config)
Remote server
~/.cursor-server/bin/linux-x64/dd066f332fcea7382764400fde902f61920648d0/
Workspace
Multi-root .code-workspace on remote

Network: Corporate proxy (Fortinet). curl to https://api2.cursor.sh succeeds from both Windows and the VM (direct and via proxy). This is not a connectivity/TLS issue.

VM RAM: Increased from ~618MB available to ~8GB available during troubleshooting. Issue persists.

Log evidence
exthost1 — agent executor ready (~30s after connect)
2026-09-08 22:04:18.492 [info] Extension host with pid 97010 started
2026-09-08 22:04:18.971 [info] ExtensionService#_doActivateExtension anysphere.cursor-agent-exec, startup: false, activationEvent: ‘*’
2026-09-08 22:04:50.174 [info] Extension activated success: anysphere.cursor-agent-exec — 29552ms
Agent request ~1 hour later — spawns exthost2 with lock conflict
2026-09-08 23:13:38.352 [info] Extension host with pid 104667 started
2026-09-08 23:13:38.352 [error] Error: EEXIST: file already exists, open ‘…/workspaceStorage/3bd4de76ba8255419884da936b28a8b6/vscode.lock’
Only 2 extension hosts in session; exthost2 appears only when Agent is invoked, not at initial connect.

Earlier session — same pattern across multiple hosts
Host cursor-agent-exec Outcome
exthost1
Success at 16:31:53
Killed by client at 16:32:25
exthost3
Started
Killed at 16:33:05 (~11s, before activation finished)
exthost4
Success at 16:34:09
EEXIST lock conflict
Windows client — extension host start timeout
Process participant start failed (id: extension-hosts, ms: 15001) Process start timed out (id: extension-hosts)
Remote cursor-agent-exec activation often takes 25–30 seconds, which may exceed the client’s 15 second extension-host startup timeout in some scenarios.

What we ruled out
HTTP proxy / Zscaler cert issues (curl to Cursor APIs works from client and VM)
Insufficient VM memory (issue persists with 8GB available)
Multiple Cursor windows / Agent-first UI (issue persists with single IDE window + Connect Current Window)
Stale ~/.cursor-server install (full wipe + reinstall did not fix)
Settings tried (no fix)
“remote.SSH.connectTimeout”: 120,
“remote.SSH.useExecServer”: false, // also tried true
“remote.SSH.localServerDownload”: “off”,
“http.proxy”: “http://grathad-proxy001.emea.nsn-net.net:8080”,
“http.proxySupport”: “override”,
“cursor.general.disableHttp2”: true
Also tried: deleting vscode.lock files, removing workspace storage for the workspace ID, pkill cursor-server, fresh rm -rf ~/.cursor-server.

Hypothesis
A recent Cursor release (observed on 3.19.13) appears to spawn a separate extension host for Agent requests on Remote SSH, while both hosts contend for the same workspaceStorage/…/vscode.lock. The ready agent executor on exthost1 is ignored. This may be a regression; Remote SSH Agent worked ~1 week ago on the same setup.

Steps to Reproduce

Open Cursor on Windows in IDE mode (single window).
Remote-SSH: Connect Current Window to Host → connect to Linux VM.
Open remote workspace; wait 30+ seconds after connect.
Send any Agent prompt (e.g. “Reply only with: WORKING”).
Observed: Agent hangs indefinitely (no response, no clear error in UI).

Expected Behavior

Agent should use the existing remote extension host (exthost1) where cursor-agent-exec is already activated, and respond normally.

Operating System

Windows 10/11

Version Information

Version: Cursor 3.19.13 · commit dd066f332fcea7382764400fde902f61920648d0
Category: Bug Report · Remote SSH · Agent

Does this stop you from using Cursor

Yes - Cursor is unusable

5

Hey @Alexandros_Adamos, thanks for the detailed report!

Two clarifications from our side:

  • the vscode.lock EEXIST line is expected and harmless (the new host simply falls back to a -1 storage folder)
  • the second extension host is not started by the Agent request itself. It appears when Cursor re-establishes the connection to the remote host (or when a second window, such as the Agents Window, connects to the same host) while the previous extension host is still shutting down. The problem is that the replacement host sometimes fails to activate the agent extension.

A workaround that has worked for others in this state:

  1. Close every Cursor window except for the IDE session connected to your remote machine.
  2. Open the Command Palette (Ctrl+Shift+P) and run "Remote-SSH: Kill Remote Server and Reload Window, pick your VM.
  3. Reconnect with a single IDE window
  4. Send a test prompt

Also let us know whether the Agents Window was open and connected to the same VM at the time. Thanks!

7

Hi Colin,

I did as you instructed, but no luck there :frowning: .

“Also let us know whether the Agents Window was open and connected to the same VM at the time.”

No, Agents Window is closed.

BR,

Alex.

11

Hi again Colin,

I am sending you also my settings:

{

“update.mode”: “none”,

“remote.SSH.connectTimeout”: 120,

“remote.SSH.useExecServer”: true,

“remote.SSH.remotePlatform”: {

“localhost”: “linux”

},

“cmake.showOptionsMovedNotification”: false,

“search.showLineNumbers”: true,

“remote.SSH.localServerDownload”: “off”,

“editor.renderWhitespace”: “all”,

“go.toolsManagement.autoUpdate”: true,

“jdk.jdkhome”: “c:\\< user >\\JAVA\\Oracle_JDK-23”,

“workbench.startupEditor”: “none”,

“terminal.integrated.enableMultiLinePasteWarning”: “auto”,

“editor.minimap.enabled”: false,

“security.workspace.trust.untrustedFiles”: “open”,

“github.copilot.nextEditSuggestions.enabled”: true,

“http.proxy”: “http://< our-proxy:port >”,

“http.proxySupport”: “override”,

“http.systemCertificates”: true,

“http.experimental.systemCertificatesv2”: true,

“cursor.general.disableHttp2”: true,

“http.proxyStrictSSL”: false,

“codeSight.telemetry.enablement”: false,

“[dockercompose]”: {

“editor.insertSpaces”: true,

“editor.tabSize”: 2,

“editor.autoIndent”: “advanced”,

“editor.quickSuggestions”: {

“other”: true,

“comments”: false,

“strings”: true

},

“editor.defaultFormatter”: “redhat.vscode-yaml”

},

“[github-actions-workflow]”: {

“editor.defaultFormatter”: “redhat.vscode-yaml”

},

“chat.agent.maxRequests”: 40,

“security.workspace.trust.enabled”: true,

“cursor.composer.usageSummaryDisplay”: “always”,

“remote.autoForwardPortsSource”: “hybrid”,

“editor.codeActionsOnSave”: {},

“editor.formatOnSaveMode”: “modificationsIfAvailable”,

“files.refactoring.autoSave”: false,

“workbench.colorTheme”: “Cursor Light”,

“window.systemColorTheme”: “auto”,

“git.openRepositoryInParentFolders”: “never”,

“window.autoDetectColorScheme”: true,

“cursor.composer.queueMessageDefaultBehavior”: “steer”,

“cursor.composer.editorConversationDensity”: “compact-ungrouped”

}

BR,

Alex.

15

Hey @Alexandros_Adamos, thanks for sending over your settings!

Quick check-in: it looks like you have since moved to Cursor 3.20.17, and from our side your Agent requests in the Remote SSH window have been completing normally since Friday. Are you still seeing the hang on your end?

16

Hi Colin,

I did a test and upgraded my VM to rocky9-8 and re-installed everything to work there.

That did solve my issue.

But, on that older rocky8 VM with the settings that I handed over, it’s still not working.

Anyway, I will mark the issue as solved because I’m able to work with the new setup.

Take care!

Alex.