Antigravity completely stopped working (Dead silence/No response/Freeze)

Hey guys,

I’m on the Pro plan (provided by my university) and was using Antigravity heavily until mid-March. That’s when the first issue popped up: I had to wait over 4 days just to get access to Gemini 3.1 Pro again after a big code sprint… It seems like new limits were rolled out without any prior communication.

Then, around March 25th-26th, Antigravity just completely stopped working for me. I send a prompt and get absolutely nothing back—no response, no loading indicator, just dead silence.

Note: I’ve already tried reinstalling the IDE and using a browser with only a single Google account logged in. This issue persists across both my Windows and macOS machines!

If I were actually paying for this out of pocket (thankfully my university is), I’d be incredibly pissed off.

Does anyone know what’s going on with Antigravity? I had really high expectations for this product, and my coworkers were really enjoying it too. But with these silent limit changes and game-breaking bugs, it’s getting hard to defend.

Has anyone else run into this completely unresponsive bug? Any known fixes or workarounds?

:index_pointing_up: Just showing the "no response” after one test prompt..

12 Likes

Same issue, have no idea

4 Likes

Yeah me too , Ai doesnt reply

2 Likes

I found a workaround: Open Claude Code, have it locate the Antigravity installation folder, and describe the issue you’re facing. Once you grant it sufficient permissions, you’ll find the problem is resolved.

But what did Claude change? Was it some configuration or cache?

I’m having the same issue — I can’t send any prompts!

looks like a configuration file, but I don’t actually know what changes Claude made. It works!

It works, can’t believe it, the issue is about this:’core.repositoryformatversion does not support extension: worktreeconfig
Failed to resolve workspace infos
workspace infos is nil, it’s about my git repo, which has some trouble with Language server, change it, and everything will be ok!

2 Likes

100% same problem, google enjoy restict us more every update :blush:

I found the issue and the simplest fix.

Root cause: Your repo’s .git/config has the worktreeConfig extension enabled, but core.repositoryformatversion is set to 0 instead of 1. The worktreeconfig extension requires version 1.

Fix

Option 1 — Bump the format version (recommended if you need worktrees):

bash

git config core.repositoryformatversion 1

Option 2 — Remove the extension (if you don’t use git worktree):

bash

git config --unset extensions.worktreeConfig

Then retry generating the commit message or using Ai chat, should work fine after either fix.

9 Likes

I’m facing the same issue sometimes it works, but other times the chat just gets stuck and stops responding. It feels like every new Antigravity update brings even more bugs.

Same here. The issue started today. I’ve sent multiple prompts. No response.

Same issue, what the heck is wrong with the team - they are actively trying to ruin this product

exactly the same issue, my workround is logout and login again… but it’s quite annoying what it happended so frequently…

I’ve tried this on windows wsl, this doesn’t work. I’ll try claude magic fix then.

And as others have said.. Give Claude the path.. and that fast you are done IF you only have one repo. If two or more you need to get all of them up to speed. When Anthropic deployed worktrees… i suspect this made the complication.
I have attached the logs from my Claude so you can see what happened. I will replace repo 1 and repo2 for safe discussion sharing.

From Claude:
Let me look at the Antigravity installation and the article for context.

Ran 2 commands, loaded tools, searched the web

Ran 2 commands, loaded tools, searched the web

The issue is a git config conflict. Let me check the git config in the relevant location.

Ran 2 commands

Ran 2 commands

Found it. Your .git/config has exactly the problem described in the forum:

  • repositoryformatversion = 0

  • extensions.worktreeConfig = true

These are incompatible — extensions.* requires repositoryformatversion = 1. Antigravity (which is an Electron/VS Code-based app) fails to resolve workspace info because of this conflict.

The worktreeConfig extension was added by Claude Code’s worktree feature. The fix is to update the format version to 1:

Fix git repositoryformatversion to support worktreeConfig extension

Fix git repositoryformatversion to support worktreeConfig extension

Let me verify the fix:
Verify the fix

Verify the fix

Done. The fix: core.repositoryformatversion was 0 but extensions.worktreeConfig = true was set (added by Claude Code’s worktree feature). Git extensions require format version 1. Antigravity (Electron/VS Code-based) was choking on this mismatch with the error “core.repositoryformatversion does not support extension: worktreeconfig / Failed to resolve workspace infos.”

Updated it to 1. Restart Antigravity and it should work now. This is a safe change — version 1 just means “this repo uses extensions,” which it already does.

BTW it was working when only hooked to Repo 2 if that helps.. now we hooked up Repo 1 as well to antigravity.

