Thanks bro. with your second option it worked for me.
Same issue, i type “Hello” and agent does not respond. Love Google but I cannot waste my time so going back to Claude Code and Cursor.
This happens a lot - in my case, i have to kill the antigravity server running locally or on remote hosts. Then chats start working again.
The testing and quality of this project is mad. This is a scriptkiddie intern project, it’s absolutely mind boggling it has been allowed to ship in this state.
Here is exactly what is going on and why your Antigravity agent has suddenly given you “dead silence”:
The Bug Explained
Claude Code operates in isolated environments by creating git worktree sessions. When it does this, it automatically modifies your repository’s .git/config file to include a specific setting: extensions.worktreeConfig = true. Normally, Claude Code cleans this up when you’re done, but if a session terminates abruptly, the setting gets left behind permanently.
Antigravity (specifically its internal Language Server) uses a strict internal Git parser that does not currently support the worktreeConfig extension. When you open a folder in Antigravity that has this flag left behind in the .git/config, Antigravity crashes internally without giving you a visible error message. It fails to load the workspace info, which causes your AI agent to freeze and silently drop all prompts.
How to Fix It
The forum users are completely right. To fix the bug, you just need to remove that unsupported Git extension from your configuration so Antigravity can read your repository again.
-
Open your terminal in the root of the affected project folder.
-
Run the command the forum recommended to remove the problematic setting:
Bash
git config --local --unset extensions.worktreeConfig -
(Optional but recommended) Since the
worktreeConfigextension required changing the repository format version, you should also safely revert that format version back to0so you don’t get mismatch errors:Bash
git config core.repositoryformatversion 0 -
Restart Antigravity completely (or hit
Cmd/Ctrl + Rto reload the window).
Once you restart, the Antigravity language server will boot up properly, successfully read your Git folder, and your agent will start responding to prompts again!
(Note: This fix is completely safe. Claude Code will just automatically recreate the settings it needs during its next active session.)
After you do git config --unset extensions.worktreeConfig. Then restart the antigravity, your first prompt should be “antigravity is unresponsive 98/100 of the time find and fix it.”
Thankyou so much for this! I’d asked Claude to review a repo and not made the connection that it had killed Antigravity as a result…just assumed Google were having yet more server problems. This fixed it!
This fixed it for me!
I ran into an issue in Antigravity on Windows where the agent would stop responding only in certain project folders. If I switched to a different project, the agent worked normally again. The problem turned out not to be the project itself, but the Git configuration of that repo.
In the broken projects, this setting was enabled in .git/config:
[extensions]
worktreeConfig = true
Antigravity logs showed errors like:
core.repositoryformatversion does not support extension: worktreeconfig
Failed to resolve workspace infos, continuing without: core.repositoryformatversion does not support extension: worktreeconfig
workspace infos is nil
So Antigravity was failing to read workspace information for repos using extensions.worktreeConfig, which caused the agent to hang or not respond.
I verified it with these safe read-only commands:
git rev-parse --git-dir
git rev-parse --git-common-dir
git config --show-origin --get extensions.worktreeConfig
git worktree list
In my case:
extensions.worktreeConfigwastruegit worktree listshowed only a single worktreegit statuswas clean
The fix was:
git config --local --unset extensions.worktreeConfig
After that, reopening the project in Antigravity made the agent work again.
Important note:
Only do this if git worktree list shows a single normal worktree. If the repo is actually using multiple worktrees intentionally, removing that setting may not be appropriate.
Short version:
If Antigravity only freezes in specific repos, check whether that repo has extensions.worktreeConfig=true. Disabling that setting fixed it for me.
That’s amazing! It’s fixed! Thank you!
In my case I am not able to “CANCEL” as well. Nothing works for me as well
The bug lasts for more than a month and it’s still not fixed. Is antigravity a discontinued product?
I have the same issue, the fixes above do not work for me. I added an .antigravityignore as well to exclude large files, but it will not work. I hope Google provides a fix soon. Weirdly enough, one conversation is still working and does not freeze. This is the thread I am hanging on.
My problem was different, that’s the logs I got from Antigravity:
[error] [LS Main stderr] E0430 14:15:59.310288 73858 log.go:398] failed to check terminal shell support: internal: internal error
[error] [LS Main stderr] E0430 14:15:59.326099 73858 log.go:398] unexpected end of JSON input
I had to remove two lines from my ~/.zshrc related to the autocomplete:
autoload -U +X bashcompinit && bashcompinit
complete -o nospace -C /opt/homebrew/bin/terramate terramate
After that, it started working
I used Gemini-cli to troubleshoot and solve the issue
Edited:
I also had to remove those lines:
if [ -f ‘/usr/local/google-cloud-sdk/path.zsh.inc’ ]; then . ‘/usr/local/google-cloud-sdk/path.zsh.inc’; fi
if [ -f ‘/usr/local/google-cloud-sdk/completion.zsh.inc’ ]; then . ‘/usr/local/google-cloud-sdk/completion.zsh.inc’; fi
And solve an MCP server issue. The MCP name must not have a space. Antigravity doesn’t raise an error when trying to start it. It fails silently.
Thanks Issue is resolved
Same approach worked for me as well. Win 11, one repo - many IDEs/Agents conflicting with Antigravity’s inability to support extensions.worktreeConfig = true.
Because the problem of freezed Antigravity Agent is not solved by Google and returns, I ended with adding these lines into my AGENTS.md:
### Lesson Learned (2026-04-30) - Antigravity Agent Failed On Git worktreeConfig Extension
**What went wrong**: Antigravity Agent did not start even after standard Git checks looked healthy. The Antigravity language-server log showed `core.repositoryformatversion does not support extension: worktreeconfig`, followed by `workspace infos is nil`.
**Why it happened**: Shared IDE-agent usage left the repo in a Git shape Antigravity could not parse: `extensions.worktreeConfig=true` remained in `.git/config`, multiple Codex/Claude/Kilo worktrees were registered, some generated worktree paths had been tracked as `160000` gitlinks without matching `.gitmodules` entries, and the local Git metadata also contained a stale commit-graph plus a stale remote-tracking reflog reference. Plain `git status` and later `git fsck` could pass before Antigravity was actually compatible.
**Correct approach**: Diagnose Antigravity startup from its own logs first, then repair Git metadata in layers: quarantine generated commit-graph caches instead of deleting source files, expire stale reflog references only after identifying the offending ref, remove malformed generated-worktree gitlinks from the index or add real `.gitmodules` mappings, verify `git submodule status --recursive`, and finally unset `extensions.worktreeConfig` only after inspecting `.git/worktrees/*/config.worktree` for settings that need preservation.
**How to avoid**: Do not put generated agent worktrees under tracked repo paths, and keep `.claude/worktrees/`, `.kilo/worktrees/`, and similar agent worktree roots locally excluded. When Antigravity fails to start, check the newest Antigravity `ls-main.log` for `worktreeconfig`, `workspace infos is nil`, or Git parser errors; do not stop at `git status`. Before enabling Git worktree extensions in this repo, confirm Antigravity supports them or keep Antigravity on a repo clone that does not use per-worktree Git config.
### Lesson Learned (2026-05-04) - Prefer VS Code ignoredRepositories For Source Control Worktree Clutter
**What went wrong**: After repairing the Antigravity `worktreeConfig` failure, VS Code Source Control still listed many clean assistant worktrees from Codex, Claude, and Kilo roots. The visible symptom looked like repo dirt, but most entries were registered Git worktrees with zero uncommitted changes, not tracked files in the main worktree.
**Why it happened**: Git still had multiple registered detached worktrees under external assistant roots, so VS Code discovered and displayed each one as a repository. A broad `git worktree remove --force` would have made the UI quiet, but it would also delete those worktree directories and risk discarding detached assistant state.
**Correct approach**: First separate three cases: malformed `160000` gitlinks in the main index, registered clean worktrees in `.git/worktrees`, and actual dirty user work. Remove malformed generated-worktree gitlinks from the index when needed, but for Source Control clutter prefer a non-destructive `.vscode/settings.json` `git.ignoredRepositories` list for known generated worktree paths. Reload VS Code or Antigravity after changing the setting.
**How to avoid**: Do not use destructive worktree cleanup just to fix SCM visibility. Before deleting any worktree directory, run `git worktree list --porcelain` and per-worktree `git status --short`; if the issue is only Source Control noise, hide the generated worktree repositories in editor settings instead.
So far it works even w/o reloading Lang Server
The same issue affects me, though in my instance, it is solely observed within a workspace.
Hi everyone.. the solution is to delete C:\Users\user\.gemini\.antigravity (hidden folder).
The problem is the cache token.
You’re welcome
Deleting the .antigravity cache did not solve it for me.
I figured it was repo related though - I tried to remove every cache and config, as well as adjusting the worktree config.
Still did not work.
I removed and cloned the repo again, since then it is working.
This fixed it for me, thank you! @demigod