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

Google Antigravity
22

Thank you. Upon executing the command git config --unset extensions.worktreeConfig within the macOS environment, I found it functioned flawlessly.

23

Same here solved runnning this command at repo level: git config --local --unset extensions.worktreeConfig

24

I used the option 1 command inside the terminal in a project folder and it came right back alive after exiting the chat window then clicking on a history chat or starting a new one.

25

i have been having same issues but was not the worktree fix mentioned above. according to claude i was having a git reflog issue.

Root cause: Corrupted git reflog entries for HEAD and refs/heads/main — these were causing git fsck to fail with “invalid reflog entry” errors

  • Why it killed agents: Agent tooling reads git state on startup; the corrupt reflog was likely causing crashes or undefined behavior before the agent could even begin work

  • Fix applied: Deleted the corrupt .git/logs/ directory and rebuilt fresh reflogs

  • Result: git fsck is now clean, repo is on main branch, up to date with origin

    this seems to have fixed the issue of my agents dying mid task.

26

Life saver, dude! was hard to understand why it was failing

27

Perfect, this cmd is helpful.

28

Hey everyone,

I’ve been experiencing the issue where typing a message in the Antigravity chat would immediately “complete” without actually sending it to the LLM too. The agent just wouldn’t respond at all.

Root cause: If you use Claude Code (or anything that creates git worktrees), it adds this to your .git/config:

[extensions]
    worktreeConfig = true

…and bumps core.repositoryformatversion from 0 to 1. This breaks Antigravity v1.21.x’s workspace/agent communication — the agent can’t properly resolve the workspace context and silently fails.

How to confirm this is your issue:

  • Chat works fine in other workspaces/directories

  • Your project’s .git/config contains worktreeConfig = true

Fix (run in your project directory):

git worktree prune
git config --unset extensions.worktreeConfig
git config core.repositoryformatversion 0

Then restart Antigravity. Chat should work immediately.

Optional cleanup: If you also have large .next/dev/cache or similar build caches, removing those can help with indexing performance too.

Hope this helps someone — took me a while to track down! :slightly_smiling_face:

29

Hello everyone!
Thank you for bringing this to our attention. We have escalated the issue to our internal teams for a thorough investigation.

To ensure our engineering team can investigate and resolve these issues effectively, we highly recommend filing bug reports directly through the Antigravity in-app feedback tool. You can do this by navigating to the top-right corner of the interface, clicking the Feedback icon, and selecting Report Issue.

30

this worked for me :slight_smile:

31

Thank you man! As soon as I ran “git config --unset extensions.worktreeConfig” in my terminal, the Agent started working. I started facing the issue as soon as I opened my project in Codex.

32

Temporary Fix for Antigravity Bug for Windows

If you are still encountering this issue, apply the following steps exactly:

  1. Uninstall Antigravity

    • Remove the current version completely from your system.

  2. Install a Stable Version

    • Go to: Google Antigravity – Releases

    • Download Version 1.19.6

      • Select: Windows x64 (.exe)

    • Install the downloaded version.

  3. Disable Auto-Updates (Critical Step)

    • Open Antigravity

    • Navigate to:

      • Settings icon (top-right, beside profile)

      • → Editor Settings

      • → Application

      • → Update

    • Apply the following:

      • Uncheck: Enable Windows Background Updates

      • Set Mode to: None

Result

Prevents Antigravity from updating to newer versions where the bug exists.

33

Confirmed: Resolving a Git worktree conflict by unsetting extensions.worktreeConfig and resetting core.repositoryformatversion to 0 restored LLM activity and indexing in Antigravity v1.21.0.

In a repo where I’ve been running Claude and Codex worktrees and using Antigravity for reviewing work, second opinions, etc., I got dead silence from Antigravity after restarts, changing models, etc. Found the suggestion to:

```bash
git worktree prune
git config --unset extensions.worktreeConfig
git config core.repositoryformatversion 0
```
And restart Antigravity. This worked.

34

None of any mentioned thing worked for me.

This issue appeared on 5 or 6 of Apr. When I was working on my project. I tried many things, restarted many times, started new chats, signout and signin but nothing worked. I was not using Claude Code simultaneously, and never had installed in it.

Now I see some of the users said it happened due to claude code require such configuration that made conflicts with the Antigravity environment.

Today I created a new project, cloned a fresh repo from the internet, never opened that project in any of the IDE that is use (Cursor, VS Code Github Copilot etc.), first time opened in Antigravity. But still same issue.

Still tried the ways mentioned by the members but nothing worked. The behavior is still as it was.

