Hey, sorry for the delay. I see you’ve updated to v2.3.29 and the issue is still there. Thanks for the console video, it helps show the full picture.
The bug is already in the backlog. Your curl shows Cloudflare connects, but can’t route to the backend. It’s weird that you’re the only one reporting this, infra issues usually affect many users.
I’ll let you know when it’s fixed.
It’s been almost 4 months since I got banned from using Cloud Agents.
You’re not gonna solve this, right? Even though I’m paying $500 per month.
Any updates on this?
4 months and a half without access to Cloud Agents.
Any update on this?
5 months without Cloud Agents and 1 month without Worktree agents: Worktree agents fork automatically into separate workspaces - #18 by dny_ex
Any update on this?
5 months and a half without Cloud Agents and 1 month and a half without Worktree agents: Worktree agents fork automatically into separate workspaces - #18 by dny_ex
You’re really not going to answer and this thread will be open for a year?
Hi @dny_ex,
I’ve reviewed this thread from the beginning with fresh eyes. I owe you an honest answer.
After a thorough review, we’ve determined that the api3.cursor.sh error you originally identified – while real – is not connected to Cloud Agents. That endpoint handles other background services. This means the actual reason Cloud Agents aren’t working for you was never properly diagnosed, and for that, I’m sorry.
Here’s what I need:
Update Cursor to the latest version (Help > Check for Updates). You’re on 2.6.11, and Cloud Agents have had significant updates since then.
Confirm your GitHub connection: Cloud Agents require your project to be connected to a GitHub repository. Check that your workspace has a git remote pointing to GitHub (Cursor Settings > General > GitHub should show “Connected,” and your project should have a GitHub remote).
Try launching a Cloud Agent after updating, and if it fails, share:
A screenshot of the Developer Console errors (Help > Toggle Developer Tools > Console tab)
Your updated Cursor version
This will give us the actual error to work with instead of the api3 red herring.
I tell you one of the answers that I gave Dean months ago:
How me updating Cursor has anything to do with getting a 404 when doing a curl request to https://api3.cursor.sh ?
➜ curl -v https://api3.cursor.sh
Host api3.cursor.sh:443 was resolved.
IPv6: (none)
IPv4: 104.18.18.125, 104.18.19.125
Trying 104.18.18.125:443…
Connected to api3.cursor.sh (104.18.18.125) port 443
ALPN: curl offers h2,http/1.1
(304) (OUT), TLS handshake, Client hello (1):
CAfile: /etc/ssl/cert.pem
CApath: none
(304) (IN), TLS handshake, Server hello (2):
(304) (IN), TLS handshake, Unknown (8):
(304) (IN), TLS handshake, Certificate (11):
(304) (IN), TLS handshake, CERT verify (15):
(304) (IN), TLS handshake, Finished (20):
(304) (OUT), TLS handshake, Finished (20):
SSL connection using TLSv1.3 / AEAD-AES256-GCM-SHA384 / [blank] / UNDEF
ALPN: server accepted h2
Server certificate:
subject: CN=api3.cursor.sh
start date: Mar 2 02:55:10 2026 GMT
expire date: May 31 03:55:08 2026 GMT
subjectAltName: host “api3.cursor.sh” matched cert’s “api3.cursor.sh”
issuer: C=US; O=Google Trust Services; CN=WE1
SSL certificate verify ok.
using HTTP/2
[HTTP/2] [1] OPENED stream for https://api3.cursor.sh/
[HTTP/2] [1] [:method: GET]
[HTTP/2] [1] [:scheme: https]
[HTTP/2] [1] [:authority: api3.cursor.sh]
[HTTP/2] [1] [:path: /]
[HTTP/2] [1] [user-agent: curl/8.7.1]
[HTTP/2] [1] [accept: /]
GET / HTTP/2
Host: api3.cursor.sh
User-Agent: curl/8.7.1
Accept: /
Request completely sent off
< HTTP/2 404
< date: Fri, 20 Mar 2026 22:09:44 GMT
< content-type: text/plain; charset=utf-8
< content-length: 31
< server: cloudflare
< cf-cache-status: DYNAMIC
< cf-ray: 9df80af9fdef8d77-HEL
<
Connection #0 to host api3.cursor.sh left intact
The request could not be routed%
Why do I tell you this? Because I don’t want to update.
EVERY SINGLE TIME that you guys have told me to update to solve an issue that I’ve had, not only it doesn’t solve the issue, but it also introduces new problems for me…EVERY SINGLE TIME.
I’m afraid of Cursor updates by now, especially this 3.0 where you’ve changed so much. It took me so many headaches and effort to get used to the buggy version of Cursor that I currently have that I don’t want to disrupt that.
So, if I can reproduce the issue with a simple curl request, I don’t see the need for me to update and risk my setup stability.
I’ll only update when you tell me that the issue was fixed and doing curl -v https://api3.cursor.sh returns a non-404 code.