Antigravity Phone Connect: mirroring a desktop AI session to a phone over CDP

The problem: an AI session that pins you to one desk

Antigravity is a desktop application. Its chat lives in a panel inside that window, and the generation stream is only visible there. If you start a long generation and then leave the room, you either wait or you kill it. Antigravity Phone Connect targets exactly that gap: it mirrors the chat to a phone browser and forwards input back, so the session keeps running on the desktop while you read and reply from elsewhere. The intended user is a single developer running Antigravity locally on their own machine, not a team sharing one instance. The README frames it as stepping away from the desk while keeping sight and control over the model's thinking process. There is no multi-user account model in the material, no per-session permissions, and no audit log. It is one operator, one machine, one phone.

How the mirror works: CDP snapshots, not a video stream

The mechanism is Chrome DevTools Protocol. Antigravity is launched with --remote-debugging-port=9000, which exposes the Electron or Chromium debugging endpoint. The Node server attaches to that endpoint and reads the chat DOM, then pushes snapshots to connected mobile clients over WebSocket. The README describes sub-100ms snapshots and calls the technique CDP mirroring. That is a different architecture from screen streaming: there is no pixel pipeline, no video codec, and no OS-level screen capture. What the phone receives is derived from the page structure, which is why the project can offer a mobile drawer for conversation history with what the README calls native-feel cards rather than a scaled-down desktop window. The trade-off is direct: anything not present in the DOM is invisible to the phone. If Antigravity renders a control outside the captured container, or changes its markup between versions, the mirror degrades. The README already warns that without an active chat session you will see chat container not found errors, which confirms the server is looking for a specific DOM element rather than scraping a generic surface.

Getting it running: debug port, launcher, then the QR code

The sequence in the README has three moving parts. First, Antigravity must be started with the debugging port open. The manual form is antigravity . --remote-debugging-port=9000. Windows and Linux users can instead run install_context_menu.bat or ./install_context_menu.sh, select [1] Install, and then right-click a project folder and choose Open with Antigravity (Debug). macOS has no context menu path in this repository; the README instead walks through Automator, creating a Quick Action that receives folders in Finder and runs a shell script with cd "$1" followed by the same antigravity command. Second, a chat must be open, either an existing conversation from the bottom-right panel or a new one. Third, the launcher runs. On Windows it is start_ag_phone_connect.bat; on macOS and Linux it is chmod +x start_ag_phone_connect.sh once, then ./start_ag_phone_connect.sh. According to the README the script sets up a Python virtual environment to avoid PEP 668 problems on Arch and similar distributions, checks Node and Python dependencies, kills anything already listening on port 3000, waits for Antigravity if it is not up yet, and prints a QR code plus a LAN URL such as https://192.168.1.5:3000. The claim that the server waits for Antigravity is worth noting because it inverts the usual order: you can start the bridge first and let it attach later.

Global access and the passcode boundary

Local Wi-Fi access is treated as trusted. The README says devices on the same LAN enjoy direct access without a password, and that the project automatically trusts the local home network while applying password protection to external traffic. That is a deliberate convenience choice and also the sharpest security edge in the design: anyone on your Wi-Fi who knows the URL reaches the session. For remote access there are three tunnel providers, selected with TUNNEL_PROVIDER in .env. ngrok is the default and needs NGROK_AUTHTOKEN from an ngrok account. cloudflare needs cloudflared installed locally, with no token in the env file. pinggy needs no install because it works over SSH and the Python SDK, and the launcher installs the pinggy pip package automatically; PINGGY_TOKEN is optional and only buys a persistent subdomain. The remote launchers are start_ag_phone_connect_web.bat and ./start_ag_phone_connect_web.sh. You then set APP_PASSWORD in .env, and the README offers two entry paths: scan the Magic QR code for automatic login, or open the public URL and type the passcode. The launchers create .env from .env.example if it is missing, and the manual equivalent is copy .env.example .env on Windows or cp .env.example .env elsewhere. HTTPS is generated separately with node generate_ssl.js, which uses OpenSSL when available and falls back to Node crypto, writing into ./certs/. The server picks the certificates up on restart. The browser warning on first visit is expected for a self-signed certificate.

Where it breaks: DOM coupling, port collisions, and the debug port itself

The failure modes are structural rather than incidental. The mirror depends on Antigravity's internal page structure, so a UI update can break capture without any change in this repository; the chat container not found message is the visible symptom. The launcher kills whatever holds port 3000, which is fine on a dedicated machine and disruptive if you run another service there. The debugging port is itself a wide door: --remote-debugging-port=9000 gives any local process control over the Antigravity browser context, and the README does not discuss binding that port to localhost only or firewalling it. Tunnel mode moves the session to a public URL guarded by one shared password, with no mention of rate limiting, session expiry, or failed-login lockout. This is the wrong tool if you want to drive Antigravity from a machine where you cannot pass command-line flags, if you need multiple viewers, or if your Antigravity build does not expose the chat DOM the server expects. It is also the wrong tool for anyone who wants a general remote desktop: it mirrors one panel, not the operating system.

The alternative: Antigravity Shit-Chat and what the fork changed

The README states plainly that this project is a refined fork and extension based on Antigravity Shit-Chat by gherghett. That upstream project is the honest comparison point, and the difference is scope rather than a different mechanism. Both sit on the same idea of reading the Antigravity session and serving it to another device. What this fork adds, per its own documentation, is the mobile-first history drawer, the LAN trust rule with password protection for external traffic, the three-provider tunnel layer with a Magic QR login, the .env-driven configuration, and the SSL generation script with an OpenSSL and Node crypto fallback. A user who only wants a quick local mirror and does not care about tunnels or certificate generation has less reason to prefer the fork; a user who wants to leave the house with the session does. The other real alternative is not another repository at all but the built-in path: run Antigravity on a machine you can reach over SSH or a VPN and treat the desktop as the interface. That avoids the DOM coupling entirely, at the cost of a much heavier connection and no purpose-built mobile layout.

Licence, maintenance, and what you are actually signing up for

The repository carries a GPL v3 badge in the README, while the repository metadata reports the licence as NOASSERTION. Those two signals disagree, and the discrepancy matters because GPL v3 carries distribution obligations that permissive licences do not. If you only run this locally for yourself, the practical effect is small. If you intend to ship it inside a product or bundle it into a distributed image, resolve the licence question first; that is a fact about the repository state, not legal advice, and it is worth a look at the LICENSE file rather than the badge. On maintenance, the release history shows v0.2.24 and v0.2.28 in late February 2026, then v0.3.2 in early April 2026, with the last push to master in mid June 2026. That is a small project with occasional releases, and the upgrade cost is tied to how much you customise. The .env file is generated from .env.example, so a new release that adds a key will not appear in your existing .env until you diff the two. Because the mirror is coupled to Antigravity's DOM, an Antigravity update can force a bridge update on its own schedule, independent of anything in this repository.

Editorial conclusion

Adopt this if you run Antigravity on a desktop with a fixed debug port and want read and control access from a phone on the same Wi-Fi, and treat the tunnel mode as a separate decision because it exposes the session to the public internet behind a single APP_PASSWORD. Do not adopt it if you need a vendor-supported remote desktop, if you cannot launch Antigravity with --remote-debugging-port=9000, or if the GPL v3 obligations in a NOASSERTION repository are a problem for your distribution. Before trusting it, verify that generate_ssl.js produces certs in ./certs/ on your machine, that the launcher's auto-kill of port 3000 does not collide with another service, and that the chat container is actually detected once Antigravity is running.

Official sources

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