Agent is stuck with "Taking longer than expected"

Hi, Cursor agent appears to be stuck forever even for a simple command. Below is a screenshot of Run Diagnostic. How can this be fixed?

Your diagnostic shows : the DNS check is failing (“No response”), and the Authentication UI and Cursor Tab checks both fail with “No response from DNS lookup.” So your machine can’t resolve some of Cursor’s domains, and requests never reach our servers, which is why the agent just sits there.

Since a few checks pass (Marketplace, Authentication) while the core API/Tab/auth domains don’t resolve, this almost always points to a corporate firewall, DNS filter, or VPN that’s only letting through part of Cursor’s traffic.

A few things to try:

  1. Test on a different network. Disconnect from any VPN and switch to another connection (e.g. a personal hotspot), then fully quit and reopen Cursor (not just Reload Window) and re-run diagnostics. If it works off your work network, that confirms the network/firewall is the cause.
  2. If you’re on a VPN, fully restart Cursor after disconnecting — Cursor can hold onto a VPN’s DNS settings until it’s restarted completely.
  3. If you’re on a managed/corporate network, the fix is to have your IT team allowlist Cursor’s domains in the firewall/DNS policy:
    • *.cursor.sh
    • *.cursor-cdn.com
    • *.cursorapi.com

Full steps and the connectivity tests are here: Network, proxy, and remote connections.

If it still fails after testing off your corporate network, hit Copy diagnostics in that same Network panel and paste the output here, and let me know whether you’re behind a VPN or proxy - that’ll let us pinpoint exactly which domains are being blocked.

for us, since a few days the agent is getting tuck on a forever “thinking” state, mostly when running terminal commands.

I have to quit the app and restart it, but then after a few iterations happens again. I ran the diagnostics and the “Ping” and “Chat” services are on an infinite loading state (see screenshot).

This started happening very often just since a few days ago. Its very annoying!!!

@mohitjain or someone from the cursor team, please help!

Version: 3.9.19
VS Code Extension API: 1.105.1
Commit: f4c1e61a548954c54901e654e536534d8e0d4080
Date: 2026-06-28T21:40:06.655Z
Layout: editor
Build Type: Stable
Release Track: Nightly
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: Darwin arm64 25.3.0

This is a different diagnostic pattern from the original post here (that one was DNS resolution failing). Yours shows Ping and Chat failing with [unavailable] PING timed out, while DNS, HTTP/2, SSL, API, and Agent all pass - so basic connectivity is fine, but the long-lived chat stream’s health checks are timing out. That lines up with the agent sitting on “Thinking” and stalling on terminal commands.

Try this:

  1. Cursor Settings → Network → HTTP Compatibility Mode → HTTP/1.1
  2. Fully quit Cursor and reopen (not just Reload Window)
  3. Re-run Network Diagnostics — Ping and Chat should pass

If you’re on a VPN or a managed network, also try a different connection (e.g. phone hotspot) with a full restart. That tells us whether the network path is the issue.

Docs: Network, proxy, and remote connections

If Ping/Chat still time out after that, hit Copy diagnostics in that panel and paste the output, and say whether you’re behind a VPN or proxy.

Hi @mohitjain ,

Thanks for your comments. I tried the steps 1,2,3 and it still didn’t work.

I noticed that I had some extensions installed and I guessed it may have corrupted the cursor profile. Creating a new profile automatically resolved the issues I had in the Network Diagnostics report.

Glad the new profile sorted it - and that result actually tells us what was going on. Something in your old profile (most likely one of the extensions you had installed, or a setting it changed) was interfering with how Cursor connects, which is why the diagnostics showed failures and the agent hung even though your underlying network was fine. That’s also why steps 1-3 didn’t help: they target the network path, not a profile-side issue.

To get your setup back without bringing the problem back:

  1. Keep the new (working) profile as your main one. Add your extensions back a few at a time, and re-run Cursor Settings > Network > Run Diagnostics (plus a quick agent request) after each batch. If the failures return right after a specific extension, that’s your culprit.
  2. When copying settings across, leave out any custom network/proxy settings from the old profile. Bring over your editor and keybinding preferences first, and only add the rest if diagnostics stay green.
  3. Don’t delete your old profile yet. Keep it as a reference so you can compare its extension list and settings against the clean one to pin down what caused this. Deleting a profile removes its extensions list, settings, and associated state, so hold onto it until you’ve migrated everything you need.

If the failures come back when you re-add a particular extension, reply here with which one and a fresh Copy diagnostics output, and I’ll help narrow it down.