How to remote/SSH access under Antigravity 2.0?

Google Antigravity
1

My antigravity just automatically upgrade into2.0 while I am still in the … mood. How should I remote into my GPU rig and continue my development there? Thanks.

2

Hi. i have same problem. i develop over ssh on my server. But after update i can’t use Antigravity, that soo sad (

3

i haven’t been able to figure it out yet, the antigravity IDE part works with remote ssh but all my previous conversations are gone (in another folder since the ide is now a separate folder)
and, i can’t use the agents window if i install the IDE, and the agents window doesn’t support ssh so it just really screwed up everything

4

I have same problem. I can neither connect to remote or view project files. All the previous features are gone! I would call it a downgrade instead of an upgrade.

5

Same here; cannot find the place to set up and connect to the SSH

edited:

Ok we need to download the Antigravity IDE; but if using WIN, we need to uninstall the Antigravity 2.0 before installing the IDE.

But still, cannot load the past conversations from the SSH.

6

Oh, thanks, i will try it!

7

same problem here. so frustrated

8

@Gemini @Google Maybe will be better to send some tips :wink: May we use Antigravity IDE instead?
BTW in AGENTIC ERA… SSH is really important function :wink:

9

Did this get fixed for the agent? I haven’t tried installing it again since the update because it broke so much stuff

10

Unless I’m reading this wrong, you should just need to click the two arrows in the bottom left hand corner?

image

This brings up a window where you can select to connect to an SSH host.

Hope this helps, otherwise if I’ve totally missed the point I do apologise! :sweat_smile:

11

That ssh is in the IDE, the remote ssh i want to use from the agent manager and then i can use my own IDE. Right now the agent manger has no remote ssh option so you can only work on code locally, although the IDE still works with remote ssh but the terminal is busted

12

Give this a shot. https://github.com/the-future-company/ag2r I hacked this for myself in a few hours. It seems to be working somewhat okay.

13

Check this out working on it for a few months gives you direct access to your IDE and more Zerog- ai free and paid model

14

It’s really important for the agent tool to support SSH remote connection to servers. Will it be supported later?

15

Can someone from the developer team confirm this is in the works?

16

I’ve updated the Proxmox CPU type to host to support the pclmul instructions, and I’m using the VS Code Remote - SSH extension to install Google Antigravity externally on the VM. Everything is running smoothly now!

17

here’s a working setup I use daily GitHub - manav-bhullar/agent-remote-workspace: Let local-only AI agents (Antigravity 2.0, Gemini, Claude, Codex) work on a remote Linux server: files mount on your Mac over SMB, commands run over SSH, and the connection heals itself. · GitHub

18

The reason this thread has been running since May is that there is a fundamental split between editor remoting and agent execution, which @Paul_Foo diagnosed perfectly in Post #11: VS Code Remote SSH connects the editor window, but the Antigravity Agent Manager still executes its tool calls locally on your host laptop.

Previous workarounds either mirrored the UI (Post #12, which only handles mobile approvals) or ran full desktop sessions inside heavy Proxmox VMs (Post #16).

The architecture @manavbhullar linked in Post #17 is the first clean approach to resolve this deadlock because it decouples the filesystem from compute:

  1. Filesystem Layer (SMB / NFS Mount):
    The remote repository is mounted locally (e.g. /Volumes/Codes on macOS, or a UNC share on Windows). The Antigravity agent inspects, diffs, and edits code using its native file tools with zero protocol overhead.

  2. Execution Layer (MCP Server over SSH):
    Instead of asking the local agent to wrap raw bash commands in brittle ssh user@host "..." strings, an MCP server (remote-runner) runs directly on the remote Linux/GPU server, spawned over SSH stdio (ssh -T server run.sh). The agent receives structured tools (run_on_server, start_background) using argv arrays. Commands never touch the local machine, dev servers run natively on the server, and there is zero nested quoting to escape.

  3. Deterministic Safety Net (Shell Interceptor):
    If an autonomous agent in a long session forgets its system instructions and invokes its native local terminal tool, a shell interceptor in ~/.zshenv traps commands like node, npm, python, pip, cargo, and git inside the mount directory and forwards them over SSH automatically.

For Windows developers (e.g. @dolores in Post #5):
The identical pattern works on Windows. Mount the Linux share via SMB (\gpu-server\codes mapped to a drive letter), spawn the remote MCP runner via OpenSSH for Windows, and add proxy functions into your PowerShell profile ($PROFILE) to intercept local build commands.

Until native remote agent workspaces are integrated into the core platform, this decoupled SMB + MCP pattern is the most robust, deterministic setup available today.

Has anyone benchmarked SMB file-lock latency on huge monorepos with this yet? Would be interested to hear if NFS or SSHFS behaves better under heavy git status polling.