Antigravity 聊天框发消息不回复：一次 macOS 本地排障记录 / Antigravity Chat Sends but Never Replies

本文包含中文与英文两个版本。
This post includes both Chinese and English versions.

中文版

现象

这次遇到的问题是：Antigravity 聊天框里消息可以发出去，但一直没有回复。

最开始最显眼的报错是：

[Error] Server initialization failed.
Message: Pending response rejected since connection got disposed

[Error] antigravity client: couldn't create connection to server.
Error: connect ECONNREFUSED 127.0.0.1:60557

另外还有一条容易让人分心的错误：

Error generating commit message: [unknown] core.repositoryformatversion does not support extension: worktreeconfig

但排查到最后，这两类信息都不是根因。

先排掉假线索

第一条假线索是 worktreeconfig。
它确实会影响 Git 相关能力，比如自动生成 commit message，但它和聊天框“不回复”不是一条链路。

第二条假线索是 ECONNREFUSED。
继续追日志后会发现，language server 后面其实已经成功拉起：

LS lspClient started successfully
Language server started
loadCodeAssist
fetchAvailableModels

所以端口拒绝连接更像是启动阶段的一次短暂失败，而不是最后把聊天功能彻底卡死的根因。

真正的问题在 renderer

真正关键的报错出现在 renderer 日志里：

[createInstance] ... depends on UNKNOWN service agentSessions

同时还能看到类似提示：

command 'workbench.action.chat.newChat' not found

这说明问题已经不只是 language server，而是聊天工作台本身依赖的会话服务没有被正常注册。
也就是说，输入框虽然还在，但聊天的前端主链路已经坏了。

为什么重装当前版本没用

我后面做了一个关键对比：不仅看本机 /Applications/Antigravity.app，还去下载并比对了当时官方 releases 提供的当前版本安装包。

结论是：

1. 本机当前版本和官方当前版本是一致的。
2. 所以不是“这台机器装坏了”。
3. 至少在这次命中的链路里，当时的当前官方包本身就有问题。

也正因为如此，单纯删掉再重装最新版没有意义。

为什么没有直接热补丁 App 包

排查过程中，我一度已经定位到工作台主包里可疑的注册缺失点，也做过本地补丁尝试。

但在 macOS 上很快就会撞到系统安全策略：

Security policy would not allow process
The file is adhoc signed or signed by an unknown certificate chain

意思很直接：

1. 技术上能改。
2. 但改完的包不适合长期稳定运行。
3. 因为只要动了已签名 App 的资源，后面就会遇到签名链、AMFI 或系统策略的问题。

所以“直接热补丁现有安装包”不是一个稳妥方案。

最后可用的修法

最后真正可用的修法不是继续硬修当前版本，而是：

1. 换成一份官方签名的旧版 Antigravity 1.20.6。
2. 把 language server 路径一起切到这份旧版自带的二进制。
3. 关闭自动更新，避免它再次跳回坏版本。

关键配置在：

$HOME/Library/Application Support/Antigravity/User/settings.json

核心字段如下：

{
  "codeiumDev.languageServerBinaryPath": "$HOME/Applications/Antigravity 1.20.6.app/Contents/Resources/app/extensions/antigravity/bin/language_server_macos_arm",
  "antigravity.persistentLanguageServer": false,
  "update.mode": "none"
}

其中：

• codeiumDev.languageServerBinaryPath：强制指向旧版 1.20.6 自带的 language server。
• antigravity.persistentLanguageServer: false：避免继续黏住旧的异常状态。
• update.mode: none：防止自动更新把运行链路再次切回坏版本。

这条路更稳的原因在于：它仍然使用的是官方签名包，没有继续破坏应用完整性。

这次排查最值得记住的几点

1. 不要被第一条报错带偏。
2. 要先区分“噪音错误”和“致命错误”。
3. 不要默认“重装最新版”一定有用。
4. 在 macOS 上，热补丁已签名 App 通常不是长期修法。
5. 如果问题确实出在某个发布版本里，官方签名旧版 + 锁版本 往往比自行魔改更现实。

结语

这次问题最难的地方，不是没有日志，而是日志太多，而且有不少误导项。