Ran 2 commands

Ran 2 commands

There it is — the exact error in the logs from this session at 13:44:10:

core.repositoryformatversion does not support extension: worktreeconfig
Failed to resolve workspace infos
workspace infos is nil

The fix I applied was correct, but these logs are from the session before the fix. The fix was applied during this session. You need to restart Antigravity for it to pick up the new git config.

But you also mentioned it started failing when you “hooked up Repo2” (the Repo 2-app repo). That repo is the one with the worktreeConfig issue. Let me also check if there are other repos open in Antigravity that might have the same problem.

Ran 4 commands

Ran 4 commands

Two issues found:

  1. REPO 2 — has the fix (repositoryformatversion = 1) but also has a second repositoryformatversion = 0 under [lfs]. Let me check that.

  2. REPO 1 — also has worktreeConfig = true and likely the same version 0 conflict.

Check REPO 1 format version

Check REPO 1 format version

REPO1 has the same bug. Let me fix it too.

Fix REPO1 repositoryformatversion

Fix REPO1 repositoryformatversion

Both repos are now fixed. Here’s the summary:

Root cause: The Antigravity logs confirm exactly the error from the forum post:

core.repositoryformatversion does not support extension: worktreeconfig
Failed to resolve workspace infos
workspace infos is nil

What happened: Claude Code’s worktree feature added extensions.worktreeConfig = true to .git/config in both Repo 2 and Repo 1, but left repositoryformatversion at 0. Git extensions require version 1. Antigravity’s language server (Go-based) fails to resolve workspace info, which blocks the Gemini chat agent from getting context.

Fixed:

  • Repo 2app/.git/configrepositoryformatversion set to 1 (was 0)

  • Repo 1/.git/configrepositoryformatversion set to 1 (was 0)

Cheers and I hope it helps.

addendum… one more tweak

Still happening — 13:54:12 shows the same error. The language server has its own embedded git that’s not reading our fix. Let me check if Antigravity bundles its own git binary.

Ran 3 commands

Ran 3 commands

The fix is in the config but the error persists. The [lfs] section has a second repositoryformatversion = 0 — the Go git library might be reading that one instead. Let me check the full config.

Read 2 files

Read 2 files

The Go-based language server might be confused by the [lfs] repositoryformatversion = 0 line, or it might just be that worktreeConfig itself is the problem for this Go git library regardless of format version. Let me try the other fix from the forum — just remove the worktreeConfig extension entirely. Claude Code worktrees will still work (git added that config automatically).

Ran 2 commands

Ran 2 commands

Also remove the stale [lfs] repositoryformatversion that shouldn’t be there:

Remove stale lfs section

Remove stale lfs section

Let me verify the config is clean now:

Ran 2 commands

Ran 2 commands

Repo 1 has the same double-version issue. Let me check and clean it:

Ran 2 commands, read a file

Ran 2 commands, read a file

Both repos are now clean. Now fully quit and restart Antigravity again. The key change this time is

This is incredible. Claude confirmed and fixed this issue for me now, too.

I’ve noticed lately that the biggest bottleneck in my own progress is often the amount of time it takes me to realize I can ask Claude to look at this.

Maybe Google should be using Claude Code to develop Antigravity :smiley:

2 Likes

It turns out this wasn’t an AI model problem at all, but a repo-discovery failure. Because Antigravity is designed as an agentic platform that needs to understand your entire workspace to function, the whole pipeline stalls if its internal Git parser can’t resolve your repository metadata. In my case, the repo had the worktreeConfig extension enabled, which triggered a compatibility error because the platform’s parser didn’t support that specific Git extension.

The fix was to remove the extensions.worktreeConfig entry and run a prune to clean up stale metadata, reverting the repo to a standard format. The main trade-off is that I lost the ability to have unique Git settings for individual worktrees, though the worktrees themselves still function normally for standard development. If you’re seeing silent failures, it’s likely your repo metadata is confusing the workspace resolution logic.

For more context, the Google AI 2025 announcements explain Antigravity’s architecture as an agent-first platform that requires successful repository mapping to initiate tasks. You can also find technical details in the official Git documentation, which explains why certain parsers refuse the worktreeConfig extension to maintain compatibility with older repository formats.

2 Likes

I doubt anyone thought it was a AI model problem. I didn’t, anyway. The problem (and question) is: Why isn’t Antigravity handling this bad state responsively, rather than freezing / dropping requests on the floor? If you figured out the specifics of this issue, Antigravity should easily be able to. I hope they are adjusting the software to reflect this.