Cursor Agent stuck on "Planning next move"

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

The Agent frequently gets stuck on “Planning next move” and never continues. It remains in this state indefinitely without any error message or timeout.

This happens across different projects and conversations, even after starting a fresh chat. The issue also occasionally occurs while the Agent is in the “Editing…” state.

Steps to Reproduce

Open any project.

Start a new Agent chat.

Ask the Agent to perform a medium or large coding task involving multiple files or tool calls.

Wait while the Agent works.

Eventually, it becomes stuck on “Planning next move” and never proceeds.

Expected Behavior

The Agent should continue planning and executing the remaining steps until the task is completed or an error is displayed if something goes wrong.

Operating System

MacOS

Version Information

3.14.27 (Universal)

For AI issues: which model did you use?

Auto mode , sonnet 4.5..

For AI issues: add Request ID with privacy disabled

2c5c93f4-be4a-4c30-8c80-3e04c439bd83
7cbe7072-c01a-417e-a89a-e70a8c903969

Does this stop you from using Cursor

Yes - Cursor is unusable

6

Hey there!
This looks like a VPN, proxy, or firewall on your network cutting off the longer agent requests (short steps finish, long ones hang). A few things to try, in order:

  1. Cursor Settings → Network → Run Diagnostics - this flags a proxy that’s breaking long-lived requests.
  2. If you’re on a VPN, disconnect it, fully quit Cursor (Cmd+Q, not just close), reopen, and retry a longer task. Fastest way to confirm, and often the fix.
  3. If you can’t drop the proxy/firewall, set Cursor Settings → Network → HTTP Compatibility Mode → HTTP/1.0, then fully quit and reopen. For a durable fix, have your network team exempt api2.cursor.sh and api2.cursor.com from SSL inspection and connection timeouts.

More detail: Network troubleshooting.

It also shouldn’t just spin with no error when a connection drops - that’s something we’ve seen before and want to improve. If those steps don’t do it, paste your diagnostics results here and I’ll dig in further.

7

Hi Mohit,

Everything is fine with the network diagnosis:

Cursor Network Diagnostic Results

DNS: Success
Logs:
[2026-08-07T11:22:45.009Z] Host:
[2026-08-07T11:22:45.009Z] Servers: 10.0.0.243
[2026-08-07T11:22:45.009Z] Resolved to 98.88.7.231 in 23ms
[2026-08-07T11:22:45.022Z] Resolved to 98.88.7.231 in 2ms
[2026-08-07T11:22:45.024Z] Resolved to 98.88.7.231 in 1ms
[2026-08-07T11:22:45.026Z] Resolved to 98.90.70.215 in 2ms
[2026-08-07T11:22:45.026Z] Host:
[2026-08-07T11:22:45.026Z] Servers: system
[2026-08-07T11:22:45.026Z] Resolved to 98.88.7.231, 32.192.143.36, 44.216.24.86, 34.233.18.171, 100.49.153.254, 3.225.211.18, 32.199.34.23, 100.49.207.14 in 0ms
[2026-08-07T11:22:45.026Z] Resolved to 98.88.7.231, 32.192.143.36, 44.216.24.86, 34.233.18.171, 100.49.153.254, 3.225.211.18, 32.199.34.23, 100.49.207.14 in 0ms
[2026-08-07T11:22:45.026Z] Resolved to 98.88.7.231, 32.192.143.36, 44.216.24.86, 34.233.18.171, 100.49.153.254, 3.225.211.18, 32.199.34.23, 100.49.207.14 in 0ms
[2026-08-07T11:22:45.026Z] Resolved to 98.88.7.231, 32.192.143.36, 44.216.24.86, 34.233.18.171, 100.49.153.254, 3.225.211.18, 32.199.34.23, 100.49.207.14 in 0ms
[2026-08-07T11:22:45.026Z] Result: true

HTTP/2: Success
Logs:
[2026-08-07T11:22:44.984Z] Start
[2026-08-07T11:22:45.259Z] Host:
[2026-08-07T11:22:45.259Z] Protocol: h2
[2026-08-07T11:22:45.259Z] Result: true in 275ms

SSL: Success
Logs:
[2026-08-07T11:22:44.984Z] Start
[2026-08-07T11:22:45.385Z] URL:
[2026-08-07T11:22:45.385Z] Status: 200
[2026-08-07T11:22:45.385Z] IP: 98.88.7.231
[2026-08-07T11:22:45.385Z] Issuer: C=US; O=Amazon; CN=Amazon RSA 2048 M01
[2026-08-07T11:22:45.385Z] Name:
[2026-08-07T11:22:45.385Z] AltName:
[2026-08-07T11:22:45.385Z] DNS Time: 6ms
[2026-08-07T11:22:45.385Z] Connect Time: 43ms
[2026-08-07T11:22:45.385Z] TLS Time: 223ms
[2026-08-07T11:22:45.385Z] Result: true in 401ms

API: Success
Logs:
[2026-08-07T11:22:44.985Z] Start
[2026-08-07T11:22:46.038Z] Result: true