THE BEHAVIOR:

  • When a prompt is send, it waits for a while and no reponse being generated.
  • A sound beeps that indicates the complition of the prompt but as we know it gives nothing.
  • No LLM thinking for the prompt.

If anyone helps me get out of this, I will be really thankful. Thanks in advance.

35

I got Antigravity working again, and in my case the fix had nothing to do with reinstalling the IDE or logging in/out.

What finally solved it was using Codex to inspect Antigravity’s local logs and my repo’s Git metadata.

Symptoms:

  • Antigravity would accept prompts but show no loading state and no reply
  • “Generate Commit Message” would also silently fail
  • Reinstalling Antigravity and extensions did not help

What Codex found:

  • Antigravity logs were failing on workspace resolution
  • My repo had a Git/worktree metadata mismatch
  • .git/config contained:
    • extensions.worktreeConfig = true
    • plus repo/worktree state that Antigravity could not resolve cleanly
  • I also had a stale nested worktree folder with a dead .git pointer

In my case, the durable fix was:

git worktree prune
git config --unset extensions.worktreeConfig
git config core.repositoryformatversion 0

Then I removed the orphaned nested worktree folder that was still inside my workspace but no longer existed in Git’s admin data, restarted Antigravity, and it started working again.

Important caveat:

  • If you actively rely on per-worktree Git config, don’t blindly remove extensions.worktreeConfig
  • First check whether you actually use it
  • If you do, you may want to try:
git config core.repositoryformatversion 1
  • But in my case that alone was not enough

What to check if you think you have the same issue:

git config --get core.repositoryformatversion
git config --get extensions.worktreeConfig
git worktree list --porcelain

If Antigravity’s logs mention things like:

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

then this is probably a repo Git metadata problem, not an account/reinstall problem.

What helped most:

  • instead of guessing, I used Codex as a local debugger to inspect the Antigravity logs and the repo’s .git/config
  • that made the root cause obvious very quickly

Prompt other users can send to Codex or another local AI agent:

Antigravity is silently failing in this repo. Please debug it locally from disk truth, not by guessing.

Check these things in order:
1. Read Antigravity’s local logs and look for workspace-resolution or git/worktree errors.
2. Inspect this repo’s `.git/config` and report:
   - `core.repositoryformatversion`
   - `extensions.worktreeConfig`
3. Run `git worktree list --porcelain`.
4. Scan for orphaned nested worktree folders inside this workspace (for example `.claude/worktrees/*`) whose `.git` file points to a missing target under `.git/worktrees/*`.
5. If you find the Antigravity failure signature involving `worktreeconfig`, fix it by:
   - running `git worktree prune`
   - unsetting `extensions.worktreeConfig`
   - setting `core.repositoryformatversion` to `0`
   - removing only orphaned nested worktree folders with dead `.git` pointers
6. Restart Antigravity and re-check the newest log session to confirm these errors are gone:
   - `worktreeconfig`
   - `Failed to resolve workspace infos`
   - `workspace infos is nil`

Be careful not to delete live worktrees or unrelated files. Show me the exact root cause you found and the exact changes you made.

Use these guardrails so Antigravity does not silently break again on Git/worktree metadata:

  • Keep .git/config in an Antigravity-safe state:
    • core.repositoryformatversion = 0
    • no extensions.worktreeConfig unless you truly need per-worktree Git config
  • Run git worktree prune occasionally, especially after deleting or moving worktrees manually.
  • Remove orphaned nested worktree folders inside the workspace, especially under paths like .claude/worktrees/, if their .git file points to a missing target.
  • If Antigravity goes silent, check logs for:
    • worktreeconfig
    • Failed to resolve workspace infos
    • workspace infos is nil
    • core.repositoryformatversion does not support extension: worktreeconfig
  • If those errors appear, treat it as a repo Git-metadata issue first, not an IDE reinstall/account issue.
  • Add a local guardrail check that verifies:
    • git config --get core.repositoryformatversion
    • git config --get extensions.worktreeConfig
    • git worktree list --porcelain
    • no dead .git pointers inside nested worktree folders
36

Thank you so much… Unfortunately, none of the commands or method worked for me for the resolution of the issue. But you literally helped to narrow down to the actual issue.

