Antigravity browser — a Chromium-based surface

The Antigravity browser is not a wrapper around Chrome — it is a distinct application that embeds a recent Chromium engine and adds a substantial agent layer on top. For standard web content, it renders identically to Chrome at the same engine version. For developer tooling, it exposes the same DevTools protocol on a configurable local port. Where it differs is in the UI shell, the agent side rail, the multi-window orchestration layer, and the artifact store that captures every step the agent takes. This page is the reference for the internals of the Antigravity browser.

Chromium engine version and update cadence

The Antigravity browser tracks the current stable Chromium release. On the Stable channel, the engine is typically within two to four weeks of the upstream Chromium commit. The About panel — accessible from the main menu — shows the exact Chromium version alongside the Antigravity browser version number, formatted as Antigravity/[version] Chrome/[chromium-version]. On the Canary channel, the browser may be running a Chromium version ahead of the current Chrome stable release.

Engine updates arrive as delta packages through the browser's built-in update mechanism. You do not need to re-download the full installer for engine updates — only for major Antigravity browser version changes that include changes to the agent runtime architecture. The update badge in the menu indicates when a restart is needed to apply a pending engine update.

Rendering behaviour in the Antigravity browser

For standard web content, the Antigravity browser renders identically to Chrome at the same Chromium version — both use the Blink rendering engine and the V8 JavaScript engine. Web developers testing sites in the Antigravity browser can expect the same results as Chrome, including CSS support, Web API surface, and Canvas/WebGL behaviour.

The differences in rendering behaviour are confined to the UI shell. The agent side rail occupies a fixed-width panel on the right edge of the viewport chrome — this reduces the effective content area width by approximately 340 pixels when the rail is open. Pages that use viewport-width media queries may respond to this differently than they would in Chrome with a maximised window. The rail can be collapsed to a narrow icon strip, restoring the full content width.

DevTools access in the Antigravity browser

The Antigravity browser includes the full Chrome DevTools suite. Open it with F12 or Cmd+Option+I on macOS, or via the main menu under Developer Tools. All standard DevTools panels are present: Elements, Console, Sources, Network, Performance, Memory, Application, Security, and Lighthouse.

The Antigravity browser also exposes the DevTools Protocol (CDP) on a configurable local port. The agent runtime uses CDP internally to observe and drive the browser surface. Extension developers and test automation authors can connect to this port with any CDP-compatible client. The port number and binding address are configurable via a command-line flag: --remote-debugging-port=9222. This is the same flag used in Chrome and works identically in the Antigravity browser.

Extension compatibility in the Antigravity browser

Extension surface	Behaviour in Antigravity browser	Notes
Manifest V3 (MV3)	Fully supported	Same install/update path as Chrome
Manifest V2 (MV2)	Deprecated, mirrors Chrome policy	Legacy MV2 extensions will be removed per Chrome timeline
Native messaging hosts	Supported; host must register app ID	Hosts registered only to Chrome's app ID need updating
chrome.* APIs (standard)	Supported	Full MV3 API surface available
chrome.* APIs (proprietary)	Not available	Small set of APIs exclusive to the Chrome binary
Agent extension APIs	New — Antigravity-specific	Provides access to agent task state and artifact log

The Antigravity browser adds a new set of extension APIs beyond the standard Chromium surface. The agent extension APIs — documented in the Antigravity API reference — let extensions read the current agent task state, subscribe to artifact events, and inject custom tools into the agent runtime. These APIs are specific to the Antigravity browser and have no equivalent in vanilla Chrome.

What the Antigravity browser does that vanilla Chrome does not

The Antigravity browser adds capabilities that are architectural additions to the Chromium base, not Chrome-specific features. The most significant are:

• Native agent runtime — a plan-execute-review loop that can drive the browser, write files, run commands, and report results with human-in-the-loop checkpoints. This runs as a first-class application component, not an extension.
• Multi-window orchestration — the Antigravity browser maintains shared agent context across a configurable grid of windows. The agent can observe and interact with all windows simultaneously, which is architecturally impossible for a Chrome extension.
• Artifact store — every network request, file write, console log, and screenshot from an agent run is captured and stored as a replayable timeline. Vanilla Chrome has no equivalent capture layer.
• Side-pane code editor — a Gemini-backed editor with whole-repo indexing embedded directly in the browser chrome, not as an extension panel.

"The Antigravity browser DevTools integration is what convinced me. I can attach a standard CDP client to the same port the agent uses and observe exactly what it is doing at the protocol level. For debugging agent task failures that is invaluable — you get a browser-native view of every interaction the agent took."

Security model of the Antigravity browser

The Antigravity browser inherits Chromium's sandbox architecture — each renderer process runs in an isolated sandbox with restricted OS access. The agent runtime is an additional privileged process that communicates with renderer processes through a controlled IPC channel. The agent cannot bypass the sandbox; it interacts with pages through the same DevTools Protocol that extension automation uses, subject to the same permissions model.

Workspace file access is scoped to the folder you designate during onboarding. The agent process does not have access to the broader file system unless you explicitly grant additional paths from the settings panel. This follows the principle of least privilege outlined in the OECD AI Principles on human oversight and accountability for AI systems. The full security model is documented on the security page.