Antigravity Phone Connect: Mirror a Desktop AI Session to Your Phone over CDP

The problem: an AI session that only exists on one screen

Antigravity, the desktop AI environment this project targets, renders its conversation in a window that has no phone client. If you start a long generation and walk away, the only way to check progress is to return to the machine. Antigravity Phone Connect exists to close that gap: it mirrors the chat to a mobile browser and forwards input back, so the desktop session stays the source of truth while the phone acts as a remote view.

The intended user is a single developer running Antigravity locally, not a team. There is one password (APP_PASSWORD), one server process, and one Antigravity instance. The README frames it as a personal convenience tool: step away from your desk while keeping sight and control over the generation. That scope explains most of the design decisions, including the reliance on a debugging port rather than an official integration.

How the CDP snapshot pipeline actually works

The mechanism is not an API integration. Antigravity is launched with --remote-debugging-port=9000, which exposes the Chromium DevTools Protocol endpoint. The Node server in server.js connects to that endpoint over WebSocket (the ws dependency) and reads the chat DOM, then pushes snapshots to connected mobile clients. The package description calls this a visual snapshot approach, and the README claims sub-100ms mirroring; the repository does not publish the measurement method behind that figure, so treat it as a project claim rather than a verified number.

Because the server reads the rendered interface instead of a data layer, it depends on Antigravity's DOM structure. The README warns directly that without an active chat session you will see "chat container not found" errors. That is the central architectural constraint: the bridge is coupled to a UI it does not control. Two consequences follow. First, the server can start before Antigravity and wait, which the README describes as intentional. Second, any Antigravity release that renames or restructures the chat container breaks snapshot capture until the selectors are updated. The repository ships a ui_inspector.js file, which suggests the maintainer inspects the live DOM when selectors need revision.

On the transport side, Express serves the mobile interface from public/, compression handles payload size, and cookie-parser supports the signed httpOnly session cookies the README lists under security. A strict Content Security Policy with no inline JavaScript is described as the XSS defence. The architecture is therefore three hops: Antigravity DOM, Node server over CDP, mobile browser over HTTP or HTTPS.

Installing it and connecting a phone on the same Wi-Fi

Start Antigravity with remote debugging enabled. The README gives a manual command and also an installer that adds a right-click context menu entry on Windows and Linux; the manual form is the one to keep in mind because it shows the port the server will later look for.

antigravity . --remote-debugging-port=9000

Next, open an existing chat or send a new message inside Antigravity. The README is explicit that the server needs an active chat session to capture snapshots, and that skipping this step produces "chat container not found" errors.

Then run the launcher for your platform. On macOS and Linux the first run needs the executable bit.

chmod +x start_ag_phone_connect.sh
./start_ag_phone_connect.sh

The launcher is a Python script (launcher.py) that the README says sets up a virtual environment, checks Node.js and Python dependencies, kills anything already listening on port 3000, waits for Antigravity if it is not running, and prints a QR code plus a LAN URL such as https://192.168.1.5:3000. Scan that QR code from a phone on the same Wi-Fi network. If HTTPS is active, the first visit shows a self-signed certificate warning, which the README says to accept through the browser's advanced option.

For HTTPS, the repository includes a generator that uses OpenSSL when present and falls back to Node's crypto module otherwise, writing into ./certs/.

node generate_ssl.js

After that, restart the server; the README states it detects the certificates automatically. The configuration file is created from .env.example on first launch, and the only value you must change for local use is the password.

APP_PASSWORD=your-app-password
PORT=3000

Global access through ngrok, Cloudflare or Pinggy

The web launchers (start_ag_phone_connect_web.bat and start_ag_phone_connect_web.sh) add a tunnel so the session is reachable over mobile data. The provider is chosen with TUNNEL_PROVIDER in .env, and the three options have genuinely different setup costs.

ngrok is the default and needs an account plus an authtoken. The .env.example comment notes that the token prevents the one-hour session limit, so an unauthenticated ngrok tunnel is a short-lived one.

TUNNEL_PROVIDER=ngrok
NGROK_AUTHTOKEN=your-ngrok-authtoken

Cloudflare requires the cloudflared binary installed separately, and the .env.example shows optional CLOUDFLARE_TUNNEL_NAME and CLOUDFLARE_TUNNEL_URL keys for a named tunnel with a custom domain instead of an ephemeral hostname. Pinggy is the lowest-friction path: the README says it works over SSH with the Python SDK and that the launcher installs the pinggy package automatically, with an optional PINGGY_TOKEN for a persistent subdomain. The README's claim that local devices still get password-free access while external traffic is password-protected is the part worth checking on your own network, because it depends on how the server classifies the request source.

