Cursor gangs permanetly showing waiting for cnnection during long agent sessions

Where does the bug appear: Cursor IDE

Describe the Bug:

cursor-server (remote SSH) hangs permanently showing “waiting for connection” during long agent sessions. logs reveal two distinct crash modes:

  1. Error in consumeStream via Fetch.terminate in node’s undici - upstream streaming connection dropped
  2. [composer] No loaded composer found - local composer garbage-collected while a long streaming response was in flight on the remote

after either crash, the agent UI hangs indefinitely. only recovery is starting a new conversation.

Steps to Reproduce:

  1. connect to a remote linux machine via Cursor SSH (cursor-server)
  2. use agent mode with tool calls (shell, read, glob, str_replace)
  3. work in a single conversation past ~75 messages
  4. cursor hangs, shows “waiting for connection” permanently
  5. starting a new conversation recovers immediately

conversation state growth from logs (~/.cursor-server/data/logs//exthost/anysphere.cursor-agent-exec/Cursor Agent Exec.log):

reproduces consistently: 10+ crashes across 3 sessions in 2 days.

Expected Behavior:

cursor should either handle large conversation state gracefully (trim/compress older messages) or surface an error message suggesting to start a new conversation, rather than hanging indefinitely with no feedback.

Operating System: Linux (GCP VM, remote SSH) + macOS (local client)

Version Information:

IDE:
Version: 3.4.20
VSCode Version: 1.105.1
Commit: 0cf8b06883f54e26bb4f0fb8647c9500ccb43310

Model: gpt-5.5 via custom OpenAI-compatible proxy endpoint (cli-gpt-5.5-xhigh-fast)

Additional Information:

  • crash 1 stack trace: Fetch.onAborted → Fetch.terminate in node:internal/deps/undici/undici
  • crash 2 stack trace: $localAgentSendInteractionUpdate → [composer] No loaded composer found in workbench.desktop.main.js
  • no OOM kills in dmesg - RSS stays ~950MB, doesn’t trigger kernel OOM
  • also found: worker.js missing from cursor-agent-exec/dist/ (separate issue, breaks PDF reads)
  • workaround: rotate conversations every ~45 minutes / ~75 messages

Does this stop you from using Cursor: partially - have to restart conversations frequently, losing context

Hey, thanks for another great report.

This is a known cluster of issues. Long agent sessions build up listener leaks and memory leaks in the extension host, and over SSH Remote it hits harder because the forked extension host scales with VSZ. The symptoms you described, Fetch.terminate in undici, [composer] No loaded composer found, a hang on “waiting for connection” with no recovery, are all part of the same degradation, not separate bugs. There’s a similar case with the same symptoms here: Remote extension host memory grows unboundedly over long agent chats; RPC reply handlers leak.

Your workaround, rotating conversations every about 45 minutes or about 75 messages, is the right mitigation for now. RSS around 950 MB without OOM matches what we see. The bottleneck is not heap exhaustion, it’s listener buildup that chokes the event loop.

We’re tracking the issue, but I can’t share an ETA for a fix yet. When something ships in a release, I’ll reply here.

A couple quick notes:

  • worker.js missing from cursor-agent-exec/dist/ during PDF reads is a separate issue. If you can reproduce it reliably, please open a separate thread and we’ll investigate.
  • A custom OpenAI-compatible proxy endpoint doesn’t really change the picture since the leak is on the client side. If you want to rule out proxy-side aborts as part of crash mode 1, try the same workflow in a session using a stock model and compare at what message count the hang starts.