If you've tried an "agentic" AI coding tool recently, there's a good chance it asked you to switch editors entirely. Google's own agent-first IDE, Antigravity, launched in November 2025 with exactly that trade-off: full agentic power, but only inside its own dedicated desktop application.
That trade-off just went away. Google has shipped Antigravity extensions for VS Code, Visual Studio, JetBrains, and Zed, bringing the same agent, the same review workflow, and the same account into the editor you've already spent years configuring exactly the way you like it.
This post walks through what the VS Code extension actually is, how it fits into Antigravity's broader architecture, how to install and configure it, and most importantly; how its permission system keeps an agent that can read files, run terminal commands, and drive a real browser from doing anything you haven't explicitly allowed.
By the end of this article, you will be able to:
agy
CLINew to Antigravity generally? Start with Google's own primer: Antigravity 2.0 Overview
To follow along hands-on, you'll need:
You can also read this purely as an architecture and workflow walkthrough; every step is explained, not just shown.
It helps to know there are actually three doors into the same house:
[ Antigravity 2.0 ] ── the full desktop app, a dedicated fork of VS Code
[ Antigravity CLI (agy) ] ── the same agent, driven from your terminal
[ IDE Extensions ] ── the same agent, embedded in an editor you already run
│
▼
[ Local `agy` backend service ] (installed automatically on first launch)
│
▼
[ Antigravity Agent Runtime ]
(planning, terminal execution, browser subagent — powered by Gemini)
The extension itself is deliberately thin: a side panel, an inline diff viewer, and a renderer for the agent's plans and artifacts, all sitting on top of your existing VS Code install. On first launch, it silently installs a local agy
backend service on your machine, the same engine that powers the standalone desktop app and the CLI. Because of that shared backend, sign-in is unified across every surface: authenticate once, and the same entitlement, permissions, and conversation history follow you whether you open Antigravity from VS Code, JetBrains, or a terminal.
Worth knowing:the full Antigravity 2.0 app is a genuine fork of VS Code, so if you ever outgrow the extension, migrating is mostly a matter of importing your settings. But if your editor setup is already exactly how you want it, the extension gets you the same agent without asking you to leave.
Getting running takes two short steps.
Ctrl+Shift+X
on Windows/Linux, Cmd+Shift+X
on macOS)agy
backend service in the background, there's no separate terminal setup to do yourself
Note:you don't need a paid plan to try this. The free tier is enough to install and start using the extension. Enterprise teams instead authenticate against a Gemini Enterprise–enabled account, which ties usage to org-level budgets and IAM policies rather than a personal quota, useful if you want every developer's agent usage centrally governed from day one.
Once you're signed in, a panel on the right side of the editor becomes your main workspace. From there you can spin up new conversations, attach images, switch agent modes, and pick between models; all without a context switch away from your code. As a task runs, a toolbar above the input tracks open file changes, running terminal processes, and any artifacts the agent has produced, so you always know what it's currently touching.
For any non-trivial request, the agent doesn't jump straight to editing files. The standard workflow will be to first produce an implementation plan, which is basically an artifact describing exactly what it intends to change and why and, unless your review policy is set to always proceed, it s for your sign-off (permission) before touching a single line.
The useful part isn't just the ; it's that you can comment directly on the plan itself. Want a smaller scope, a different library, or to correct a misunderstanding before any code gets written? Leave the comment, and either hit Proceed to continue as-is or submit your feedback for the agent to revise the plan against. Think of it as reviewing a pull request description before the pull request exists.
After a task finishes, the agent can generate a walkthrough, which is basically an artifact summarizing what actually changed and why useful when you're reviewing work after the fact rather than watching it happen live.
More interesting for web development specifically: Antigravity can open, read, and actuate a real local Chrome browser through a dedicated browser subagent. Practically, that means after building a feature, the agent can launch your dev server, click through the UI it just built, capture screenshots, and save the interaction as a video artifact, all before you ever tab over to localhost
yourself to check its work.
This is the section that matters most if you plan to use this on real projects, not just toy demos/projects.
Every sensitive action the agent takes, like reading a file, running a command, hitting a URL, calling an MCP tool is represented as a permission resource in the form action(target)
. Each one is evaluated against three lists:
Strict precedence always runs Deny > Ask > Allow. If a command matches both an Allow rule and a Deny rule, the Deny rule wins. That single fact makes it easy to build a safety net: broadly allow the things you trust, then explicitly deny the handful of commands you never want run automatically, regardless of any other rule.
Step-by-Step Decision Hierarchy
Incoming Tool Action: action(target)
│
▼
┌───────────────────────┐
│ 1. Check DENY List │ ──(Matches?)──► ❌ Blocked Immediately
└───────────┬───────────┘
│ No
▼
┌───────────────────────┐
│ 2. Check ASK List │ ──(Matches?)──► ❓ & Prompt User
└───────────┬───────────┘
│ No
▼
┌───────────────────────┐
│ 3. Check ALLOW List │ ──(Matches?)──► ✅ Run Automatically
└───────────┬───────────┘
│ No
▼
┌───────────────────────┐
│ 4. Default Fallback │ ──────────────► ❓ Prompt User
└───────────────────────┘
A reasonable starting configuration looks something like this:
command(rm -rf .*)
command(git push --force.*)
write_file(\.env.*)
command(git push.*)
command(npm publish)
execute_url(*)
command(git status)
command(git log.*)
command(npm run (test|lint|build).*)
read_file(src/.*)
read_url(developer\.mozilla\.org)
By default, reading and writing files inside your active project workspace is auto-allowed, while everything else; like arbitrary shell commands, MCP tools, and any interactive browser action falls back to Ask unless you configure otherwise. That default is deliberately conservative, it lets the agent move quickly on the code it's supposed to touch, while still checking in before it runs a command or browses a URL you haven't vetted.
Because the agent can drive an actual browser, it gets its own layer of isolation on top of the general permission engine:
read_url
/ execute_url
permission rules.PS:
At first, when I started prompting, the agent wasn't able to provide an implementation plan due to a ** Pre-Tool Hook Issue detected**.
And so, instead of creating or modifying my files, it simply printed out the codes with an instruction to copy & paste the codes into my files as shown below:
I used the method One (1) to apply a quick fix to the Pre-Tool Execution Hook Issue and voila! (Issue Resolved).
Try the smallest possible version: install the extension, ask it to fix one small bug or add one small feature, and actually read the implementation plan before clicking Proceed. Watch the toolbar as it works to see which files, commands, and artifacts it touches along the way.
Are you planning to move to the full Antigravity 2.0 desktop app, or sticking with your current editor and just adding the extension? I'd love to hear how the plan-and-review workflow compares to inline-suggestion tools like Copilot in the comments.