Agent is interrupted with "Connection Error" if Subagent is running for more than two hours

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Agent is interrupted with “Connection Error” if Subagent is running for more than two hours.

  • I didn’t have time to take a screenshot because the error disappeared when switching between chats, but the error was the same as when the connection was lost.
  • I’m not sure if the connection wasn’t actually interrupted.

Steps to Reproduce

  1. Start an Agent in IDE window Chat
  2. The Agent should start a Subagent
  3. The Subagent should launch a foreground shell in legacy terminal mode, which will run for more than 100 minutes (in my case, the process took at least 103 minutes). But the Subagent was also doing other work before launching this long terminal, so I can’t say how long it actually worked.

Operating System

Windows 10/11

Version Information

Version: 3.12.17 (system setup)
VS Code Extension API: 1.128.0
Commit: 0fb762053c34788bb7760d5673f8a6d4c8589d50
Date: 2026-07-17T02:53:53.006Z
Layout: IDE
Build Type: Stable
Release Track: Nightly
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Windows_NT x64 10.0.22631

For AI issues: which model did you use?

gpt-5.6-terra-1m-Max + grok-4.5-High

For AI issues: add Request ID with privacy disabled

ARID: c8ac4664-5ef4-4a04-9de7-4ff9b6c2a832
SRID: 784a737a-901b-4f99-94d8-77818f3976a8

Does this stop you from using Cursor

Yes - Cursor is unusable

Hey there!

This isn’t a hard 2-hour limit, and your work generally isn’t lost. When a single agent turn stays open for a very long time (like your subagent waiting on a 100+ minute foreground terminal command), the long-lived connection to our backend gets dropped and re-established a few times. Each turn only allows a limited number of those reconnects, so a multi-hour turn eventually uses them all up and surfaces the generic “Connection Error.” The ~2 hours is just how long it takes to hit that limit, not a fixed timeout, and the error card usually sits on top of an otherwise-resumed conversation, which is why it vanished when you switched chats.

This is on our side, not your setup. I’ve traced the mechanism and reported it to our team.

A couple of things that can reduce it in the meantime:

  1. For very long-running processes (100+ min), running them in the background rather than as a foreground shell the agent waits on keeps a single turn from being held open for hours, which is what exposes it to these reconnects. Splitting a big task across shorter turns has the same effect.
  2. If you’re on a corporate VPN or proxy, disabling HTTP/2 (Cursor Settings, search “http2”) usually cuts down on the mid-stream drops that trigger this.

If it keeps happening even with shorter turns, reply here and I’ll dig in further.

Hey @Artemonim!

The behavior should be more stable here in 3.13. We’ve merged some changes to give agent streams a better chance to recover.