Antigravity 1.21.6 on macOS appears to break when the opened workspace is a Git worktree repo whose main `.git/config` contains:
[extensions]
worktreeConfig = true
Observed behavior:
Agent UI becomes effectively unusable / silent
Requests stall or terminate without useful output
Repeated backend errors appear in Antigravity logs
Important log lines:
`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`
`GetAgentScripts (unknown): core.repositoryformatversion does not support extension: worktreeconfig`
`run state not found`
What I verified locally:
This is not a normal Git failure. Git itself handles the worktree fine.
The breakage happens specifically in Antigravity’s workspace/agent handling.
Removing `extensions.worktreeConfig` from the repo makes Antigravity usable again.
Re-enabling it in a proper Git shape still causes Antigravity to break, so this looks like an Antigravity compatibility bug, not just malformed Git metadata.
Environment:
Antigravity app version: 1.21.6
macOS
Workspace was a linked Git worktree
Repro:
1. Use a repo with `git worktree`.
2. Enable per-worktree config in the main repo config:
Same issue for me on Windows 11 – man Antigravity is the gift that keeps on giving. Google needs to figure out their tests before they push out things – does no one in their org use worktrees?
Came here to report this issue on macOS on 1.21.9. Claude helped me with a workaround. Below he says what worked.
Workaround that worked for me:
The root cause is that AntiGravity’s language server uses a Go git library that rejects the [extensions] block in .git/config entirely — bumping repositoryformatversion to 1 is not sufficient, as multiple code paths (cascade_manager and GetAgentScripts) both fail on it independently.
The fix is to remove the [extensions] section from your repo’s .git/config:
# Remove these lines from .git/config:
[extensions]
worktreeConfig = true
If you have worktrees, check whether your config.worktree files actually contain anything meaningful (cat .git/worktrees/*/config.worktree). In most cases they only contain [core] longpaths = true which is a Windows-only setting and safe to lose on macOS. The worktrees themselves continue to work normally without it.
After removing the [extensions] block, restart AntiGravity and the agent responds as expected.
Broke for me too on Win11 inside a workspace sharing repo with Codex/CC. Gemini 3.1Pro in AG burnt through 3/4 of 3d of its quota to try and fix it, doing lots of shotgunning. Claude Code came in and saved the day. Gemini web search hallucinates wildly on this too.
Above fix does work - needs both changes. And this is triggered by this, so have to monitor for regressions cause Codex/CC love worktrees:
git worktree add on newer git versions auto-sets extensions.worktreeConfig = true and bumps repositoryformatversion to 1. If Claude Code or Codex created worktrees, git itself would have injected the extension block that crashes AG.
I wanted the new version.
Thought it was history.
Wiped antigravity data.
Nothing.
Dozens of experiments.
Git was the culprit — but I couldn’t see why.
Until your post.
Then everything clicked.