I have the same issue. But actually get past the part with “working…” after a looong wait.
Hello @andy_james311
Confirming the same issue — specifically the variant @FT83 describes: the turn is not stuck forever, it does complete, but only after a 5–10 minute wait.
@Ritesh_Dhawade thanks, but those steps don’t apply in my case:
mcp_config.json has "disabled": true for every entry, and I killed the orphaned node.exe / python.exe MCP processes left over from earlier sessions. The MCP Error indicator cleared. No change to the delay.First turn of an exchange = 5–10 minutes. Continuation within the same exchange = instant.
When the model asks me a clarifying question and I answer it, the reply comes back in seconds — same session, same socket, same model. So this cannot be general model latency, quota, or regional degradation. Whatever happens at turn initiation is where the time goes.
The delay is before the first token, not during tool execution. A prompt that requires no tool calls at all (e.g. “Where is your working directory?”) still takes 5–10 minutes.
| Hypothesis | How it was tested | Result |
|---|---|---|
| Network / DNS / TLS | Connection check during the hang | Socket to Google established at send time, held open throughout — negative |
| Antivirus quarantine of language server | Checked for LS update error / missing language_server_windows_x64.exe |
Not present — negative |
| Workspace indexer / CPU contention | Task Manager during the hang | All Antigravity.exe processes at 0% CPU — negative |
| MCP servers | Fully disabled + orphaned processes killed | Negative |
| Hooks | hooks.json removed entirely; symptom also predates it |
Negative |
| Accumulated conversation state | New conversation, new empty project | Negative |
| Summary cache rebuild | Polled agyhub_summaries_proto.pb during the hang |
File is static for the whole wait; it only updates after the response arrives — negative |
| Server-side / regional degradation | — | Contradicted by instant follow-ups in the same session |
During the wait the client is completely idle: 0% CPU, no disk writes, socket open. It is sending and then waiting.
.gemini\antigravity\mcp\<server>\*.json keep getting written even when every MCP server is disabled in the UI. Disabling does not appear to remove a server from turn preparation.brain/<id>/transcript.jsonl to conversations/<id>.db (SQLite/WAL) in 2.5.0, and brain/<id> folders are now created empty. I assume this is an intentional migration, mentioning it only for completeness.@FT83 — which version are you on, and did your delay also start at the beginning of August? If you’re also on 2.5.0 that would make this a regression rather than a local configuration problem.
I’m sorry, I did not see your message!
It occured on versions 2.5.0 and 2.6.0 (Edit: corrected version).
I did clear 300 files from some folder, “/brain” something. And after that, no problem, instant replies.
I’ll see if I can find it on the actual computer, which folder/files it was.
Hope it get solved for you, it was really frustrating.
Edit:
The directory I cleared was:
• Linux: ~/.gemini/antigravity-cli/brain/
• Windows: %USERPROFILE%.gemini\antigravity-cli\brain\ (and corresponding .gemini\antigravity\ paths)
What happened in my case was an orphaned trajectory reference: the UI was attempting to restore a previous conversation state on turn initiation, but failed with:
LoadTrajectory failed: trajectory not found in any store
This caused StreamAgentStateUpdates to hang in a retry/timeout loop before streaming the first token.
Clearing out the old session folders under brain/, restarting the Language Server process (pkill -9 -f language_server / killing language_server_windows_x64.exe), and starting a completely clean chat (+ New Conversation) resolved the state loop.