What happened
Google says the built-in browser agent is rolling out for Antigravity App version 2.30.0 and later on macOS, Windows, and Linux, for personal Google Accounts on Free, Plus, Google AI Pro, and Google AI Ultra plans. It requires no separate browser installation or setup. The agent can open pages, interact with a running application, inspect console errors and failed network requests, take screenshots, and verify visual fixes before completing a task.
A user can describe the desired test in ordinary language; the main agent starts a browser subagent when the task needs live rendering, clicking, form input, responsive checks, screenshots, or console and network inspection. Users can also invoke /browser directly. Google’s example asks the agent to playtest a local checkout flow, reproduce a calculation error, fix it, and verify the updated total with no console errors. For questions answerable from static documentation, the agent reads the page without opening a browser tab.
Each browser subagent has its own isolated context window. The default model is Gemini Flash, which Google says is intended to keep interactions fast and conserve higher-tier quota. If Flash quota is exhausted or unavailable, the agent stops and asks how to proceed rather than switching models automatically. In the app, multiple browser subagents can run concurrently in separate tabs for tasks such as comparing pricing, documentation, and changelog pages. Users can observe activity, stop a subagent, and take control of its tab.
Availability differs across products. The built-in browser agent is not yet available for business or enterprise accounts, Remote Agents, or SSH workspace windows. Antigravity CLI, business and enterprise app accounts, and local IDE workspaces instead have a Chrome DevTools browser subagent. The CLI path requires Node.js with npx, Chrome version 144 or later, and remote debugging enabled; the user must approve Chrome’s prompt. IDE support is listed for Antigravity IDE 2.6.0+ and the Google Antigravity VS Code extension 1.9.0+. Google also notes that the manual built-in browser side panel is available across desktop app accounts from version 2.26.0.
The built-in browser’s controls include site-navigation approvals, cross-origin redirect checks, per-port localhost isolation, explicit approval for staged file uploads, and download rules. Identity-provider and payment pages are blocked from agent actuation, while sensitive content is masked from snapshots and screenshots. The built-in subagent uses structured actions in an isolated worker without workspace or shell tools or arbitrary in-page JavaScript evaluation. These protections and the separate Chrome-based mode mean that “browser use” is not one uniform capability across all Antigravity environments.
What the archive adds
New Runtime’s earlier coverage described Antigravity Remote Agents gradually rolling out in a Google-managed remote environment (Google Antigravity rolls out Remote Agents on cloud VMs, 2026-11-06). This browser documentation is a new fact about the product’s local-app workflow, not a restatement: it explicitly excludes Remote Agents from the built-in browser rollout.
Trend signal
This supports agent security moves to runtime boundaries: the documented controls govern what the browser agent can access and do, including site approvals, isolated browser actions, upload/download gates, and blocking credential and payment interactions. The docs describe product safeguards, not an independent assessment of their effectiveness.
Why now
Google’s documentation identifies a version threshold and an ongoing rollout, rather than a single general-availability date. That makes the practical timing account- and version-dependent: builders need to check whether their personal account has received the built-in mode or whether their environment still requires Chrome-based setup.
Why it matters
For teams building web products with Antigravity, browser interaction can close a useful loop between code changes and observable behavior: an agent can exercise a page, surface errors, and check whether a fix worked. The example is especially relevant to local development and UI regression checks, where screenshots alone may miss a broken interaction or console failure.
The deployment boundaries matter as much as the capability. A personal-account developer can get a no-install built-in browser, while an enterprise team or CLI user may need a locally configured Chrome session and debugging permission. The separate-context design and user-visible controls help make browser tasks easier to supervise, but they do not establish how reliably the agent tests arbitrary applications or whether its checks are sufficient for release quality. Teams should treat it as an additional verification path, not a replacement for deterministic tests and human review.
What happens next
- The built-in browser rollout will reach more personal Antigravity App users. (3 months, 75%). Watch for: Google changing the documentation’s “rolling out” status or adding broader account availability.
Limits and uncertainty
Google describes the intended capabilities and access rules, but does not report independent measurements of task success, false negatives in bug detection, or how often browser actions require user intervention. Availability is explicitly still rolling out, so a qualifying personal account and app version do not guarantee that the feature is active for every user immediately. The documentation also distinguishes the built-in agent from Chrome DevTools MCP; results and controls should not be assumed identical across those modes.
Skill to build now
Turn one recurring UI check into a bounded browser task: state the starting URL, the action sequence, and a concrete completion condition such as a visible total or absence of console errors. Run it against a local app, inspect the agent’s actions and review the code diff, then keep a deterministic test for any behavior that must never regress.
Reader takeaway
Antigravity’s browser agent is a practical new UI-testing surface, but access depends on account, version, and product surface. Before building a workflow around it, confirm which browser mode your environment supports and keep explicit completion checks and conventional tests in the loop.