Remote-SSH: Chat freezes, Extension host UNRESPONSIVE, ComposerCapability errors, no response

[Aleksandr_Pasynkov (Александр Пасынков)]

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

When using Cursor with Remote-SSH (host: Linux VM), the chat/composer window often:

• Does not return AI responses (or they arrive after very long delay)
• Shows “Planning next moves” or “Reconnecting…” without completing
• Becomes very slow or unresponsive (dialog window freezes)
• Chat history sometimes does not appear or update

Cursor Network Diagnostic in the same window shows all checks Success (DNS, SSL, API, Chat, Agent, Marketplace, etc.), so basic connectivity is OK. The problem appears to be extension host and composer lifecycle, not raw network.

Console errors (Help → Toggle Developer Tools → Console)

• [composer] Extension host became UNRESPONSIVE (with extensionHostKind: 'Remote') — happens repeatedly
• [composer] No first token received within 4s / 6s / 8s / … 32s — first token of AI response never arrives in time
• [ComposerCapability] Composer task … is not loaded. Are you obtaining a handle to the composer during its disposal? — many times (278+ errors), suggests code accessing composer after it is disposed
• [transport] No handler found for server message of type abort
• [transport] Stream error … ConnectError: [deadline_exceeded]
• PluginsProviderService very slow: getPluginMcpServers / getPluginCommands / getPluginHooks take 2.5–15+ seconds
• WARN [ExtensionService] No inspect port found for Remote

(Optional: I can attach a screenshot of the Console with these errors.)

Environment

• OS: Windows 10 (host), Linux (remote VM, SSH)
• Cursor version: 2.5.20
• Arch: x64, platform: win32, channel: stable
• Mode: Remote-SSH (single host)
• Setup: HTTPS_PROXY on VM (SOCKS via SSH RemoteForward 1080) so that API traffic goes through the host PC; curl from VM to api2.cursor.sh / marketplace.cursorapi.com returns 200.

Steps to reproduce

1. Connect to a remote host via Remote-SSH in Cursor.
2. Wait until the remote workspace is fully loaded.
3. Open Chat (Composer) and send a message (simple question or Agent task).
4. Observe: response often does not arrive; console shows “Extension host became UNRESPONSIVE”, “No first token received within Xs”, and many “ComposerCapability … is not loaded … during its disposal?” errors; dialog window becomes slow or freezes.

Expected

Chat in Remote-SSH should return responses (possibly slower than local) and the dialog should remain responsive. Composer should not be accessed after disposal.

Actual

Chat often does not return a response; extension host becomes UNRESPONSIVE; many ComposerCapability disposal errors; dialog window freezes or is very slow. Network diagnostic still shows Success.

Summary

The issue seems to be stability of the Remote extension host and Composer lifecycle (access during disposal), not network connectivity. Fixing extension host timeouts and ensuring composer is not used after disposal would likely resolve the chat freeze and missing responses.

Steps to Reproduce

It is accrued 2 days ago on SSH project, local chats are working fine.

Operating System

Windows 10/11

Version Information

Version: 2.5.20 (user setup)
VSCode Version: 1.105.1
Commit: 511523af765daeb1fa69500ab0df5b6524424610
Date: 2026-02-19T20:41:31.942Z
Build Type: Stable
Release Track: Default
Electron: 39.4.0
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.19045

Does this stop you from using Cursor

Yes - Cursor is unusable

[deanrie]

Hey, thanks for the report.

A few things to try and check:

1. Disable HTTP/2: Open the app settings Ctrl + , search for “HTTP/2”, and enable “Disable HTTP/2”. With your proxy setup (SOCKS over SSH RemoteForward), HTTP/2 multiplexing can cause issues when running through a proxy.

2. MCP servers: Your logs show getPluginMcpServers / getPluginCommands / getPluginHooks taking 2,5 to 15+ seconds, which can block the extension host. Do you have any MCP servers configured? If yes, try disabling them temporarily to see if the freezes go away.

3. Extensions on the remote side: Try starting without extensions. This helps isolate whether a remote extension is causing the freezes.

4. Process Explorer: While connected over SSH, open Ctrl+Shift+P > Developer: Open Process Explorer. Check whether extensionHost CPU usage is unusually high on the remote side.

This is a known problem area. The team is aware of extension host freezes over SSH, and your report helps us prioritize.

Also, can you share the Request ID from one of the failed chat attempts? (Top-right of the chat > Copy Request ID.) This helps the team look up the server logs.

Let me know how these steps go.