Here is the last output of the codex prompt that you gave:
```
Requested Checks

Initial repo config:

  • core.repositoryformatversion: 1
  • extensions.worktreeConfig: unset

git worktree list --porcelain:

worktree /home/a-sajjad72/my-projects/pip
HEAD 76fc13665a3281045f60a1729e747096af77c2fc
branch refs/heads/main

Nested/orphaned worktrees inside this workspace:

  • none found
  • nothing was deleted

Changes Made

I made exactly these changes:

  • Ran git worktree prune
  • Attempted to unset extensions.worktreeConfig
    • there was nothing to unset
  • Set core.repositoryformatversion back to 0

Current .git/config:1:

  • core.repositoryformatversion = 0
  • extensions.worktreeConfig absent

Restart Verification

I launched a fresh Antigravity session. Newest session:

  • /home/a-sajjad72/.config/Antigravity/logs/20260414T203220:1

Re-check of that session:

  • no matches for worktreeconfig
  • no matches for Failed to resolve workspace infos
  • no matches for workspace infos is nil

Fresh repo-open evidence:

  • /home/a-sajjad72/.config/Antigravity/logs/20260414T203220/window1/exthost/
    vscode.git/Git.log:7 shows the repo opened successfully
  • /home/a-sajjad72/.config/Antigravity/logs/20260414T203220/window1/exthost/
    google.antigravity/Antigravity.log:1 contains no workspace-resolution/
    worktree errors

Remaining unrelated issue in the new session:

Antigravity still has 401 Unauthorized backend/auth errors in its extension
log, but the git/worktree/workspace-resolution errors you asked about are
gone.
```

The 401 Unauthorized issue reported by the codex was the real culprit. But the main issue was, Antigravity had never told me about that, no indication of expired session etc. nothing.

Even I see my profile logged in, my profile picture on the top right. and nothing related to re-sign instructions.

I don’t know whether i had same issue, with the worktree configs or it was related to only session expiration. Might be the issue was resolved by those commands which I ran earlier, and I was still getting it because of the session expire.

Anyways, thank you, you really made my day.

37

This also worked for me. Option 1 did not.

38

Hello. I had the same issue, working with both Antigravity and Claude Code.
Here’s a recap of the fix. And of course, I updated claude.md accordingly afterwards!

Antigravity silent in one project — cause and fix

If Antigravity stops responding to prompts in a specific project (while working fine in others), check your .git/config for this combination:

[core]

repositoryformatversion = 0

[extensions]

worktreeConfig = true

Root cause: Claude Code’s worktree feature adds extensions.worktreeConfig = true to .git/config whenever it creates an isolated worktree for parallel work. Git extensions require repositoryformatversion = 1, but more importantly, Antigravity’s Go-based language server doesn’t support the worktreeConfig extension at all. It fails silently with workspace infos is nil in the logs, which blocks the Gemini chat agent from getting any project context — hence the silence.

Fix:

  1. Remove all stale worktrees:
git worktree list

git worktree remove --force .claude/worktrees/<name> # repeat for each

git worktree prune

  1. Clean up .git/config — remove the [extensions] block entirely and reset the format version:
[core]

repositoryformatversion = 0

# remove the [extensions] block

  1. Restart Antigravity.

To confirm the issue: check ~/Library/Application Support/Antigravity/logs/<session>/ls-main.log and look for:

core.repositoryformatversion does not support extension: worktreeconfig

Failed to resolve workspace infos

workspace infos is nil

Prevention: avoid any tooling that calls git worktree add in projects where you also use Antigravity.

39

Confirming the fix + identifying the root trigger: Claude Code worktrees

Same issue here (STUCK for 3 days!!), fixed by removing worktreeConfig = true from .git/config.

What I can add: the exact cause in my case was Claude Code (Anthropic’s CLI/IDE agent). When Claude Code creates an isolated worktree via its isolation: "worktree" parameter, it automatically writes this to .git/config:

[extensions]
    worktreeConfig = true

It does not clean this up after the worktree session ends. The orphan worktree directory can be removed, but the [extensions] block stays in .git/config — and that’s what silently crashes Antigravity’s Go language server.

Diagnostic (30 seconds):

grep -n "worktreeConfig" .git/config

If it returns a line → that’s your culprit.

Fix:
Delete the entire [extensions] block from .git/config. Antigravity will work again immediately on next VS Code reload.

Prevention:
After any Claude Code session on a git repo that uses Antigravity, run the grep above. If the line is present, remove it.

The issue lasted 3 days on my end before I connected it to Claude Code worktrees. Hope this saves someone the same debugging time.

40

thank you , you are right, mine was Claude Code added extensions.worktreeconfig=true to your Git config (for its worktree-based parallel editing), but your repo’s core.repositoryformatversion was 0, which doesn’t support extensions. The Antigravity language server tries to read your Git repo info on startup, hits this incompatibility, fails with “core.repositoryformatversion does not support extension: worktreeconfig”, and silently gives up — causing it to never respond.

41

omg i thought i was the only one, i am on ultra plan right now