Two different ways to reach the same AI — including exactly why hundreds of users got banned in February 2026, and what keeps our setup safe.
| Step | What Happens | Location |
|---|---|---|
|
1
|
You type your message in the Antigravity chat panel | Your PC — local |
|
2
|
Press ▶ — passed to language_server.exe running as background process |
Your PC — local |
|
3
|
Language server checks your Google OAuth login token — nothing has left your PC yet | Your PC — local |
|
4
|
Bundles your message + open files + chat history + instructions | Your PC — local |
|
5
|
First internet request — HTTPS POST with your Gmail token + Antigravity app badge | Internet → Google |
|
6
|
Google validates Gmail identity, confirms badge, checks quota | Google servers |
|
7
|
Gemini model generates response, streams back word by word | Google → Your PC |
|
8
|
Words appear live in your IDE as they're generated | Your PC — display |
| Step | What Happens | Location |
|---|---|---|
|
1
|
You send Jack a Telegram message | Telegram — your app |
|
2
|
Telegram pushes it to Jack's VPS in Malaysia | Telegram → VPS |
|
3
|
OpenClaw receives it, checks if you're an allowed user | VPS — Malaysia |
|
4
|
Jack picks a google-antigravity/ model — retrieves OAuth token for the Faith Gmail
account |
VPS — Singapore |
|
5
|
First internet request — HTTPS POST with Faith Gmail token. No IDE badge attached. | Internet → Google |
|
6
|
Google validates the OAuth token (valid ✅) — notes: no badge, VPS IP, no streaming | Google servers |
|
7
|
Gemini model generates complete response and sends it back all at once | Google → VPS |
|
8
|
Jack sends reply to Telegram — you see his response in your chat | VPS → Telegram → You |
| Signal | 🔵 Antigravity IDE | 🟠 AUTH via VPS |
|---|---|---|
| Server endpoint | cloudcode-pa.googleapis.com | cloudcode-pa.googleapis.com |
| Auth credential | OAuth Bearer token | OAuth Bearer token |
| Whose Gmail? | Your main account | faithinmotion88@gmail.com |
| App badge (User-Agent) | ✅ antigravity/1.15.8 | ❌ No badge |
| Client-Metadata header | ✅ ideType: ANTIGRAVITY | ❌ Missing |
| IP address origin | Your home PC (residential) | VPS datacentre IP |
| IP expected for this account? | ✅ Consistent | 🟡 VPS — unusual |
| Streaming? | ✅ Always — SSE word by word | 🟡 Usually not |
| Request speed | Human-paced (seconds between) | Can be machine-paced (instant) |
| Intended use by Google? | ✅ Yes — this is the product | 🟡 Grey area (ToS) |
| Google links the two accounts? | — Different Gmail accounts — completely unlinked to Google — | |
A logical idea: make Jack send the same User-Agent: antigravity/1.15.8 and
Client-Metadata headers to appear as the real IDE. This is technically possible — but it makes
things significantly worse.
Google sees more than just headers. The badge is one signal of many. Spoofing it creates an impossible contradiction that is more suspicious than having no badge at all.
| Signal | With Spoofed Badge | Risk |
|---|---|---|
| Badge header | Says antigravity/1.15.8 |
✅ Passes |
| IP address | Still a VPS datacentre — residential IPs use Antigravity, not VPS servers | ❌ Contradiction |
| TLS fingerprint | Still Node.js/OpenClaw — the real IDE uses a different TLS stack | ❌ Mismatch |
| Request timing | Still instant/automated — no human think-time pauses | ❌ Anomaly |
| What Google concludes | Claims to be the official IDE — but every other signal contradicts it → detected as active impersonation | |
Grey area. No impersonation claim. Google sees: unknown client, valid token. Acceptable.
Active impersonation. Much harder to appeal. Changes from grey area to deliberate ToS fraud.
In February 2026, Google issued a mass ban wave affecting hundreds of OpenClaw users. Most victims had no idea why they were banned. Here is the full picture from forum reports and Google's own emails.
"Your account was found to be powering a non-Antigravity product using Antigravity backend infrastructure. This constitutes malicious usage and resource degradation for legitimate users."
| # | Trigger | Why It Got People Caught |
|---|---|---|
| 1 | Token abuse at machine speed | The IDE subscription assumes human-speed usage (~a few messages/min). Servers using AUTH sent dozens per second. Backend spikes were immediately visible to Google's monitoring. This was the primary trigger. |
| 2 | Concurrent sessions — two IPs at once | IDE open on home PC + OpenClaw running on VPS = same OAuth token active from two different IP addresses simultaneously. Google's session system detects this as an anomaly. |
| 3 | VPS datacentre IP | Residential IPs use Antigravity IDE. When authenticated requests started arriving from VPS IPs (datacentre ranges), the pattern was instantly abnormal. |
| 4 | No streaming on requests | The real IDE always uses SSE streaming. Non-streaming requests from the cloudcode-pa endpoint are a strong automated-usage signature. |
| 5 | Missing Client-Metadata badge | Supporting signal — every real IDE request includes {"ideType":"ANTIGRAVITY"}. Its
absence combined with the above signals confirmed automated non-IDE usage. |
Most people assumed adding the badge would fix the problem. It doesn't. The volume of requests, the VPS IP, and concurrent sessions were what triggered the ban. The badge was the least important signal. Keeping AUTH volume low is the only real protection.
Many users assumed only their Antigravity access would be blocked. Google's automated enforcement was broader:
| What Got Blocked | Expected? | Google's Stated Scope |
|---|---|---|
| Antigravity IDE access | ✅ Intended | Yes — primary target |
| Gemini CLI | ✅ Intended | Yes — same backend |
| Cloud Code Private APIs | ✅ Intended | Yes — same backend |
| Gmail | 🟡 Unintended | Automation error — some accounts affected |
| YouTube / Workspace | 🟡 Unintended | Automation error — fixed in late Feb unban |
The OAuth token from your IDE is tied to your personal Gmail with full cloud-platform scope.
Using it outside the IDE is an immediate ToS violation and risks your entire Google account. AUTH in OpenClaw
is safe only because it uses its own OAuth flow on a separate dedicated account.
| Rule | Why | Priority |
|---|---|---|
| Never use AUTH as Jack's primary model | Volume is the #1 ban trigger. Keep AUTH for occasional, high-value requests only. | Critical |
| Never use AUTH and IDE at the same time | Concurrent session detection — same OAuth token from two different IPs = immediate anomaly flag. | Critical |
| Never spoof the badge | Changes grey area to active impersonation. IP mismatch makes it impossible to sell regardless. | Critical |
| Keep Faith account isolated | If anything goes wrong, only that one account is affected — not Gmail, YouTube, or your main work. | Important |
| Don't run AUTH 24/7 | Automated server patterns are visible in Google's usage monitoring. Human-scale volume only. | Important |
| What Banned Users Did | What Our Setup Does |
|---|---|
| Used AUTH as their primary model for all conversations | ✅ AUTH is secondary/occasional only |
| Same Gmail account for both IDE and AUTH | ✅ Separate Gmail (Faith) for AUTH — zero overlap |
| High-volume automated requests at machine speed | ✅ Reasonable human-scale volume |
| IDE open + VPS AUTH running simultaneously from same account | ✅ Different accounts — no concurrent session conflict |
| Tried to fix by spoofing badge headers | ✅ We don't spoof — it makes things worse |
These are the best real sources to understand the Feb 2026 ban wave — forum threads, news coverage, and official responses. Read these to learn from other people's experiences.
These two sources give you the most complete picture of what happened, why, and the community response.
The original ground-zero threads where hundreds of users discovered and compared their bans. Includes the specific error messages, ban emails, and what users tried to appeal.
Search Reddit Threads →Best technical breakdown of why the bans happened — pricing arbitrage, token economics, and how OpenClaw's OAuth plugin created the backend spike that triggered enforcement.
Read Full Analysis →Tech media coverage including Google's official statements. Good for understanding the company's legal position and what they classify as a terms violation vs acceptable use.
Read Coverage →The HN thread contains developer-level analysis of Google's enforcement detection methods, TLS fingerprinting discussion, and the Account Remediation Pathway that was later announced.
Read HN Thread →Google's own dev forum posts where they clarified the policy — specifically recommending Vertex AI or AI Studio API keys for programmatic use instead of IDE OAuth tokens.
Antigravity Developers →Covers the broader industry trend — Anthropic blocked Claude Code third-party tools in Jan 2026, then Google followed in Feb. Shows this is a deliberate ecosystem lockdown across AI companies, not a one-off.
Read Coverage →Anthropic blocked Claude Code third-party integrations in January 2026 via client fingerprinting. Google followed in February. This is a coordinated industry shift — AI companies are actively closing the door on unofficial third-party access. Expect OpenAI and others to follow. The safe path long-term is official API keys, not OAuth arbitrage.