Antigravity Remote Control: Desktop, CLI, Daemon

What Antigravity remote control covers now: desktop, CLI, and daemon

Remote control started as a single desktop toggle and now has three ways in: that toggle, a CLI tunnel for one session, and a CLI daemon that is always on. Antigravity 2.0 (the desktop app) and the Antigravity CLI are separate products that happen to share the feature name.

On the desktop, remote control is still the toggle the feature launched with in August 2026: a browser window onto agent sessions already running in the app. The CLI version is newer and comes in two forms: a one-session tunnel you open and close yourself, and a daemon that stays registered as a background service.

Three entry points, one feature name

Entry point	What it connects to	Stays open
Desktop toggle (in the app's settings)	Antigravity 2.0 sessions	Until you sign out or turn the toggle off
CLI /remote-control (or --remote-control flag)	One interactive CLI instance	Only for that CLI session
CLI daemon (agy remote-control start)	The whole machine, headless	Until you stop it, across reboots

From the desktop side you can still do everything it could at launch: read conversations in progress, start new agent tasks, review implementation plans, inspect artifacts and run commands on the host, all in a browser with nothing installed on the device you connect from. The two CLI routes add to that and cover machines and moments where no desktop app window is open.

Which machines can you reach from a browser?

You can reach any machine running Antigravity 2.0 or the Antigravity CLI, as long as it is signed in to the same Google account as your browser. Google mentions laptops, servers and desktops, and a browser is the only thing the desktop route asks of the device you connect from. A phone browser works as well, which is why a mobile web app and push notifications come alongside the desktop setup.

Turning on remote control in Antigravity 2.0 Desktop

If the desktop app is already installed, remote control takes one setting and a sign-in, and that process has not changed since the August launch. The steps in the table still match Google's current documentation.

From toggle to first connection

Step	Action
1	Open Settings with Cmd + , (Ctrl + , on Linux and Windows)
2	Go to the App section and switch Enable Remote Control on
3	Optionally set a nickname so the machine is identifiable in the list
4	Open the remote control dashboard in a browser and sign in with the same Google account

Open the Settings panel with Cmd + , on macOS (Ctrl + , on Linux and Windows) or from Settings at the bottom of the left sidebar, then find the Enable Remote Control switch in the App section. The nickname field beside it matters more than it looks. Google suggests names that say what the machine does, such as workstation-primary or server-machine, and those names earn their keep once a third machine shows up in the list.

Connecting to the dashboard from a browser or phone

Open the remote control dashboard in any browser, sign in with the account the desktop app uses, and choose the machine from the instance switcher. On a phone, add the web app to your home screen if you want push notifications when an agent finishes a turn or stops to wait for an answer.

Starting a one-session connection with the CLI's /remote-control

The Antigravity CLI has a remote control of its own that, by default, covers one interactive session instead of the whole machine. Type /remote-control (or /remote-control on) in a running instance and it opens a tunnel for that instance alone, without registering any lasting service.

Once the tunnel is up, the CLI prints a hostname and a URL to open on another device. The tunnel lasts only as long as that CLI instance runs: typing /remote-control off closes it without closing the terminal, and so does quitting the CLI or closing the terminal window.

--remote-control at launch versus /remote-control mid-session

The flag and the slash command open the same tunnel; the only difference is when you decide you need it. Starting the CLI with --remote-control opens the tunnel from the first prompt, which fits a session you already plan to check from your phone. Typing /remote-control mid-session fits the reverse case: you started working locally and later decided to carry on from another device.

In both cases the tunnel belongs to that single CLI instance. It ends when the session ends, whether you type /remote-control off or quit the CLI, and this command has no hidden always-on mode.

Running an always-on daemon with agy remote-control

A server or build machine seldom has a terminal open for someone to type /remote-control, so the CLI has a separate subcommand that registers a background daemon rather than a tunnel tied to one session. Three commands manage it from start to stop.

Daemon management commands

Command	Effect
agy remote-control start	Register and start the daemon
agy remote-control status	Check whether it is running and what it is named
agy remote-control stop	Take it down and drop the registration

The start subcommand hands the daemon to the operating system's service manager, so it no longer depends on a terminal window: systemd runs it on Linux, a LaunchAgent on macOS and a Scheduled Task on Windows. For the same reason it starts automatically and needs no open shell to keep running. It signs in with whatever account the CLI uses, and that credential stays separate from the desktop editor's sign-in, even on the same machine.

Naming the machine and where the settings live

Give the daemon a name with the --name flag, for example agy remote-control start --name "my-workstation". Without one, the daemon makes up a friendly name on first start, such as my-machine-distant-plume, which is easy to remember but says nothing about what the machine does.

The settings file is ~/.gemini/config/config.json on Linux and macOS and %USERPROFILE%\.gemini\config\config.json on Windows. It holds two keys with almost the same name, and only cliRemoteControlHostname belongs to the daemon. remoteControlHostname belongs to the Antigravity editor on the same machine, and in Antigravity 2.0 you can change that one in the App section of Settings instead.

How the daemon behaves on Linux, macOS, and Windows

The daemon starts at a different point and recovers with different reliability on each operating system, and that should decide which machine you keep always on. The table answers the three questions that matter most for each one.

Daemon lifecycle by operating system

Question	Linux	macOS	Windows
Needs a login to start?	No	Yes	Only without an Administrator install
Survives a sign-out?	Yes	No	Yes, with a boot install
Recovers from a crash alone?	Yes	Yes	Up to 3 retries, then a reboot or manual restart

Linux needs nothing from you: the service is running before anyone logs in and keeps running after a sign-out. macOS is the opposite: the daemon starts only after someone logs in and stops at sign-out until the next login. Keeping a Mac reachable at all times therefore means leaving a user logged in, not changing a setting once.

Windows sits between the two: to keep running after a sign-out, the daemon has to be registered from an Administrator prompt (PowerShell or Command Prompt both work). Without that, start still works, but the daemon will not return after a sign-out or restart until someone logs in. Checking its status or stopping it needs no special rights, and after a crash Windows retries three times before Google's fallback applies: the next boot, a scheduled update, or someone running the start command by hand.

When a machine or session does not show up

Google's troubleshooting is split between the desktop app and the CLI, so where you look first depends on what went wrong. The table maps each symptom to what to check, and the two sections after it cover the fixes.

Symptom to check

Symptom	What to check
Machine missing from the web list	Enable Remote Control is on for that host
Same	Host is online and is not asleep or suspended
Same	Desktop app and browser use the same Google account
CLI says remote control is not enabled	Account or organization policy has not enabled the feature flag
Instance disappears from the dashboard	Expected for a session-scoped tunnel — it ends with the terminal; switch to the daemon for a box that must stay reachable with nothing open
The connection flaps between up and down	A leftover daemon from the old script install is probably fighting the new one for the port; re-registering clears it

Checks for the Antigravity desktop app

Whether the desktop app appears at all comes down to three things: the toggle, the connection and the account. Enable Remote Control must be on for that host, the host must be online and not asleep or suspended, and the desktop app and the browser must use the same Google account.

Sleep is the one that trips people up, since a laptop with its lid closed drops off the list without any error message. On any machine you plan to reach remotely, change the sleep settings before you leave rather than troubleshoot afterwards.

Checking the CLI and its logs

Each of the two CLI symptoms has a single fix: a disabled feature flag needs an admin, and a disappearing instance needs the daemon instead of a session tunnel. A "not enabled for your account" message means an organization or account policy is blocking the feature, so there is no local setting to look for. A session that keeps dropping off the dashboard is working as designed, because that tunnel lives and dies with one terminal.

For anything else, check the log. On Linux it is journalctl --user -u antigravity-cli-daemon -n 50, on macOS ~/Library/Logs/antigravity-cli-daemon.log, and on Windows the newest cli-*.log file under %USERPROFILE%\.gemini\antigravity-cli\log. If the connection keeps dropping, a daemon left over from the retired script install may still be holding the port, and running agy remote-control start again removes the old service.

Remote control in a day-to-day agent workflow

The three entry points cover most needs: the desktop toggle for the machine at your desk, the CLI's /remote-control for one session you want to check from somewhere else, and agy remote-control start for a machine that must stay reachable with nobody logged in. Choosing between the two CLI modes comes down to how long the machine has to stay reachable, for one session or for good.

The per-OS daemon table tells you which machine to leave on: macOS stops at sign-out, and Windows needs a boot install from an Administrator prompt to outlast a logout. Once a machine is reachable, a dropped connection costs you the view, not the work. Background agent tasks and shell commands keep running on the host as long as it is online, so you can start something long and walk away whichever entry point you used.

The models running inside those agent sessions change on their own schedule and are worth following separately. Gemini 3.5 Pro is still not in the Gemini API covers where that model stands now.