I’ve been experiencing an issue where Cursor stops automatically after exploring a few files — forcing me to manually click “Continue.” Sometimes it even halts after just a brief “Thought,” making progress frustratingly intermittent.
This problem has always existed, but it’s become significantly worse over the past two weeks. It’s most severe with Opus 4.7, but I’ve also seen similar behavior when switching to GPT-5.5 or Composer 2.5.
At this rate, I’m seriously considering abandoning Cursor and switching to Claude instead..
Steps to Reproduce
Initiate a New Agent session.
Give the agent a standard coding request.
Wait for the agent to finish exploring the initial set of files.
Result: The agent halts prematurely instead of proceeding to the next step. It often shows “Thought briefly” and then does nothing, forcing me to intervene and press “Continue.”
Expected Behavior
The agent should autonomously complete the entire task or reasoning chain without requiring manual intervention to “Continue” after every few file explorations.
I am using a proxy (VPN) and have set the HTTP Compatibility Mode to HTTP/1.1. However, if this were a network disconnection, I would expect to see a “Reconnecting…” message. Currently, the agent simply fails silently and stalls without any notification.
This is a known issue that our team is actively investigating. Your setup is especially susceptible to this because you have HTTP Compatibility Mode set to HTTP/1.1 combined with a VPN. HTTP/1.1 streams through proxies are more prone to message drops than HTTP/2 connections.
A few things to try:
Disable HTTP/1.1 compatibility mode — Go to Cursor Settings > Network and turn off “Use HTTP/1.1”. HTTP/2 has built-in multiplexing and flow control that’s more resilient to intermediary interference. If your proxy supports HTTP/2, this should significantly reduce the stalling frequency.
Run Network Diagnostics — Go to Cursor Settings > Network > Run Diagnostics and share the results. This will help us understand if there are specific connectivity issues between your setup and our servers.
Try a different VPN exit node — If disabling HTTP/1.1 isn’t possible (some proxies require it), try routing through a different region. Your current traffic exits through AWS Singapore, and the additional latency + proxy handling increases the risk of message drops.
This issue affects multiple models (not just Opus 4.7), which matches what you’re seeing across GPT-5.5 and Composer 2.5 as well. Our engineering team is working on making the stream handling more resilient to these network conditions.
Let me know if switching off HTTP/1.1 mode helps reduce the frequency!
Thanks for the diagnostics and for trying a different VPN node.
The diagnostics confirm why this is happening: your VPN routes all traffic through a local proxy (127.0.0.1), which adds ~800ms+ latency per round trip. Short operations work fine, but long agent sessions with many back-and-forth messages are where the proxy drops or reorders data, causing the stall.
Switching VPN nodes doesn’t help here because the bottleneck is the local VPN proxy’s handling of HTTP/1.1 streams, not the exit location.
Two things that could help:
Try without VPN temporarily (even once) to confirm the VPN proxy is the root cause. If the stalling stops, that narrows it down definitively.
VPN split tunneling – if your VPN supports it, exclude Cursor’s domains (*.cursor.sh, *.cursorapi.com, *.cursor.com) from the VPN tunnel. This would let Cursor connect directly with HTTP/2 while keeping the rest of your traffic on the VPN.
Our engineering team is also working on making the stream protocol more resilient to these network conditions, which should help even in difficult proxy setups.
The VPN proxy appeared to be the root cause. With the VPN disabled, the stalling stopped—at least in Composer 2.5.
I’m using Clash for Windows and am unsure whether “tunneling” refers to TUN mode in Clash. When I disable TUN mode and switch Cursor to HTTP/2, the network diagnostic shows 2 out of 4 tests failing (see diag1.txtand diag3.txt). I’m not certain whether this is due to an issue on my VPN provider’s side.
Just a quick update: After downgrading to the older version, I no longer encounter the ‘stalling without errors’ issue, but ‘taking longer than expected’ happens quite often. Perhaps these are just two different symptoms of the same underlying problem.
Hi @WeiYuemin, I hope you find stable solution for your setup, I’m in China also, and my setup have been running really well since more than 2 month now! http 2 and latest version all working well! I’m using Throne as the vpn host with my own vps in Tokyo connected on it, would love to share more details if you are interested, all model have been working well on my end, without stalling issue!
I have 2 setup, both work well, the harder one is : Vultr (sing-box) ➔ Hysteria2 / VLESS REALITY ➔ Throne (Clash Meta)
feel free to ask an LLM about that.
And the easier one… Oh, they are currently having trouble, I won’t share the link in here, the name is GW树洞
Thanks for the thorough testing @WeiYuemin. The version comparison is very helpful.
What you’ve found is a possible regression between 3.1.17 and 3.5.17: the same network setup (HTTP/1.1 + VPN) that worked before now causes silent stalls. I’ve shared this finding with our engineering team along with the version details.
You’re also right that the “taking longer than expected” messages are a related but older issue that affects both versions. The silent stall without any error notification is the new behavior introduced between April and May.
I’ll follow up here once we have more info on a fix.
Hi @Tom_Coustols, thanks for sharing your setup! When you were using HTTP/2 with the latest version, did you still run into the issue “take longer than expected”? If it happened on your side, I might just stick with the older version for now — your config looks a bit complex
Hi @mohitjain , thanks for the reply! I’ll be looking forward to the fix then.
but no I have no more issue on my end with it at least