Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
CURSOR SUPPORT REPORT — “Agent Execution Timed Out” (deadline_exceeded)
SUMMARY
Frequent “Agent Execution Timed Out” errors during agent chats. The request
connects successfully, but the server-side agent backend sends ZERO tokens and
the request fails at a consistent ~70-second deadline (“Request aborted before
first token”). This happens across chats of all sizes (13-message chats fail as
often as 187-message chats) and affects roughly 35% of requests
(33 success / 18 timed out / 6 cancelled across recent sessions).
All client-side network causes have been investigated and ruled out (details
below), which points to a server-side agent-backend issue. Requesting
investigation of the request IDs listed.
ENVIRONMENT
- OS: Windows 11 (10.0.26200), x64
- Cursor client_version: 3.12.30 (stable channel)
- Layout: glass
- Model observed on failures: claude-opus-4-8
- Backend: server-side “agent backend” (useAgentProviderRouter=false)
- Network: home Wi-Fi, no proxy (WinHTTP direct, WinINET ProxyEnable=0)
ERROR SIGNATURE (representative trace, requestId f79fc100-…)
19:32:09 agent.turn.start turn_type=“resume” model=“claude-opus-4-8”
19:32:09 Starting stream request → Using agent backend
19:32:10 “No first token received within 2s”
19:32:12 …4s → …6s → …8s … → …32s (server sends nothing)
19:33:18 [error] ConnectError: [deadline_exceeded] Agent Execution Timed Out
19:33:18 “Request aborted before first token” elapsedMs=70136
span “agent.request” durationMs=70299
All 18 failures share this pattern; elapsed time clusters tightly at
~70,000-71,000 ms (a couple at 77-81s), i.e. a fixed server-side deadline with
zero bytes received. TCP connection stays up the whole time (no resets).
CLIENT-SIDE INVESTIGATION (all clean)
- Extension host: starts cleanly every session; cursor-agent-exec /
cursor-agent-worker / cursor-mcp all activate in <1s. No startup timeout. - DNS: api2.cursor.sh + all Cursor hosts resolve fast (~17ms). (Note: an earlier
family-filter DNS resolver 1.1.1.3 was causing intermittent ENOTFOUND; switched
to 1.1.1.1 — resolved.) - HTTP transport: set cursor.general.disableHttp2=true (HTTP/1.1). Confirmed live:
“HTTP/1.1 transport created”, httpVersion=1.1. (Earlier HTTP/2 produced 122x
NGHTTP2_REFUSED_STREAM; gone after switching to HTTP/1.1.) - Endpoint reachability (curl): api2.cursor.sh dns=17ms tls=195ms ttfb=259ms HTTP 200.
- Stream buffering test (curl to httpbin drip): first byte in ~0.3s, streams
incrementally over 6s — no middlebox buffering on this host. - Endpoint security: SentinelOne agent (Sentinel Agent 25.1.3.334) with
SentinelNetworkMonitor loaded, but logged ZERO network/mitigation events at any
timeout timestamp, and generic HTTPS streaming passes through fine. - Windows event logs: NO TCP drops, Wi-Fi disconnects, or reconnects during the
timeout windows.
Conclusion: DNS + HTTP/1.1 fixes eliminated the earlier connect/stream errors,
but “Agent Execution Timed Out” persists after those fixes and after a full
restart. Given the clean client evidence and the zero-token / fixed-70s-deadline
signature on the server-side agent backend, this appears to be a server-side
agent execution timeout.
FAILING REQUESTS (18) — timestamp (local, UTC-7) | requestId | conversationLength
2026-07-21 22:22:09 97055414-c5be-46b1-b91e-317b387d3a30 len=18
2026-07-21 22:23:46 09f46f58-1783-4949-b1f8-b4717708bd4f len=18
2026-07-22 13:04:20 091628c1-7070-4508-b40b-754968a42b92 len=20
2026-07-22 13:08:55 2f014a94-a413-425a-898e-7c68ed2f3779 len=20
2026-07-22 14:56:02 ee8162a2-a06a-4827-aaab-adce6e37a3b2 len=13
2026-07-22 14:58:04 0b588674-5368-446d-8a48-32e3ec16b5a4 len=13
2026-07-22 15:11:38 03d0a3a8-4714-442d-bbaa-814f711adb12 len=13
2026-07-22 15:14:14 b01ba0a6-062b-4411-bab7-34e548c07c04 len=13
2026-07-22 17:44:17 7abe0216-3e72-4aa4-b298-e22eeafc06b0 len=13
2026-07-22 17:46:24 1ec64755-eb65-483f-839d-66bc12d999eb len=13
2026-07-22 18:51:14 cd05f662-acf8-4822-8f7f-a87a0426bf2b len=187
2026-07-22 18:52:46 6b3c8418-e01b-429e-96ca-20bd373b5ca7 len=187
2026-07-22 18:54:06 a141b79a-a1a4-40b5-98c0-d704f5d52fe9 len=187
2026-07-22 18:56:23 128a7be1-c58a-4d0c-b5c1-3500f01e09f5 len=13
2026-07-22 19:01:57 ab477ad9-a861-49a3-92b4-a5f3ce401b3e len=13
2026-07-22 19:03:47 eb78ab48-afb8-4804-bb9d-49f55b6eb34f len=13
2026-07-22 19:05:57 dd49df84-a3b2-491b-9c83-28db458b4d4a len=187
2026-07-22 19:33:18 f79fc100-30be-4a7c-a1ec-ead488610512 len=187
Most recent Request ID (from the Cursor error UI): f79fc100-30be-4a7c-a1ec-ead488610512
QUESTION FOR SUPPORT
Why is the server-side agent backend failing to emit a first token within the
~70s deadline for these requests, and is there anything server-side (routing,
model capacity for claude-opus-4-8, account/region) that explains the ~35%
failure rate? Client network path is confirmed healthy.
Steps to Reproduce
Occurs intermittently during agent chats
Operating System
Windows 10/11
Version Information
Cursor client_version: 3.12.30 (stable channel)
For AI issues: which model did you use?
claude-opus-4-8
For AI issues: add Request ID with privacy disabled
see IDs above
Does this stop you from using Cursor
Sometimes - I can sometimes use Cursor