Very Frequently seeing Internal Error: "This socket has been ended by the other party"

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

I am frequently encountering an internal server error while using Cursor IDE. The request fails with the message “This socket has been ended by the other party”, followed by an “An unexpected error occurred on our servers” popup. The issue occurs repeatedly during normal AI interactions, requiring me to retry requests multiple times, which significantly disrupts my workflow. The problem appears to be intermittent and server-side rather than related to my local environment. I have attached the screenshot, Request ID, and stack trace for investigation.

Steps to Reproduce

Just give the prompt, it will load for some time and then pop up with this error seen very frequently new chat and retry both are not working

Expected Behavior

shouldnt get terminated in btwn

Screenshots / Screen Recordings

Operating System

Windows 10/11

Version Information

Version: 3.10.20 (user setup)
VS Code Extension API: 1.125.0
Commit: 23b9fb205fe595ea2be29da7214e19762d037fc0
Date: 2026-07-07T07:03:33.071Z
Layout: IDE
Build Type: Stable
Release Track: Default
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.26100

For AI issues: which model did you use?

Cursor Grok 4.4 High but seen in all model

For AI issues: add Request ID with privacy disabled

79b24c58-fd4b-4ce8-8523-adc2a3592df3

Additional Information

Request ID: 79b24c58-fd4b-4ce8-8523-adc2a3592df3
[internal] This socket has been ended by the other party
RetriableError: [internal] This socket has been ended by the other party
at hdf (vscode-file://vscode-app/c:/Users/gshivamurthy/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:9066:9690)
at Wqi (vscode-file://vscode-app/c:/Users/gshivamurthy/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:9066:8425)
at wcp (vscode-file://vscode-app/c:/Users/gshivamurthy/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:9067:11962)
at Object.classify (vscode-file://vscode-app/c:/Users/gshivamurthy/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:9067:16467)
at gdf (vscode-file://vscode-app/c:/Users/gshivamurthy/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:9067:5856)
at async fWo.runWithSharedTurnRunner (vscode-file://vscode-app/c:/Users/gshivamurthy/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:9067:15819)
at async xz.runAgentLoop (vscode-file://vscode-app/c:/Users/gshivamurthy/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:20459:3067)
at async lba.streamFromAgentBackend (vscode-file://vscode-app/c:/Users/gshivamurthy/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:20487:14009)
at async lba.getAgentStreamResponse (vscode-file://vscode-app/c:/Users/gshivamurthy/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:20487:23432)
at async VIe.submitChatMaybeAbortCurrent (vscode-file://vscode-app/c:/Users/gshivamurthy/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:9229:2399)
at async wk (vscode-file://vscode-app/c:/Users/gshivamurthy/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:19518:83910)

and the try again doesn’t continue from where it stopped, it will start from the beginning.

Network:

Does this stop you from using Cursor

Yes - Cursor is unusable

Hey there!

Two signals in your Network Diagnostics: your traffic is being SSL-inspected by a proxy (the goskope.com / Netskope certificate), and the Chat check is failing with “Streaming responses are being buffered by a proxy.” That buffering is what produces “This socket has been ended by the other party” - the proxy holds and then cuts the long-lived streaming connection mid-response, so the reply can’t stream back even though the request itself completes.

Since you’ve already set HTTP Compatibility Mode to HTTP/1.0 and it didn’t help, the fix needs to happen on the proxy side. Ask your network/IT team to, for Cursor’s domains:

  1. Bypass SSL inspection, and
  2. Disable response buffering and allow Server-Sent Events (SSE) passthrough without forced connection timeouts.

Domains to exempt (or grab the full list via Settings → Network → Copy Domains):

  • *.cursor.sh
  • *.cursor-cdn.com
  • *.cursorapi.com

Our Network Configuration docs list the exact proxy requirements, plus curl commands your IT team can run to confirm streaming works (output should arrive line-by-line; if it lands all at once, the proxy is still buffering).

Once that bypass is in place, re-run diagnostics - the Chat check should pass. Let me know if it’s still happening after that.