Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
Bug Report: Agent unusable over Remote-SSH when the remote host has no outbound internet (new cursor_agent_host topology)
Request ID: 72503d9d-e46c-4e5d-8980-bda705b31e25
Where does the bug appear
Cursor IDE — Agent / Composer in a Remote-SSH window.
Summary
After the server-side cursor_agent_host feature gate was enabled on my account, Agent no longer works in Remote-SSH windows whose remote host has no outbound internet access. Ask/Chat, editing, terminal, and everything else in the remote window work normally.
This is a regression. The same setup worked on 2026-09-11. Nothing changed on my network or on the remote host.
Symptoms, in the order they appear:
- Agent sits at
Reconnecting… - Then
Connection failed - Finally:
Timed out waiting for the agent host bridge to register; please retry.
AgentTurnClassifiedError: Timed out waiting for the agent host bridge to register; please retry.
at Eoo (workbench.desktop.main.js)
at async FFo._waitForAgentHostBridgeBoundedInner
at async FFo._waitForAgentHostBridgeBounded
at async FFo._waitForPushRequestContextProviderRegistration
at async FFo.streamFromAgentBackend
at async FFo.getAgentStreamResponse
at async bDe._submitChatMaybeAbortCurrent
Environment
| Local OS | Windows 11 (10.0.22621) |
| Cursor | 3.20.21 (commit f09fca384ceca23f7bf21f9c23655b162641d740) |
| Also reproduced on | 3.20.10 (commit d6f462cdd0a6a6d1cff570daf980e671d0a63de0) |
| Remote | Linux x64, Anysphere Remote SSH 1.1.15 |
| Remote internet | None. No outbound access to the public internet. |
| Local internet | Working (Ask/Chat, auth, marketplace all fine) |
The remote cursor-server installs fine, because the Remote-SSH extension downloads it on the local machine and pushes it over SSH. Both builds are present on the remote:
~/.cursor-server/bin/linux-x64/d6f462cdd0a6a6d1cff570daf980e671d0a63de0
~/.cursor-server/bin/linux-x64/f09fca384ceca23f7bf21f9c23655b162641d740
So this report is not about server installation. It is only about where Agent’s network traffic egresses from.
Root cause analysis
1. The gate is enabled, and it is server-side only
Every window logs:
[CursorAgentHostEnablementService] cursor_agent_host gate is enabled, effective agent-host topology is enabled
From workbench.desktop.main.js, this comes from a Statsig gate with no user-facing override:
if (!Zc.localMode) try {
n = e.checkFeatureGate("cursor_agent_host", { disableExposureLog: false });
} catch (i) { /* ... */ }
this._agentHostEnabled = n;
The only bypass is localMode, which is a compile-time build flag and is hardcoded off in stable builds (buildFlags.js):
Qc = { extensionIsDev:!1, developmentTooling:!1, ..., localMode:!1 }
2. Under the new topology, agent-host runs on the remote and egresses from there
extensions/cursor-agent-host/package.json declares no extensionKind, so it defaults to workspace and runs in the remote extension host. Its own description confirms this: “Hosts Cursor agent orchestration in the AgentExec extension host.”
Its network platform is hardcoded with no alternative:
const zOe = "builtin";
// ...
`Created agent host and registered provider (network kind: ${zOe}, timeToBridgeRegisterMs: ...)`
and at startup it logs:
[agent-host] Builtin IDE network platform initialized
builtin means the agent host opens its own outbound connections from whatever process it is running in. In a Remote-SSH window that is the remote host. There appears to be no option to tunnel this traffic back through the local client.
3. This contradicts the current documentation
https://cursor.com/help/troubleshooting/network still states:
When using Cursor’s Remote SSH extension, AI features run on your local machine and communicate with the remote server for file access. […] AI requests go from your local machine to Cursor’s servers, not from the remote host.
That was true under the old cursor-agent-exec-only topology, and it is why my setup worked for months. It is no longer true for Agent once cursor_agent_host is enabled. The docs should be corrected regardless of how the rest of this report is handled.
Workarounds attempted (all fail)
cursor.general.disableHttp2 / HTTP Compatibility Mode → HTTP/1.1
Does switch the transport. The Cursor Agent Host Network (debug) channel confirms it:
[TransportFactory] Creating dynamic HTTP/1 transports with keepalive killswitch
But it is irrelevant here — the problem is no egress at all, not protocol incompatibility.
Side note / separate minor bug: I had both cursor.general.disableHttp2: true and cursor.general.disableHttp1SSE: true set. That combination leaves no usable streaming transport and silently keeps HTTP/2. Cursor should either warn or reject this combination in settings, since the two keys are individually documented as remedies.
Also confusing: the Cursor Agent Host Network (non-debug) channel prints
[HTTP/2 Ping] remote_agent_host_presence interval=10000 timeout=20000
[HTTP/2 Ping] background_composer_proxy interval=10000 timeout=20000
regardless of the selected transport, because getHttp2PingConfig() only resolves the Statsig http2_ping_config values and never consults isHttp2Disabled(). This strongly reads as “HTTP/2 is still in use” to anyone debugging a proxy problem. Please either gate that log on the effective transport or rename it.
remote.extensionKind override to force agent-host local
"remote.extensionKind": { "anysphere.cursor-agent-host": ["ui"] }
This hangs and then produces the AGENT_HOST_BRIDGE_TIMEOUT above, because the runtime backfills dependencies onto agent-host when the gate is on:
yp.equals(e.identifier, uYC) && this._cursorAgentHostEnabled &&
(n.add(_mc.value), n.add(bmc.value))
// uYC = anysphere.cursor-agent-host
// _mc = vscode.git
// bmc = anysphere.cursor-retrieval
Both dependencies are workspace-kind, so in a remote window they live on the remote side and are unreachable from the local host.
Working local window — dependencies resolve, activation completes:
ExtensionService#_doActivateExtension vscode.git-base, startup: true, activationEvent: '*', root cause: anysphere.cursor-agent-host
ExtensionService#_doActivateExtension vscode.git, startup: true, activationEvent: '*', root cause: anysphere.cursor-agent-host
ExtensionService#_doActivateExtension anysphere.cursor-retrieval, startup: true, activationEvent: '*', root cause: anysphere.cursor-agent-host
Extension activated success: anysphere.cursor-agent-host — 13312ms
Remote window with the override — no dependency activations, and no Extension activated success ever:
ExtensionService#_doActivateExtension anysphere.cursor-agent-host, startup: true, activationEvent: '*'
[ExtHostShellExec] Default shell changed: /bin/bash
ExtensionService#_doActivateExtension anysphere.cursor-always-local, startup: false, activationEvent: 'onStartupFinished'
(window closed ~64s later, still no success line)
Making this override viable would require also forcing vscode.git and anysphere.cursor-retrieval to ui, which would point git and codebase indexing at the local filesystem in a remote window — worse than the original problem.
Sub-request: an unsatisfiable remote.extensionKind override for agent-host should fail fast with an actionable message instead of hanging until the bridge-registration budget is exhausted.
Downgrade
Downgraded to 3.20.10 (the build that was current on 2026-09-11, the last day this worked). Does not help. 3.20.10 ships extensions/cursor-agent-host and the gate still evaluates to enabled:
version = 3.20.10
commit = d6f462cdd0a6a6d1cff570daf980e671d0a63de0
extensions/cursor-agent-host exists = True
[CursorAgentHostEnablementService] cursor_agent_host gate is enabled, effective agent-host topology is enabled
This confirms the trigger was the gate flipping server-side, not a client update — and that no client version in reach is a workable rollback target.
What I am asking for
- A supported way to keep agent network egress on the local client under Remote-SSH. For example a
network kindother thanbuiltinthat tunnels agent-host traffic through the local client, the way the pre-agent-host topology effectively did. - Failing that, a user setting to opt out of the agent-host topology, so Remote-SSH users with restricted remotes can stay on the previous behaviour.
- As an interim measure, please remove my account from the
cursor_agent_hostgate. Agent over Remote-SSH is currently unusable for me and there is no client-side workaround. - Correct the Remote-SSH section of https://cursor.com/help/troubleshooting/network.
- Smaller fixes noted inline above: the misleading
[HTTP/2 Ping]log, the silentdisableHttp2+disableHttp1SSEconflict, and the silent hang on an unsatisfiableremote.extensionKindoverride.
Does this stop you from using Cursor
Agent over Remote-SSH: yes, completely. Local workspaces are unaffected.
Steps to Reproduce
1.ssh connect to a server
2.agent window send anything
Operating System
Linux
Version Information
3.20.10 (system setup)
Does this stop you from using Cursor
Yes - Cursor is unusable