"code": 400 "User location is not supported for the API use"

,

Hi there,

I am no longer able to use Antigravity on mac since a few hours, i just keep getting “User location is not supported for the API use.” no matter what i do, no matter which model i choose!

User Tier: Google AI PRO Subscriber Product: Google Antigravity (Agentic IDE) Impact: Total blocker; unable to generate code or run logic flows.

Issue Description: I am experiencing a persistent error where Antigravity fails immediately upon generation. Despite having an active Pro subscription and stable internet connection, the agent hangs or errors out regardless of the prompt complexity.

I’m getting the same error, but only with Gemini. Claude works fine. I don’t understand what’s going on or how to fix it. There’s no information anywhere.

Have you found a solution?

Reverting antigravity to version 1.22.2 fixes the issue, but it’s not an ideal solution—even though it works. I hope Google addresses this problem soon; I suspect that leftover authentication data from the older version is interfering with the new version, which appears to use a different authentication mechanism.
Maybe u could try completely uninstalling it and then reinstalling the latest version.

Great, reverting can solve it.

Today they banned work through version 1.22

Is there a solution yet?

I also have this issue when using Gemini.

yes, thats the problem

I did it! Struggled for 2 weeks! Found the solution!

:hammer_and_wrench: Fixing Error 400 (User location is not supported) in Antigravity 1.23.2 (WSL)

Why does this error occur?

If you are getting this message, it means your actual region is not supported by Antigravity (Gemini) services for some reason. To bypass this restriction, a VPN is strictly required. For example, I use a US server (Miami, Florida).

However, if you’ve turned on your VPN and the 400 error still persists, the problem lies in a traffic leak.

The technical core of the issue:

In the 1.23.2 update, requests to the AI models started routing directly. If you are working on Windows via the Windows Subsystem for Linux (WSL), a conflict arises: WSL ignores Windows system proxies by default. As a result, your browser connects through the US, but the hidden agent inside WSL sends traffic directly through your local ISP. The security system detects your real IP and drops the connection.

The Solution: Strict Tunneling (using Happ, v2rayN, NekoBox as examples)

A regular proxy mode is no longer enough. You need to intercept absolutely all system traffic at a low level.

  1. Go to your VPN/proxy client settings.

  2. Enable TUN Mode.

  3. In the routing settings, select the gVisor (or Strict/Global) mode.

    Important: “Mixed” or “System” modes will not work — WSL will route traffic past the tunnel again!

  4. Enable the DNS for TUN option and set the address to 1.1.1.1 (to prevent location leaks via your ISP’s DNS).

  5. Turn the connection off and back on in your app to apply the new settings.

  6. Mandatory step: Open PowerShell and enter the following command to force restart the Linux network:

    Bash

    wsl --shutdown
    
    
  7. Restart Antigravity — the agent should be working again.

If you use a classic VPN (Outline, Amnezia, etc.):

These inherently work as a tunnel. To avoid issues, simply disable the IPv6 protocol in your Windows network adapter properties, set the IPv4 DNS to 1.1.1.1, and don’t forget to run the wsl --shutdown command.