Agent disconnect too often

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Since several weeks, i experience agent disconnect more often than previously during long task that use subagent to handle serially several tasks.

In august i have launched during the month several very big job with around 40 tasks and i did not experience this issue. In september it is almost everytime i launch a job with more than 5 tasks.

Steps to Reproduce

Maybe just ask an agent to handle a serie of several tasks serially using subagents.

If you want to check logs here is a request id : 9483cd95-b360-4669-b601-6085536d1b7d
I have started this yesterday (Paris TZ), there is 10 tasks to do it was stuck all night and did not progress. Experienced some disconnects this morning also.

Operating System

Linux

Version Information

Version: 3.21.16
VS Code Extension API: 1.128.0
Commit: 8ae78e8eee1e63479c7e0504b664bc0a80c68000
Date: 2026-09-19T06:43:22.276Z
Layout: IDE
Build Type: Stable
Release Track: Default
Electron: 42.10.0
Chromium: 148.0.7778.280
Node.js: 24.18.1
V8: 14.8.178.38-electron.0
xterm.js: 6.1.0-beta.291
OS: Linux x64 7.0.0-31-generic

For AI issues: which model did you use?

Grok 4.6 but i remember the same kind of issue with Composer 2.5 fast.

For AI issues: add Request ID with privacy disabled

9483cd95-b360-4669-b601-6085536d1b7d

Additional Information

Cursor is unusable for the needs i have to fullfil : “Handling a list of tasks serially in autonomy”

Does this stop you from using Cursor

Yes - Cursor is unusable

6

Hey @Marlou, thanks for the report and the request ID!

What’s happening: when the connection drops a couple of times while the main agent is waiting on a long-running subagent, it stops reconnecting even though the subagent keeps going and finishes. Nothing is lost, but the job just sits until you pick it back up. It’s not something on your end, and it’s an issue we’re tracking.

Two things that help:

  1. Click Retry / Try again on the error. It continues from the last save point and pulls in whatever the subagent already finished.
  2. Have the agent run one subagent per task, waiting for each, instead of one long subagent for the whole batch. Each finished subagent is a save point, so a dropped connection is much less likely to stall the run.

If it still happens with smaller steps, run Cursor Settings > Network > Run Diagnostics and share the results plus a fresh request ID. You can also try HTTP Compatibility Mode → HTTP/1.1 in the same settings, which is often steadier for long streams.

I’ll post here when there’s an update.