表面看像 language server，像 Git，像本地缓存，最后真正影响聊天恢复的，却是工作台聊天链路和版本选择。

最后真正把它拉回正常的，不是继续修当前安装，而是：

回退到官方签名的 1.20.6，切换 language server 路径，并锁住更新。

---

English Version

Symptom

The problem looked simple at first: messages could be sent in Antigravity chat, but no reply ever came back.

The first errors that stood out were:

[Error] Server initialization failed.
Message: Pending response rejected since connection got disposed

[Error] antigravity client: couldn't create connection to server.
Error: connect ECONNREFUSED 127.0.0.1:60557

There was also another distracting error:

Error generating commit message: [unknown] core.repositoryformatversion does not support extension: worktreeconfig

In the end, neither of them turned out to be the real root cause.

Removing the false leads first

The worktreeconfig error was the first false lead.
It can affect Git-related features such as commit message generation, but it is not on the same path as “chat sends but never replies”.

The second false lead was ECONNREFUSED.
Once I kept reading the logs, it became clear that the language server was eventually starting successfully:

LS lspClient started successfully
Language server started
loadCodeAssist
fetchAvailableModels

So the refused localhost port looked more like a startup race or transient failure, not the final blocker.

The real failure was in the renderer

The truly important error showed up in the renderer log:

[createInstance] ... depends on UNKNOWN service agentSessions

There was also a related message like:

command 'workbench.action.chat.newChat' not found

That changes the diagnosis completely.
At that point, the issue is no longer just the language server. It means the chat workbench itself is missing a required session service registration.

In other words, the input box may still be visible, but the front-end chat pipeline is already broken.

Why reinstalling the current version did not help

I compared not only the local /Applications/Antigravity.app, but also the then-current official installer downloaded from the official releases feed.

The result was:

1. The local current version matched the official current version.
2. So this was not simply “a corrupted install on this Mac”.
3. On the code path I hit during this debugging session, the current official build itself appeared to be problematic.

That is why deleting and reinstalling the latest version did not meaningfully help.

Why I did not hot-patch the app bundle

At one point I had already narrowed the issue down to a suspicious missing registration in the workbench bundle and even tried building a local patch.

On macOS, that quickly runs into system policy:

Security policy would not allow process
The file is adhoc signed or signed by an unknown certificate chain

That means:

1. You can patch it technically.
2. But the patched app is not a good long-term runtime target.
3. Once you modify resources inside a signed app, you start fighting code signing, AMFI, and system policy.

So “hot-patching the installed app” is not a reliable long-term fix.

The fix that actually worked

The working solution was not to keep patching the broken current version, but to:

1. Switch to an officially signed older build, Antigravity 1.20.6.
2. Repoint the language server path to the binary shipped inside that build.
3. Disable auto-update so it would not jump back to the broken version.

The key configuration lives in:

$HOME/Library/Application Support/Antigravity/User/settings.json

The important fields were:

{
  "codeiumDev.languageServerBinaryPath": "$HOME/Applications/Antigravity 1.20.6.app/Contents/Resources/app/extensions/antigravity/bin/language_server_macos_arm",
  "antigravity.persistentLanguageServer": false,
  "update.mode": "none"
}

Why this is safer:

• It keeps using an officially signed build.
• It avoids breaking the integrity of the installed app bundle.
• It pins the runtime to a version that still behaves normally.

The most useful lessons from this debugging session

1. Do not let the first visible error dictate the whole investigation.
2. Separate noisy errors from fatal ones.
3. Do not assume reinstalling the latest build will always help.
4. On macOS, patching a signed app is rarely the best long-term answer.
5. If a release itself is the problem, an officially signed older version plus update pinning is often much more practical.

Closing note

The hardest part of this issue was not the lack of logs.
It was the opposite: there were too many logs, and several of them were misleading.

At first glance it looked like a language server problem, or a Git problem, or a cache problem.
In the end, the real issue was the chat workbench path itself and the version being used.

What finally brought the app back to a usable state was:

rolling back to the officially signed 1.20.6 build, repointing the language server path, and locking updates.