Antigravity IDE Server Crash immediately after upgrading to Google AI Pro

Google Antigravity
1

Hello,

I am experiencing a persistent server crash issue in Antigravity IDE immediately after upgrading my account plan. I need assistance in resolving this.

[Issue Description]
The Antigravity IDE was working perfectly fine while I was on the “Google AI Plus” plan. However, immediately after upgrading to the “Google AI Pro” plan, the IDE started displaying the error: “Antigravity server crashed unexpectedly. Please restart to fully restore AI features.”
The AI features are now completely unavailable, even though I am using the exact same Google account.

[Environment]

  • Antigravity IDE Version: 2.0
  • OS: Windows (Version 10.0.26200.8655)

[Error Log & Stack Trace]
The language server crashes immediately upon startup. The Output log shows the following:

Language server failed - listen tcp 127.0.0.1:0: listen: An attempt was made to access a socket in a way forbidden by its access permissions.

Here is the full log data:

2026-07-01 00:51:37.200 [info] F0701 00:51:37.200168 22012 main.go:2..] Language server failed - listen tcp 127.0.0.1:0: listen: An attempt was made to access a socket in a way forbidden by its access permissions.
2026-07-01 00:51:37.200 [info] (1) attached stack trace
2026-07-01 00:51:37.207 [info] – stack trace:
2026-07-01 00:51:37.207 [info] | google3/third_party/jetski/language_server/language_server.setUpServerPortListeners
2026-07-01 00:51:37.207 [info] | third_party/jetski/language_server/server.go:491
2026-07-01 00:51:37.207 [info] | google3/third_party/jetski/language_server/language_server.CreateLanguageServerAndServe
2026-07-01 00:51:37.207 [info] | third_party/jetski/language_server/server.go:1342
2026-07-01 00:51:37.207 [info] | main.main
2026-07-01 00:51:37.207 [info] | third_party/jetski/cmd/language_server/main.go:252
2026-07-01 00:51:37.207 [info] | runtime.main
2026-07-01 00:51:37.207 [info] | third_party/go/gc/src/runtime/proc.go:294
2026-07-01 00:51:37.207 [info] | runtime.goexit
2026-07-01 00:51:37.207 [info] | third_party/go/gc/src/runtime/asm_amd64.s:1736
2026-07-01 00:51:37.207 [info] Wraps: (2) listen tcp 127.0.0.1:0
2026-07-01 00:51:37.207 [info] Wraps: (3) listen
2026-07-01 00:51:37.207 [info] Wraps: (4) An attempt was made to access a socket in a way forbidden by its access permissions.
2026-07-01 00:51:37.207 [info] Error types: (1) *withstack.withStack (2) *net.OpError (3) *os.SyscallError (4) syscall.Errno

[Troubleshooting Steps Already Taken]
To isolate the issue, I have tried the following steps, but the error persists:

  1. Clean Installation: Completely uninstalled Antigravity 2.0/IDE, deleted all hidden caches, and reinstalled.
  2. WinNAT Restart: Ran net stop winnat and net start winnat via Command Prompt with Administrator privileges.
  3. Run as Administrator: Launched the IDE as Admin.

Since the issue strictly correlates with the plan upgrade, could you please investigate if there are any specific port requirements or authentication conflicts introduced in the Pro plan?

2

this actually looks more like a windows socket permission issue (firewall, antivirus, or a vpn blocking a new local port bind) rather than something the pro plan itself broke, the timing might just be a coincidence with a reauth/reinstall step. worth trying with security software temporarily disabled or on a different network to confirm. since you already tagged this as a bug, that should get it in front of the antigravity team for a closer look at the logs.

3

Thank you for the quick and insightful reply!

Your point about it being a Windows socket permission issue makes a lot of sense. It is very possible that the timing of the re-authentication or re-installation triggered a firewall or antivirus block, rather than the Pro plan itself causing the crash.

I will try temporarily disabling my security software and testing it on a different network to see if the local port bind succeeds.

Thank you also for confirming that the team will look into the logs. I’ll post an update here if I manage to isolate which specific security setting was blocking it.