same for me too, ı swithed to another acc(free tier) and it is working so its account related some how, my stucked acc was pro plan.. ı already opened thread ı need urgent fix too..
Hey @Qiang_He, thanks for the detailed report and the Request ID.
It looks like the request fails before it even leaves your Mac, which is why there’s such a long pause before the error. In your screenshot, the chat is open on No Repo, and in that state the Agents Window can sometimes get stuck with no visible loading indicator, while the normal editor window keeps working. Let’s narrow down the cause:
In the Agents Window, click No Repo at the top of the chat and pick a real project folder.
Open a new chat in that project and send hello. Does it respond?
Open Cursor Settings with Cmd+Shift+J, search for trust, and check Security > Workspace > Trust: Empty Window. If it’s off, turn it on, then fully quit Cursor with Cmd+Q and reopen it.
Go back to the Agents Window with No Repo, open a new chat, and send hello again.
Tell me what happened in step 2 and step 4. If it still fails, right after the failed send press Cmd+Shift+P in the Agents Window, run Developer: Capture and Send Debugging Data with default settings, and share the approximate time you started it. Also open the Output panel, pick Cursor Agent Host in the dropdown, and paste the last about 30 lines.
While we’re digging into this, the normal editor window should work as a temporary workaround. In the Agents Window press Cmd+Shift+P, then run Open IDE.
This is a known issue we’re tracking. I don’t have an exact timeline yet, but the steps above will help confirm whether you’re hitting the same case.
Thanks, the capture helped a lot. It shows the version in restricted mode / No Repo, and the agent host extension activated and registered the provider normally (timeToBridgeRegisterMs: 272).
But after that, we see something else. The turn fails on the runtime connect (reason: managed-local-unavailable), then it hangs for a few minutes with no response. Also, capture itself crashed with Client network socket disconnected before secure TLS connection was established (that’s in the screenshot). Both signals point to a network connection issue between Cursor and the backend. That’s the path where the Agents Window is getting stuck. The IDE chat uses a different path, which is why it still works.
Let’s check the network:
Open App Settings Cmd+,, find HTTP/2, and turn on Disable HTTP/2. Then fully quit Cursor with Cmd+Q and reopen it. This is a common cause of TLS socket disconnects on strict networks, or behind a proxy or VPN.
Cursor Settings > Network > Run Diagnostics, then send me the results.
After that, open a new chat in the Agents Window and send hello. Let me know if anything changes.
If you’re using a VPN or a corporate proxy, try without them for this test so we can see if they’re affecting it.
While we’re debugging, the regular editor window should work as a temporary workaround. In the Agents Window, press Cmd+Shift+P and run Open IDE.
The issue has been resolved; it was related to the upgrade to macOS 27.0.
You can check out this post—the information there is correct.
By the way, why do ARM applications sometimes have dependencies on Intel-based components?
Glad installing Rosetta got you unblocked, and thanks for sharing what worked so others can find it.
To answer your question: Cursor was using the first git it found on your PATH, and on some Macs that’s an older Intel-only copy left over from a previous install (often in /usr/local/bin). macOS 27 doesn’t carry Rosetta over during the upgrade, so that git couldn’t start and the Agents Window stalled waiting on it.
A fix for this is coming in Cursor 3.23. Cursor will fall back to a compatible git instead of hanging, so the agent keeps working even if Rosetta isn’t installed.
