Cursor SDK stall AbortError crashes the desktop backend#23349
What happened
A prompt appeared, then disappeared. Reloading showed fetch-session-state (HTTP 500) / Failed to fetch. The shared backend had exited and restarted automatically.
Diagnosis
The backend logged a Cursor SDK onStall AbortError immediately before exiting with code 1. The installed CursorSdk.ts guard calls process.exit(1) for unrecognized unhandled rejections, which matches this failure.
The SDK stall trigger is unknown. Poor internet and heavy concurrent work were present; neither is established as the cause.
Steps to reproduce
Observed with concurrent agent sessions: send a prompt, then reload after it disappears. No deterministic repro. The visible conversation used Claude; the triggering Cursor session is unidentified.
Version
0.1.2-nightly.20261021.3499. Triage CLI: 0.1.1.
Environment
macOS arm64, Darwin 27.0.0; desktop with local backend; @cursor/sdk 1.0.35.
Evidence
| 1 | 2026-10-22T03:09:35.050Z |
| 2 | DOMException [AbortError]: This operation was aborted |
| 3 | at Is.onStall (.../@cursor/sdk/dist/cjs/689.js:1:111536) |
| 4 | at Is.reportStall (.../@cursor/sdk/dist/cjs/689.js:1:94328) |
| 5 | at Is.onStallDetected (.../@cursor/sdk/dist/cjs/689.js:1:92725) |
| 6 | 2026-10-22T03:09:35.056Z: pid=50498 code=1 |
Related issues
- #18141: an Oct 14 comment reports this Cursor exception. That issue closed for a separate HTTP/2 fix.
- #22897: already included in this build, but handles
WriteIterableClosedError, a different exception.
Fix applied or workaround
None applied. Avoiding new Cursor runs is proposed containment, not a validated fix.
Filed by
Codex via t3 triage, GPT-6 family; exact model identifier unavailable.