The launcher prints a public URL and a Magic QR code that logs the phone in without typing the password. That convenience is also the risk surface: the tunnel URL is the only thing standing between the internet and a debugging port on your machine, which is why the README pairs it with a passcode and signed cookies rather than exposing the CDP endpoint itself.

Where the design breaks down

The first limitation is UI coupling. Every capability here is downstream of Antigravity's DOM. The README's own troubleshooting note about the missing chat container is a preview of the failure mode: the server runs, the phone connects, and the screen stays empty because a selector no longer matches. There is no fallback data source described.

The second is the debugging port. Launching Antigravity with --remote-debugging-port=9000 opens a DevTools Protocol endpoint on the machine. The project does not expose it through the tunnel, but it does rely on it being present. Anyone who already treats an open debugging port as unacceptable should stop here.

The third is release cadence. The last push was on 2026-06-16, and the newest release listed is v0.3.2 from 2026-04-07. That is not an abandoned project, but it is also not a fast-moving one, and a bridge that tracks another application's UI benefits from speed. If Antigravity changes its chat layout, the wait for a fix is measured against that cadence.

Finally, this is the wrong tool for anything multi-user. There is one password, one session, and no notion of accounts. If two people need to watch the same session with different permissions, the project does not model that.

Alternatives and how they differ

The README states that this project is a refined fork and extension of Antigravity Shit-Chat by gherghett, so that upstream is the closest reference point. The distinction is in scope: the fork adds the tunnel providers, the HTTPS generator, the launcher with QR codes and virtual environment setup, and the mobile history drawer, while the shared foundation is the CDP snapshot approach. Choosing between them is largely a question of whether you want the extra operational tooling or a smaller surface.

A second alternative is not a tool but a pattern: screen sharing or remote desktop into the desktop machine. That approach needs no debugging port and no DOM coupling, because it forwards pixels rather than parsing a chat container. It is heavier on bandwidth, awkward for typing on a phone, and it does not give you a mobile-native history view, but it does not break when Antigravity ships a UI change. If your main need is occasional progress checks rather than replying from the phone, remote desktop is the more durable choice.

A third option is to wait for an official mobile client from the Antigravity side. The search data shows people asking whether Google Antigravity works on a phone, and the honest answer from this repository alone is that it does not; this project is a third-party workaround, and its existence depends on the absence of a first-party one.

Licence, upgrade cost and what to check before committing

The package.json declares GPL-3.0-only, and the README badge says GPL v3. The repository's LICENSE file is present but GitHub reports the licence as NOASSERTION, meaning the automated classifier could not match it to a known template. Treat the package metadata as the stated intent and read the LICENSE file yourself before redistributing or bundling this into another product; if you plan to ship a modified version over a network, the copyleft obligations are the thing to clarify with someone qualified, not something to infer from a badge.

Upgrade cost is low in dependency terms. The runtime is small: express, ws, compression, cookie-parser and dotenv, with Node >=16.0.0 declared in engines. There is no database and no migration path. The real upgrade cost is the Python launcher and the tunnel binaries: cloudflared must be installed and kept current, and the pinggy package is pulled in by the launcher. If you skip the launcher and run node server.js directly, you take on the environment setup the launcher was written to handle, including the virtual environment that the README says fixes PEP 668 issues on Arch and similar distributions.

Before adopting, verify three things on your own machine: that your Antigravity build accepts the debugging port flag, that a chat session produces a readable container rather than the documented error, and that the tunnel provider you pick actually reaches the server through whatever firewall or network you are on. Those three checks cover most of the ways this setup fails.

Editorial conclusion

Adopt it if you already run Antigravity on a desktop and want read-and-reply access from a phone on the same Wi-Fi, and you are comfortable with a GPL-3.0 fork whose last push was on 2026-06-16. Do not adopt it if you need a documented API, a stable release cadence, or a mobile experience that survives Antigravity UI changes. Before installing, verify that your Antigravity build accepts --remote-debugging-port=9000 and that a chat container is actually found; without an open chat the snapshot layer has nothing to read.

Frequently asked questions

Official sources

1. Issues
2. krishnakanthb13/antigravity_phone_chat on GitHub
3. README
4. Releases