I am experiencing frequent unexpected interruptions in Cursor chat and agent sessions.
The issue happens across all models I have tried. During a normal conversation or agent workflow, the chat/session window often stops responding or ends the current turn unexpectedly. The interruption can happen while the assistant is answering, analyzing files, or working through a development task.
The visible behavior is:
The assistant starts responding normally.
The response or workflow stops suddenly before completion.
The chat/session does not provide a clear error message or recovery explanation.
I have to manually send another message such as “continue” to resume.
The resumed session may lose continuity or fail to continue from the exact previous point.
This happens repeatedly and makes longer Cursor conversations unreliable. The problem is not limited to one specific model, prompt, or task type. It affects general chat as well as agent-style development sessions.
Please investigate why Cursor chat and agent sessions are frequently interrupted or stopped unexpectedly across all models.
Steps to Reproduce
Open Cursor.
Start a new chat or agent session.
Ask the assistant to perform a normal multi-step development task, such as analyzing files, explaining code, or working through a project issue.
Continue the conversation for several turns.
Try the same workflow across different available models.
The chat or agent session frequently stops unexpectedly before the response or workflow is completed.
Sending “continue” sometimes resumes the session, but the previous execution flow may be interrupted or lose continuity.
Hey, thanks for the detailed report. What you’re describing, the assistant stops before it finishes, then you have to type continue and it loses continuity, is a known issue and it’s on our radar. I can’t share an exact timeline for a fix yet.
To link your case to the investigation, can you share a couple details?
The Request ID from one of the interrupted responses: top-right chat menu (three dots) > Copy Request ID. If Privacy Mode is on, the Request ID might not be saved. If that happens, let me know if you have it enabled in Cursor Settings > Privacy.
Please run Cursor Settings > Network > Run Diagnostics and send the results. In some similar reports we’re seeing the stream drop due to network issues, which can trigger a false interruption, so I want to rule out a network factor.
Temporary workaround: if your connection is unstable, try enabling Disable HTTP/2 in App Settings, open settings with Cmd+Shift+, then search for HTTP/2. This often helps on corporate networks, VPNs, and proxies where stream drops happen.
198.18.0.0/15 is a reserved technical range that proxy and VPN clients like Clash, Surge, V2Ray, and similar tools use in fake IP mode. That means all Cursor traffic is currently going through a local proxy. Quick checks in Run Diagnostics can pass, but long streaming connections and agent responses are exactly that often get cut off by these proxies due to timeouts or node switching. From the outside, it looks exactly like your symptom: the response stops halfway through, you have to type continue, and continuity is lost.
What to check, in order:
Test without the proxy: temporarily disable the proxy or VPN completely and see if the cutoffs still happen. This is the fastest way to confirm the cause.
If you need the proxy, set up direct routing rules for Cursor domains so they do not go through fake IP: *.cursor.sh, *.cursor.com, *.cursorapi.com. Then streaming should go directly and stop breaking.
You already disabled HTTP/2, keep it disabled. That is the right direction.
We do know about the symptom of false interruption after a completed response, and it is being tracked. There is no exact ETA for a fix yet. But in your case, the logs point to a network factor, so start with step 1 and let me know if it still happens without the proxy.