Working with Antigravity Server Remote (Parent Thread)

Google Antigravity
1

Looking to contain Antigravity? Use a container.

Looking to introduce Antigravity into a high-maturity secure composable dev architecture? Use a remote (container) with Antigravity Server.

Unofficial user thread by Matthew Fisch (antigravity customer), I will continue to update this thread until we’ve finished our internal rollout.

What’s Antigravity Server?

  • VS Code Remote-ing was a bleeding edge experimental feature just a few years ago. Today it’s the mature architecture that backs GitHub Codespaces and many more.
  • The Google Antigravity fork partially supports remoting with a fully functional “Antigravity Server” alternative to the VS Code Remote Server – it magically works – mostly

What’s working? (Working / Issues)

Last updated for version 1.15.6

Attach protocols working

  • SSH Remote (Working)

Attach protocols not working

  • Kubernetes Remote Attach (Not working, no compatible provider?)
  • Remote (non-local system) Dev Containers (Not Working, requires incompatible Microsoft Extension?)

Feature (in)compatibility

  • Agent Manager - Mostly broken

    • Appears to have communication issues over the remote connection. Conversation may be started here but it will eventually fail and need to be “picked up” via the conversation sidebar inside the workspace/IDE.
    • Workaround: Don’t use the agent manager, but this means only one simultaneous conversation thread per workspace.

  • CDP (Chrome Dev tools Protocol) for Browser Tool - Mostly broken

    • Works unreliably. In my testing you’re just as likely to get a “positive” outcome as a totally broken one (in my system, I’ve seen connection storms that create 10-50k or more zombie socket acquisitions).
    • Notes: Possible unconfirmed workaround (see thread)

This discussion is the parent thread for discussions about using antigravity “remotely” e.g. the “Antigravity Server”.

Feel free to bring up bugs you’ve encountered and workarounds, but this thread is NOT for reporting bugs (as discussed elsewhere, you should use the feedback tool for that).

[Bug Antigravity] Remote-SSH crashes immediately on connection (Exit 132 / Hanging CMD Window)
[BUG] Antigravity Agent Manager: Conversation history exists on remote host but is not listed or creatable after latest update (Remote SSH, Mac & Ubuntu)
2

Our POC was mostly a success, and now that there are “Workspaces” plans we’re grooming this to be our next gen dev environment (moving from Codecatalyst, another containerized vscode remote infrastructure).

We did get Github Codespaces working as a POC, but we’ve decided to host directly in Kubernetes and have chosen to deploy using company maintained manifests (not a tool like devspace or devpod or even Microsoft devcontainers that all have maintainability or compatibility problems with antigravity).

We “Attach” over SSH Remote using a Kube exec -i (inetd mode).

Anyone else?

3

CDP (Chrome Dev tools Protocol) for Browser Tool - Mostly broken - Update

Antigravity Version: 1.15.6
VSCode OSS Version: 1.104.0
Commit: 537cf4f35922babf391f4c5b03281f3228d2a0b0
Date: 2026-01-22T04:39:18.468Z
Electron: 37.3.1
Chromium: 138.0.7204.235
Node.js: 22.18.0
V8: 13.8.258.31-electron.0
OS: Linux x64 6.6.99-08879-gd6e365e8de4e
Language Server CL: 859380938

CDP Works unreliably. In my testing you’re just as likely to get a “positive” outcome as a totally broken one (in my system, I’ve seen connection storms that create 10-50k or more zombie socket acquisitions).

Notes:

Both the antigravity and launched chrome bind to port 9222. I’ve had some luck with changing the port but not reliably. I have not investigated why antigravity is intercepting requests but the problem appears to be related to a failure retry or LISTENER detection with the sshd proxy. CDP sometimes works without storms, sometimes it even works with storms, but ultimately CDP is not reliable when it tries and fails to bind thousands of socket connections.

Workaround?

I’m not convinced about this workaround – I will submit to dev team if I confirm before they fix it. It’s possible its working randomly, or its possible its successfully avoiding the antigravity port binding and the remote AG server is hitting chrome directly for the win.

It appears to me that if I forward remote:9222 –> local:9222 & remote:9223 –> local:9223 AND start Chrome before antigravity tries binding ports, the connection storm does not happen. I’m not sure both these ports are necessary …

Step 1 (execute on local machine)

/opt/google/chrome/chrome --remote-debugging-port=9222 --user-data-dir=/home/{user profile name}/.gemini/antigravity-browser-profile --disable-fre --no-default-browser-check --no-first-run --auto-accept-browser-signin-for-tests --ash-no-nudges --disable-features=OfferMigrationToDiceUsers,OptGuideOnDeviceModel

Step 2 (execute on local machine)

  • Make sure you’ve port forwarded remote:9222 –> local:9222 & remote:9223 –> local:9223
  • Start Antigravity
4

Confirmed CDP workaround below:

CDP (Chrome Dev tools Protocol) for Browser Tool - Mostly broken - Update

Antigravity Version: 1.15.6
VSCode OSS Version: 1.104.0
Commit: 537cf4f35922babf391f4c5b03281f3228d2a0b0
Date: 2026-01-22T04:39:18.468Z
Electron: 37.3.1
Chromium: 138.0.7204.235
Node.js: 22.18.0
V8: 13.8.258.31-electron.0
OS: Linux x64 6.6.99-08879-gd6e365e8de4e
Language Server CL: 859380938

CDP Works unreliably. In my testing you’re just as likely to get a “positive” outcome as a totally broken one (in my system, I’ve seen connection storms that create 10-50k or more zombie socket acquisitions).

Notes:

Both the antigravity and launched chrome bind to port 9222. I’ve had some luck with changing the port but not reliably. I have not investigated why antigravity is intercepting requests but the problem appears to be related to a failure retry or LISTENER detection with the sshd proxy. CDP sometimes works without storms, sometimes it even works with storms, but ultimately CDP is not reliable when it tries and fails to bind thousands of socket connections.

Workaround: Confirmed

I’m not convinced about this workaround – I will submit to dev team if I confirm before they fix it. It’s possible its working randomly, or its possible its successfully avoiding the antigravity port binding and the remote AG server is hitting chrome directly for the win.

It appears to me that if I forward remote:9222 –> local:9222 & remote:9223 –> local:9223 AND start Chrome before antigravity tries binding ports, the connection storm does not happen. I’m not sure both these ports are necessary …

Step 1 (execute on local machine)

/opt/google/chrome/chrome --remote-debugging-port=9222 --user-data-dir=/home/{user profile name}/.gemini/antigravity-browser-profile --disable-fre --no-default-browser-check --no-first-run --auto-accept-browser-signin-for-tests --ash-no-nudges --disable-features=OfferMigrationToDiceUsers,OptGuideOnDeviceModel

^^ you’ll need to make sure to specify the correct user profile data directory or use a relative URL such as ~/.gemini/antigravity-browser-profile

Step 2 (execute on local machine)

  • Make sure you’ve port forwarded remote:9222 –> local:9222 & remote:9223 –> local:9223
  • Start Antigravity