Codex、Antigravity 雙修黨注意：這個 Git worktree 坑會讓 Antigravity 直接“失聯”
整理版優先睇
Git worktree 殘留配置令 Antigravity 扮死？檢查 .git/config 就搞掂
呢篇文章係作者分享自己一次親身經歷：佢同時用 Codex 同 Antigravity 喺同一個 Git repo 做開發，但突然 Antigravity 好似死咗咁，訊息 send 咗出去但完全冇反應。佢最初以為係網絡、登入過期或者模型問題，搞咗一輪先發現原來係 Git worktree 嘅殘留配置搞鬼。
作者解釋，佢之前用 Codex 起過 linked worktree，雖然之後用 git worktree remove 同 prune 清過，但 .git/config 入面仲留低咗一項 worktree 相關配置，而 Antigravity 呢個版本對呢個配置兼容唔好，初始化工作區嗰陣會卡死，結果就係「模型好似識答但 IDE 唔識接」。要快速判斷，可以睇日誌有冇 "worktreeconfig"、"workspace infos is nil" 呢啲關鍵詞。
最後作者教路：直接刪咗 .git/config 入面相關嘅 worktree 設定，重啟 Antigravity 就搞掂。佢仲提醒其他「雙修黨」，最好俾唔同工具用唔同 clone，或者清 worktree 之後順手檢查一次 .git/config，避免呢類隱藏問題。
- Git worktree 殘留配置會令 Antigravity 看似冇反應，實際係本地工作區初始化失敗。
- 快速判斷方法：睇日誌有冇 "worktreeconfig" 同 "workspace infos is nil" 關鍵詞。
- 問題根源唔係網絡或賬號，而係 .git/config 入面嘅 worktree 設定卡住咗初始化。
- 啟發：同一 repo 用多個 AI 工具，工具鏈本身都會留低狀態，要小心殘留配置。
- 可行動：清理 worktree 後檢查 .git/config，或者直接用唔同 clone 俾唔同工具。
Antigravity 扮死？其實係 worktree 殘留作怪
如果你平時同時用 Antigravity 同 Codex，又鍾意喺同一個 repo 嚟回切工具，可能會遇到 Antigravity 突然冇反應嘅情況：訊息 send 咗出去，但完全收唔到回覆。第一反應通常係諗網絡、登入過期、模型抽風，但呢次唔係呢啲問題。
真正嘅根因係 Git worktree 嘅殘留配置令 Antigravity 嘅工作區初始化卡死咗。
作者發現，個 repo 之前俾 Codex 起過 linked worktree，雖然之後用 git worktree remove 同 prune 清過，但 .git/config 入面仲留低咗一項配置，而 Antigravity 對呢個配置兼容唔完整，結果表面睇似「模型冇反應」，實際上係「工作區起唔到」。
點解 .git/config 殘留會搞到 Antigravity 死機？
Antigravity 喺初始化本地工作區嗰陣，會讀取 .git/config。如果入面有 worktree 相關嘅設定，而佢又唔識處理，就會當成「不支援嘅 worktree 擴展狀態」，然後成個 agent 會話初始化失敗。
呢個唔係「模型唔識答」，而係「IDE 冇將對話真正起動」。
點樣快速判斷同解決？
- 1 先檢查日誌有冇上面提到嘅關鍵詞，確認係 worktree 問題。
- 2 如果個 repo 仲有用 worktree，用 git worktree list 睇下狀態。
- 3 喺 .git/config 入面刪走所有 worktree 相關嘅 extension 配置行。
- 4 重啟 Antigravity 再試一次，通常就正常返。
作者建議：如果仲係唔得，可以試下直接刪咗 .git/config 入面嘅 "worktreeConfig" 整段。
俾雙修黨嘅提醒：工具鏈都會留狀態
git worktree 好好用，但只要你用多個 AI Coding IDE，殘留配置就會變成隱藏地雷。
作者仲提醒：同一 repo 唔單止 code 會留狀態，工具鏈本身都會留低設定。
如果你平時同時用 Antigravity 和 Codex，又鍾意喺同一個倉庫裏面來回切工具，咁呢篇文章可能會幫你慳返一次「以為 Antigravity 死咗，其實係本地 Git 狀態卡住咗佢」嘅排查時間。
Antigravity 冇反應
現象好直接：Antigravity 裏面訊息發咗出去，但係就冇迴音，睇落似突然用唔到。
第一反應通常都係：
係咪網絡問題？ 係咪登入過期？ 係咪帳號俾人封咗？ 係咪模型服務發神經？
但係今次，以上全部都唔係。
真正嘅原因，係 Git worktree 嘅殘留配置令 Antigravity 嘅工作區初始化死咗。
表面睇似「模型冇回」，實際上係「工作區起唔到」
今次問題嘅關鍵在於：
呢個倉庫之前俾 Codex 建立過 linked worktree。 雖然之後執行咗 git worktree remove和git worktree prune。但係倉庫嘅 .git/config裏面，仍然殘留咗一項配置：
問題就喺呢度。
Antigravity 現時版本對呢個配置項嘅兼容唔完整。佢初始化本地工作區資訊嘅時候，會將呢個倉庫辨認為「唔支援嘅 worktree 擴展狀態」，於是後面嘅 Agent 會話狀態起唔到。
結果就係：
雲端請求其實發咗出去，但係本地會話駁唔到，最後表現成聊天視窗冇反應。
換句話講，呢個唔係「模型唔識答」，而係「IDE 冇將呢次對話真正行起嚟」。
呢類問題點樣快速判斷？
如果你都遇到類似情況，可以優先睇日誌裏面有冇呢幾個關鍵字：
worktreeconfigworkspace infos is nilagent state for conversation ... not found
如果呢幾個字同時出現，基本上就唔係普通嘅網絡問題，而係 本地倉庫元數據解析失敗。
Antigravity 日誌查詢
好多人一見到「訊息冇返」，就不斷退出登入、重裝 IDE、轉模型、換網絡。
但如果原因喺 .git/config，呢啲動作基本上都解決唔到問題。
正確處理方法
如果倉庫確實之前用過 worktree，建議跟呢個順序處理：
如果最後呢一步仍然見到：
而你而家又已經唔再需要 worktree 相關配置，咁可以繼續執行：
然後重啟 Antigravity，再試一次。
今次我嘅問題，就係剷咗呢條配置之後恢復正常。
俾「雙修黨」嘅一個建議
如果你同時用多個 AI Coding IDE，有一個經驗好值得記低：
同一個倉庫，唔單止程式碼會留低狀態，工具鏈本身都會留低狀態。
git worktree 好好用，的確可以提升多分支並行效率；
但係只要某個工具對 worktree 兼容唔完整，殘留配置就可能變成「隱藏地雷」。
所以更穩陣嘅做法係：
一係俾唔同工具用唔同 clone； 一係喺清理 worktree 之後，順手檢查一次 .git/config；
總結
總結
如果你平時同時用 Antigravity 和 Codex，又喜歡在同一個倉庫裏來回切工具，那這篇文章可能會幫你省下一次“以為 Antigravity 掛了，其實是本地 Git 狀態把它卡住了”的排查時間。
Antigravity 無回應
現象很直接：Antigravity 裏消息發出去了，但就是沒反饋，看起來像突然不能用了。
第一反應通常都是：
是不是網絡問題？ 是不是登錄過期了？ 是不是賬號被封了？ 是不是模型服務抽風了？
但這次，以上都不是。
真正的根因，是 Git worktree 的殘留配置把 Antigravity 的工作區初始化卡死了。
表面看像“模型沒回”，實際是“工作區沒建起來”
這次問題的關鍵點在於：
這個倉庫之前被 Codex 建過 linked worktree。 後來雖然執行了 git worktree remove和git worktree prune。但倉庫的 .git/config裏，仍然殘留了一項配置：
問題就出在這裏。
Antigravity 當前版本對這個配置項兼容並不完整。它在初始化本地工作區信息時，會把這個倉庫識別成“不支持的 worktree 擴展狀態”，於是後面的 Agent 會話狀態建不起來。
結果就是：
雲端請求其實發出去了，但本地會話沒接上，最後表現成聊天窗口無響應。
換句話說，這不是“模型不會答”，而是“IDE 沒把這次對話真正跑起來”。
這類問題怎麼快速判斷？
如果你也遇到類似情況，可以優先看日誌裏有沒有這幾個關鍵詞：
worktreeconfigworkspace infos is nilagent state for conversation ... not found
如果這幾個詞同時出現，基本就不是普通的網絡問題了，而是 本地倉庫元數據解析失敗。
Antigravity 日誌查詢
很多人一看到“消息沒返回”，就開始反覆退出登錄、重裝 IDE、切模型、換網絡。
但如果根因在 .git/config，這些動作幾乎都不會解決問題。
正確處理方式
如果倉庫確實曾經用過 worktree，建議按這個順序處理：
如果最後這一步仍然能看到：
而你當前又已經不再需要 worktree 相關配置，那麼可以繼續執行：
然後重啓 Antigravity，再試一次。
這次我的問題，就是在移除這條配置後恢復正常的。
給“雙修黨”的一個建議
如果你同時使用多個 AI Coding IDE，有一個經驗非常值得記住：
同一個倉庫，不只是代碼會留下狀態，工具鏈本身也會留下狀態。
git worktree 很好用，確實能提升多分支並行效率；
但只要某個工具對 worktree 兼容不完整，殘留配置就可能變成“隱藏雷區”。
所以更穩妥的做法是：
要麼給不同工具用不同 clone； 要麼在清理 worktree 後，順手檢查一次 .git/config；
總結
總結