It bypasses one Google regional check on Windows
Antigravity exists for one reason: Google's Antigravity coding products can reject users based on location, including users in Russia. This Windows unlocker changes how the installed software identifies the restriction and how a small set of Google hostnames resolve. The README is entirely in Russian, as are the release notes and support links. There is no English guide for an international reader to fall back on.
The scope is narrower than a VPN. According to the README, the tool renames one same-length field in the protobuf descriptor inside language_server.exe or agy.exe, changing ineligible to inexigible. It then adds Windows Name Resolution Policy Table rules for the Google endpoints used by Antigravity. If the computer lacks a global IPv6 address, it also gives IPv4 higher priority. A full rollback command is available from the menu.
That approach has an appealing property: ordinary DNS traffic and unrelated Google services keep using the normal resolver. Only the named Antigravity endpoints take the alternate path. It also means the program touches both an installed vendor binary and system networking. A user has to be comfortable with those changes before the convenience matters.
Public source and private release material
The repository is open enough to inspect the patching, DNS, background relay, and rollback code. The public build compiles, and the README says its DNS route can unlock Antigravity by itself. The downloadable release has another path that is intentionally absent from Git: the fast relay address and its access key live in an excluded file.
That split weakens reproducibility. A developer can review and build the DNS-only version, or download the maintainer's binary to receive behavior that cannot be recreated entirely from the repository. The README explains the difference plainly, which is better than hiding it, but the trust decision remains. The project also has no declared repository license in GitHub's metadata, so the ability to read the code should not be confused with clear permission to redistribute modified builds.
End users need a free license code from a linked Telegram group. One open issue questions the purpose and strength of that code system and includes a script that generates keys for an earlier version. Whatever the maintainer's reason, a Telegram dependency is awkward for automated deployment and for organizations that need a documented software intake process.
What happened when we ran it
We cloned commit 85200bb into a fresh Debian container with three CPUs, 12 GB of RAM, Rust tooling, and no secrets. Dependency installation succeeded in 15 seconds with 57 packages installed. The build succeeded in 35 seconds. The test command ran for 13 seconds, then exited with code 101: 220 tests passed and 4 failed out of 224.
The supplied log tail names two failures in the background module: the_log_stays_in_the_user_profile and the_relay_is_installed_outside_the_user_profile. The second shown panic occurred at src/background.rs:274 because an assertion expected program_data to be non-empty. That log does not identify the other two failures or establish why the environment value was empty, so we cannot assign a cause. It does show that the full suite is not portable to our fresh Debian sandbox as written.
A successful Linux build is useful evidence about source integrity, though it does not exercise the Windows system changes that define the product. The repo has no CI workflow, Dockerfile, or top-level tests directory. Given the failed suite and platform-specific behavior, a Windows test matrix would make releases easier to trust.
The system changes deserve scrutiny
Patching the language server is deliberately small: the replacement string has the same length, so the file's size and structure stay unchanged. Small does not mean stable. A Google update can move or remove that descriptor, replace the binary, or add another eligibility check. The unlocker includes logic intended to survive updates, yet each upstream release can change the assumptions it depends on.
Selective DNS is also a trust exchange. The README names xbox-dns.ru as the resolver for two Google hosts. Source comments at the measured commit discuss a local relay, resolver health, cached answers, and fallbacks. DNS replies for those names influence where the Antigravity client connects. Users should decide whether that third party is acceptable and test that rollback removes the NRPT rules.
The project tells nervous users to run the binary in a virtual machine because antivirus products may flag unsigned or unfamiliar executables. That is sensible advice. A VM also limits the damage from a bad patch, a broken rollback, or a release that behaves differently from the public source. It cannot make an opaque relay trustworthy, but it gives the unlocker a smaller blast radius.
Version v2.10.0_3 still depends on Google and private relay details
The repository was pushed on August 26, 2026, and release v2.10.0_3 arrived later that day. Its notes add another fast route and fix repeated reconnections after 10 idle seconds, a silent route address, and a dead proxy that previously delayed fallback by 15 seconds. GitHub listed 7 issues and pull requests combined, including reports that the bypass had stopped and requests for Linux or macOS support.
That activity shows a maintained workaround, not a settled utility. Its job depends on behavior controlled by Google and on outside DNS or relay infrastructure. A release can repair connection handling without making the private relay address and key reproducible from source. There is still no CI workflow showing which platforms pass before publication, and our 13-second Rust suite ended with 4 failures.
Use Antigravity only when the exact regional block is your problem, Windows is disposable enough to modify, and you have reviewed the trust boundaries. A normal VPN or self-hosted tunnel is easier to reason about for work machines because it avoids patching the Google installation and does not require the maintainer-only fast route.