Chat send silently fails after switching workspaces in same window — no error, no network call, no logs

Google Antigravity
1

Environment

  • Antigravity 1.107.0, commit 62335c71d47037adf0a8de54e250bb8ea6016b15

  • Downloaded from antigravity.google (public release, no early access enrollment)

  • macOS 15 (Darwin 25.4.0), Apple Silicon (arm64), Electron 39.2.3

  • Bundled google.antigravity extension only; no third-party chat extensions

  • User settings.json is essentially empty (only workbench.colorTheme)

  • No proxy, no VPN, no application firewall (Little Snitch / Lulu / Radio Silence not installed); scutil --proxy confirms all proxies disabled

  • Direct curl to https://daily-cloudcode-pa.googleapis.com/ returns HTTP 404 in 229 ms — network path to the backend is healthy

Steps to reproduce

  1. Run antigravity auth login from CLI. App opens.

  2. Send a chat message — it works, Cascade responds.

  3. File → Open Folder to switch the same window to a different, already-trusted, previously-opened workspace.

  4. Send any new chat message.

Reproduces 100% of the time. I have switched between two old, familiar folders many times in a row — every switch breaks chat the same way.

Expected

Cascade responds normally after a workspace switch.

Actual

The user message bubble renders in the chat thread, then nothing happens — no spinner, no error, no response, indefinitely. No toast, no status bar warning, no console error visible to the user. The chat panel looks alive (input still accepts text, send still renders bubbles), but no further activity occurs.

The same broken state applies to brand-new conversations started via “New Chat” in the broken window — not just the conversation that was active when the switch happened.

What does NOT recover the chat

All of the following were tried, in order, with no effect:

  1. Developer: Reload Window

  2. Starting a new conversation via “New Chat”

  3. Disabling chat.implicitContext.enabled and chat.implicitContext.suggestedContext

  4. Quit (Cmd+Q) and relaunch — chat works for the very first message, then breaks again on the next workspace switch

  5. Re-running antigravity auth login

  6. Deleting Local Storage, Local Storage.bak, Session Storage, Cookies, Cookies-journal from ~/Library/Application Support/Antigravity/ (after full quit), then relaunching — the app did not ask me to re-login, and chat was still broken from the very first message after relaunch

Workspace Trust is already granted; no Restricted Mode banner is shown at any point.

Diagnostic evidence from ~/Library/Application Support/Antigravity/logs/<session>/

I captured 8 separate session directories during reproduction. Every single one shows the identical pattern:

cloudcode.log — exactly 4 lines, all from startup:

[CloudCode] POST v1internal:loadCodeAssist  traceId: ...
[CloudCode] POST v1internal:loadCodeAssist  traceId: ...
[CloudCode] POST v1internal:fetchAvailableModels  traceId: ...
[CloudCode] POST v1internal:fetchAvailableModels  traceId: ...

Zero entries are written when the user sends a chat message, even after waiting indefinitely.

window1/exthost/google.antigravity/Antigravity.log (Go language server)

Stops at startup: LS lspClient started successfully followed by the same two loadCodeAssist + fetchAvailableModels HTTPS calls to daily-cloudcode-pa.googleapis.com. No further activity is logged when the user sends a message.

In one session (17:02), I observed the LS being respawned 3 times within 60 seconds (pids 30445 → 30789 → 31171) as I switched folders. Each respawn re-ran the two startup calls successfully, then went silent again.

window1/network.log and network-shared.log

Both 0 bytes throughout the broken state.

window1/renderer.log

Contains these warnings at every startup (flagging in case relevant):

[error] [google.antigravity]: Menu item references a command 
  `antigravity.importAntigravitySettings` which is not defined in the 'commands' section.
[error] [google.antigravity]: Menu item references a command 
  `antigravity.importAntigravityExtensions` which is not defined in the 'commands' section.
[error] [google.antigravity]: Menu item references a command 
  `antigravity.prioritized.chat.open` which is not defined in the 'commands' section.

Interpretation

The complete absence of any post-startup entries in both the TS extension layer (cloudcode.log) and the Go LSP layer (Antigravity.log), combined with network.log being 0 bytes, combined with the user message bubble rendering correctly in the UI, strongly suggests the chat-send dispatch is failing inside the renderer process before it ever reaches the extension host. The user bubble appears to be rendered optimistically; the actual vscode.commands.executeCommand (or equivalent IPC call) appears to silently no-op or be swallowed by a try/catch with no surface telemetry. There is no error anywhere in the UI, logs, or network — which is what makes this so hard for end users to even recognize as a bug.

Secondary observation (may be a separate bug, flagging anyway)

While trying to file this report in-app, the submission UI itself stuck at “submitting” indefinitely. Inspection of /Applications/Antigravity.app/Contents/Resources/app/product.json shows:

  • reportIssueUrl: "" (empty string)

  • updateUrl: "https://example.com" (placeholder)

These look like placeholder values left in the published 1.107.0 build. They likely explain why both in-app issue reporting and Check for Updates appear to “succeed” silently without doing anything. This may be a separate bug, but it forced me to find this forum manually.

What would help most

  • Renderer-side logging on the chat send path, so a swallowed dispatch error becomes visible in renderer.log

  • A user-facing error toast when send fails for any reason, instead of leaving the user message bubble dangling forever

  • Investigate whether chat panel UI state (active conversation reference, workspace ID, model selection) becomes stale after a workspace switch within the same window — that’s the most parsimonious cause given the symptoms

  • Fix product.json reportIssueUrl and updateUrl placeholders in the next build

Full session log directories are available on request.