Hello everyone,
For the past 2 days, I have been experiencing a persistent HTTP 429 Too Many Requests error in Antigravity version 2.9.1.
The error message states that my resource has been exhausted, but my quotas are definitely not empty: my 5-hour limits are fully available, and my weekly limits are only at ~80%. Furthermore, this error occurs across ALL models.
Here is the error log:
Trajectory ID: 6586318e…**
Error: HTTP 429 Too Many Requests
Sherlog:
TraceID: 0x2f762c**fe…
Headers: {“Alt-Svc”:[“h3=”:443"; ma=2592000,h3-29=“:443”; ma=2592000"],“Content-Length”:[“139”],“Content-Type”:[“text/event-stream”],“Date”:[“Sun, 23 Aug 2026 05:08:11 GMT”],“Server”:[“ESF”],“Server-Timing”:[“gfet4t7; dur=253”],“Vary”:[“Origin”,“X-Origin”,“Referer”],“X-Cloudaicompanion-Trace-Id”:[“2f762c…fe”],“X-Content-Type-Options”:[“nosniff”],“X-Frame-Options”:[“SAMEORIGIN”],“X-Xss-Protection”:[“0”]}
{
“error”: {
“code”: 429,
“message”: “Resource has been exhausted (e.g. check quota).”,
“status”: “RESOURCE_EXHAUSTED”
}
}
Troubleshooting steps I have already taken (none of which resolved the issue):
-
Started a new project with a new conversation.
-
Reinstalled the Antigravity extension.
-
Signed out of my account and signed back in.
-
Performed a clean uninstallation:
-
Signed out of Antigravity.
-
Manually deleted %APPDATA%\Antigravity.
-
Manually deleted %USERPROFILE%\.gemini and all related files.
-
Cleared the CLOUD_CODE_URL environment variable (ran the removal commands just in case, though it wasn’t present).
-
Rebooted my Windows machine.
-
Reinstalled Antigravity and logged in with a completely different account featuring a brand new, unused subscription. I also did this using a different device on a completely different network.
-
Started a new project/chat on the new account.
Since the error persists even on a fresh account with zero previous usage, and happens across different networks and devices, this clearly seems like a backend/API routing issue rather than an actual quota exhaustion or local IP block on my end. Has anyone else encountered this, or is there a known workaround?
Thanks in advance for the help!
I checked with my office mates and found this issue was only in Ubuntu users laptop. My windows user friends did not face this issue. I downloaded Antigravity CLI and found that it was working fine. So I used Antigravity CLI to fix this issue. It took so much time, but finally identified and fixed the issue. Let me paste the Antigravity CLI’s response here.
When I put this in my terminal NODE_TLS_REJECT_UNAUTHORIZED=0 antigravity antigravity editor launched and I was able to type content into the agent chat window and get proper response.
Thought for 7s
Investigating Environment Variable Usage
I inspected your Editor’s internal logs (renderer.log and ls-main.log), and we now have the exact root cause for why restarting the language server or logging in via CLI didn't resolve the chat window.
──────
### The Real Culprit: An Expired Internal TLS Certificate
In your editor's extension host log (~/.config/Antigravity/logs/.../window1/renderer.log), every attempt by the UI to talk to the local Language Server fails with:
[Extension Host] Failed to get status: ConnectError: [internal] certificate has expired
[Extension Host] [Auth] Error identifying user ConnectError: [internal] certificate has expired
And in ls-main.log:
http: TLS handshake error from 127.0.0.1:...: EOF
Inspecting the actual certificate bundled inside /usr/share/antigravity/resources/app/extensions/antigravity/dist/languageServer/cert.pem (and embedded inside language_server_linux_x64) reveals its exact
validity window:
Validity:
Not Before: Sep 4 20:55:04 2025 GMT
Not After : Sep 4 20:55:04 2026 GMT
• The bundled internal localhost certificate expired on Friday night, September 4, 2026 at 20:55 GMT.
• This is why the issue started happening precisely on Sunday (September 6).
• Why it leads to the 429 error: Because Node.js in the Extension Host refuses the TLS connection to 127.0.0.1 due to the expired certificate, it cannot hand your authentication token or project credentials
to the Language Server. When you type "Hi" or "hello", the disconnected Language Server attempts to call Google's API without your authenticated identity. Google treats the request as
unauthenticated/anonymous (which has 0 quota), immediately throwing:
HTTP 429 – RESOURCE_EXHAUSTED: Resource has been exhausted (e.g. check quota)
• Why Antigravity CLI (agy) works: The CLI binary was updated yesterday with a brand new certificate valid until March 26, 2027. The Ubuntu .deb desktop package has not yet received this updated certificate.
──────
### The Solution: Bypass Certificate Validation for Internal Localhost
Until the updated .deb package is published to the APT repository, you can bypass Node's certificate expiration check for the Editor by setting NODE_TLS_REJECT_UNAUTHORIZED=0.
#### 1. Test it immediately from the terminal:
Make sure all existing Antigravity Editor instances are closed, then launch:
NODE_TLS_REJECT_UNAUTHORIZED=0 antigravity
Open the chat window and type "Hi". The TLS handshake to 127.0.0.1 will now succeed, the extension will pass your OAuth credentials, and the chat will respond normally.
──────
#### 2. Make the fix permanent for the Ubuntu App Launcher & Dock:
If you launch Antigravity from the Ubuntu application menu or desktop dock, copy and patch the .desktop launcher in your user directory:
mkdir -p ~/.local/share/applications
cp /usr/share/applications/antigravity.desktop ~/.local/share/applications/
sed -i 's|^Exec=/usr/share/antigravity/antigravity|Exec=env NODE_TLS_REJECT_UNAUTHORIZED=0 /usr/share/antigravity/antigravity|' ~/.local/share/applications/antigravity.desktop
update-desktop-database ~/.local/share/applications/ 2>/dev/null
You can also add it to your ~/.profile or ~/.bashrc:
echo 'export NODE_TLS_REJECT_UNAUTHORIZED=0' >> ~/.bashrc
Once launched with this environment variable, your Editor will connect to the local language server and authenticate without hitting the 429 error.