Ping: Success
Logs:
[2026-08-07T11:22:44.986Z] Sending ping 1
[2026-08-07T11:22:45.438Z] Response: ‘ping’ in 452ms
[2026-08-07T11:22:45.438Z] Sending ping 2
[2026-08-07T11:22:45.489Z] Response: ‘ping’ in 51ms
[2026-08-07T11:22:45.489Z] Sending ping 3
[2026-08-07T11:22:45.538Z] Response: ‘ping’ in 49ms
[2026-08-07T11:22:45.538Z] Sending ping 4
[2026-08-07T11:22:45.586Z] Response: ‘ping’ in 48ms
[2026-08-07T11:22:45.586Z] Sending ping 5
[2026-08-07T11:22:45.636Z] Response: ‘ping’ in 50ms
[2026-08-07T11:22:45.636Z] Result: true

Chat: Success
Logs:
[2026-08-07T11:22:44.987Z] Starting stream
[2026-08-07T11:22:45.480Z] Response: ‘foo’ in 489ms
[2026-08-07T11:22:46.489Z] Response: ‘foo’ in 1009ms
[2026-08-07T11:22:47.490Z] Response: ‘foo’ in 1000ms
[2026-08-07T11:22:48.490Z] Response: ‘foo’ in 1000ms
[2026-08-07T11:22:49.499Z] Response: ‘foo’ in 1009ms
[2026-08-07T11:22:50.490Z] Result: true

Agent: Success
Logs:
[2026-08-07T11:22:44.990Z] Starting stream
[2026-08-07T11:22:44.991Z] Pushing first message
[2026-08-07T11:22:45.445Z] Response: ‘foo’ in 454ms
[2026-08-07T11:22:45.946Z] Pushing next message
[2026-08-07T11:22:45.996Z] Response: ‘foo’ in 551ms
[2026-08-07T11:22:46.497Z] Pushing next message
[2026-08-07T11:22:46.591Z] Response: ‘foo’ in 595ms
[2026-08-07T11:22:47.093Z] Pushing next message
[2026-08-07T11:22:47.174Z] Response: ‘foo’ in 583ms
[2026-08-07T11:22:47.674Z] Pushing next message
[2026-08-07T11:22:48.039Z] Response: ‘foo’ in 865ms
[2026-08-07T11:22:48.039Z] Result: true

Marketplace: Success
Logs:
[2026-08-07T11:22:44.981Z] Host:
[2026-08-07T11:22:45.112Z] Response in 131ms
[2026-08-07T11:22:45.112Z] Response: 200
[2026-08-07T11:22:45.112Z] Response Type: cors
[2026-08-07T11:22:45.112Z] Server: null
[2026-08-07T11:22:45.112Z] Result: OK in 131ms

Authentication: Success
Logs:
[2026-08-07T11:22:44.981Z] Host:
[2026-08-07T11:22:45.351Z] Response: 200 in 370ms

Authentication UI: Success
Logs:
[2026-08-07T11:22:44.984Z] DNS lookup:
[2026-08-07T11:22:45.009Z] Resolved to 104.18.35.233 in 17ms

Cursor Tab: Success
Logs:
[2026-08-07T11:22:44.984Z] DNS lookup:
[2026-08-07T11:22:45.009Z] Resolved to 104.18.18.125 in 16ms

Agent Endpoint: Success
Logs:
[2026-08-07T11:22:44.984Z] DNS lookup:
[2026-08-07T11:22:45.010Z] Resolved to 44.197.141.31 in 16ms

Downloads: Success
Logs:
[2026-08-07T11:22:44.983Z] Host:
[2026-08-07T11:22:45.383Z] Response: 403 in 400ms

CDN: Success
Logs:
[2026-08-07T11:22:44.984Z] Host:
[2026-08-07T11:22:45.272Z] Response: 404 in 288ms

i also realize it is also stuck on small tasks

8

Those built-in checks are all quick one-shot connections, so they pass even when a VPN/proxy is cutting the longer connection the agent streams over. It happening on small tasks too fits that.

Best test: switch to a phone hotspot with any VPN fully off, then Cmd+Q and reopen Cursor and retry a task that hangs. If that works, it’s the network path.

If you can’t switch networks, try Cursor Settings → Network → HTTP Compatibility Mode → HTTP/1.0, then fully quit and reopen - did you get a chance to try that yet? On a managed network, IT can exempt Cursor’s domains from connection timeouts and SSL inspection (network guide).

Let me know how the hotspot test goes.

9

Hi Mohit,

Indeed, it was the cause.

I found the root cause of the issue: an old CyberGhost VPN configuration was still registered in macOS, even though I had already uninstalled the CyberGhost app.

The confusing part was that all the usual network checks looked fine:

  • DNS worked
  • Ping worked
  • Cursor’s built-in diagnostics passed
  • HTTP/2 test passed
  • SSL/API/Agent checks passed

However, TCP connections were failing with:

No route to host

After checking the macOS network logs, I found:

Network Agent [domain: NetworkExtension, type: VPN, description: VPN: CyberGhost VPN (IKEV2)]

and:

tcp drop outgoing ... reason: NECP

So macOS was still applying an old VPN network policy even though the CyberGhost application itself had been removed.

What fixed it:

  1. Opened macOS System Settings
  2. Went to VPN
  3. Found the old CyberGhost IKEv2 configuration
  4. Removed the VPN configuration completely
  5. Restarted the Mac

After that, normal TCP/HTTPS connections started working again, and Cursor stopped getting stuck on “Planning next move”.

So indeed, it was a network/VPN issue. If anyone has the same problem, I recommend checking for old VPN configurations in macOS even if the VPN application has already been uninstalled.

thanks for your precious help.